rfc2168.txt

bind-3.2.

RFC 2168            Resolution of URIs Using the DNS           June 1997


        rewrite_flag = false;
        terminal = false;
        if (key has been seen) {
          quit with a loop detected error
        }
        add key to list of "seens"
        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'

        discard any records with an unknown value in the "flags" field.
        sort NAPTR records by "order" field and "preference" field
            (with "order" being more significant than "preference").
        n_naptrs = number of NAPTR records in response.
        curr_order = records[0].order;
        max_order = records[n_naptrs-1].order;

        // Process current batch of NAPTRs according to "order" field.
        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
          if (unknown_flag) // skip this record and go to next one
             continue;
          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
          if (!newkey) // Skip to next record if the rewrite didn't
             match continue;
          // We did do a rewrite, shrink max_order to current value
          // so that delegation works properly
          max_order = naptr[j].order;
          // Will we know what to do with the protocol and services
          // specified in the NAPTR? If not, try next record.
          if(!isKnownProto(naptr[j].services)) {
            continue;
          }
          if(!isKnownService(naptr[j].services)) {
            continue;
          }

          // At this point we have a successful rewrite and we will
          // know how to speak the protocol and request a known
          // resolution service. Before we do the next lookup, check
          // some optimization possibilities.

          if (strcasecmp(flags, "S")
           || strcasecmp(flags, "P"))
           || strcasecmp(flags, "A")) {
             terminal = true;
             services = naptr[j].services;
             addnl = any SRV and/or A records returned as additional
                     info for naptr[j].
          }
          key = newkey;



Daniel & Mealling             Experimental                     [Page 16]

RFC 2168            Resolution of URIs Using the DNS           June 1997


          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.










Daniel & Mealling             Experimental                     [Page 17]

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:
===========

   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
        for Uniform Resource Names", RFC-1737, Dec. 1994.

   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
        February 1996.



Daniel & Mealling             Experimental                     [Page 18]

RFC 2168            Resolution of URIs Using the DNS           June 1997


   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.

   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
        the location of services (DNS SRV)", RFC-2052, October 1996.

   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
        Resolution", RFC-2169, June 1997.

   [6]  URN-WG, "URN Resolution Services", Work in Progress.

   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
        Resource Cataloging and Distribution System, Technical Report
        CS-97-346, University of Tennessee, Knoxville, December 1996

   [8]  Paul Vixie, personal communication.

   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
        Messages", RFC-822, August 1982.

   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
        Specification, http://www.handle.net/docs/client_spec.html

   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.

   [12] Information Retrieval (Z39.50): Application Service Definition
        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.

   [13] IEEE Standard for Information Technology - Portable Operating
        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
        IEEE Std 1003.2-1992; The Institute of Electrical and
        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9

   [14] Braden, R., "Requirements for Internet Hosts - Application and
        and Support", RFC-1123, Oct. 1989.

   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
        Systems", November 1996, Work in Progress.













Daniel & Mealling             Experimental                     [Page 19]

RFC 2168            Resolution of URIs Using the DNS           June 1997


Security Considerations
=======================

   The use of "urn.net" as the registry for URN namespaces is subject to
   denial of service attacks, as well as other DNS spoofing attacks. The
   interactions with DNSSEC are currently being studied. It is expected
   that NAPTR records will be signed with SIG records once the DNSSEC
   work is deployed.

   The rewrite rules make identifiers from other namespaces subject to
   the same attacks as normal domain names. Since they have not been
   easily resolvable before, this may or may not be considered a
   problem.

   Regular expressions should be checked for sanity, not blindly passed
   to something like PERL.

   This document has discussed a way of locating a resolver, but has not
   discussed any detail of how the communication with the resolver takes
   place. There are significant security considerations attached to the
   communication with a resolver. Those considerations are outside the
   scope of this document, and must be addressed by the specifications
   for particular resolver communication protocols.

Author Contact Information:
===========================

   Ron Daniel
   Los Alamos National Laboratory
   MS B287
   Los Alamos, NM, USA, 87545
   voice:  [phone]
   fax:    [phone]
   email:  [e-mail]


   Michael Mealling
   Network Solutions
   505 Huntmar Park Drive
   Herndon, VA  22070
   voice: [phone]
   fax: [phone]
   email: [e-mail]
   URL: http://www.netsol.com/







Daniel & Mealling             Experimental                     [Page 20]