rewriteflag = true;
          break;
        }
      } while (rewriteflag && !terminal);

      // Did we not find our way to a resolver?
      if (!rewrite_flag) {
         report an error
         return NULL;
      }


      // Leave rest to another protocol?
      if (strcasecmp(flags, "P")) {
         return key as host to talk to;
      }

      // If not, keep plugging
      if (!addnl) { // No SRVs came in as additional info, look them up
        srvs = lookup(type=SRV, key);
      }

      sort SRV records by preference, weight, ...
      foreach (SRV record) { // in order of preference
        try contacting srv[j].target using the protocol and one of the
            resolution service requests from the "services" field of the
            last NAPTR record.
        if (successful)
          return (target, protocol, service);
          // Actually we would probably return a result, but this
          // code was supposed to just tell us a good host to talk to.
      }
      die with an "unable to find a host" error;
    }

Notes:
======

     -  A client MUST process multiple NAPTR records in the order
        specified by the "order" field, it MUST NOT simply use the first
        record that provides a known protocol and service combination.











 
RFC 2168            Resolution of URIs Using the DNS           June 1997


     -  If a record at a particular order matches the URI, but the
        client doesn't know the specified protocol and service, the
        client SHOULD continue to examine records that have the same
        order. The client MUST NOT consider records with a higher value
        of order. This is necessary to make delegation of portions of
        the namespace work.  The order field is what lets site
        administrators say "all requests for URIs matching pattern x go
        to server 1, all others go to server 2".
        (A match is defined as:
          1)  The NAPTR provides a replacement domain name
          or
          2) The regular expression matches the URN
           )

     -  When multiple RRs have the same "order", the client should use
        the value of the preference field to select the next NAPTR to
        consider. However, because of preferred protocols or services,
        estimates of network distance and bandwidth, etc. clients may
        use different criteria to sort the records.
     -  If the lookup after a rewrite fails, clients are strongly
        encouraged to report a failure, rather than backing up to pursue
        other rewrite paths.
     -  When a namespace is to be delegated among a set of resolvers,
        regexps must be used. Each regexp appears in a separate NAPTR
        RR.  Administrators should do as little delegation as possible,
        because of limitations on the size of DNS responses.
     -  Note that SRV RRs impose additional requirements on clients.

Acknowledgments:
=================

   The editors would like to thank Keith Moore for all his consultations
   during the development of this draft. We would also like to thank
   Paul Vixie for his assistance in debugging our implementation, and
   his answers on our questions. Finally, we would like to acknowledge
   our enormous intellectual debt to the participants in the Knoxville
   series of meetings, as well as to the participants in the URI and URN
   working groups.

References:
===========