Subject: draft-ietf-urn-dns-ddds-database-00.txt

From: Michael Mealling <[email-masked]>
Date: Fri, 14 Jul 2000 13:06:40 -0400

Network Working Group                                      M.M. Mealling
Internet-Draft                                   Network Solutions, Inc.
Expires: January 12, 2001                                  July 14, 2000

              A DDDS Database Using The Domain Name System
                  draft-ietf-urn-dns-ddds-database-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   This document describes a Dynamic Delegation Discovery System
   Database using the Domain Name System as a distributed database of
   Rules. The Keys are domain-names and the Rules are encoded using the
   NAPTR Resource Record.

   Since this document officially obsoletes RFC 2168, it is the
   official specification for the NAPTR DNS Resource Record.

Mealling                Expires January 12, 2001                [Page 1]

Internet-Draft             DDDS DNS Database                   July 2000

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  DDDS Database Specification  . . . . . . . . . . . . . . . . .  5
   4.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . . .  6
   4.1 Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.2 Master File Format . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Application Specifications . . . . . . . . . . . . . . . . . .  9
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.1 URN Example  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Advice for DNS Administrators  . . . . . . . . . . . . . . . . 13
   8.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 16
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19

Mealling                Expires January 12, 2001                [Page 2]

Internet-Draft             DDDS DNS Database                   July 2000

1. Introduction

   The NAPTR DNS Resource Record was originally produced by the URN
   Working Group as a way to encode rule-sets in DNS so that the
   delegated sections of a URI could be decomposed in such a way that
   they could be changed and re-delegated over time. The result was a
   Resource Record that included a regular expression that would be
   used by a client program to rewrite a string into a domain name.
   Regular expressions were chosen for their compactness to
   expressivity ratio allowing for a great deal of information to be
   encoded in a rather small DNS packet.

   Over time this process was generalized for other Applications and
   Rule Databases. This document defines a Rules Database absent any
   particular Application as there may be several Applications all
   taking advantage of this particular Rules Database.

   As a result of this generalization, this document, along with [11]
   and [12], obsoletes RFC 2168[13] and updates RFC 2276[10].

Mealling                Expires January 12, 2001                [Page 3]

Internet-Draft             DDDS DNS Database                   July 2000

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [1].

   All other terminology, especially capitalized terms, is taken from
   [11].

Mealling                Expires January 12, 2001                [Page 4]

Internet-Draft             DDDS DNS Database                   July 2000

3. DDDS Database Specification

   General Description:
      This database uses the Domain Name System (DNS) as specified in
      [3] and [2].

   Key Format:
      A Key is a DNS valid domain-name.

   Lookup Request:
      In order to request a set of rules for a given Key, the client
      issues a request, following standard DNS rules, for NAPTR
      Resource Records for the given domain-name.

   Lookup Response:
      The response to a request for a given Key (domain-name) will be a
      series of NAPTR records. The format of a NAPTR Resource Record
      can be found in Section 4.

   Rule Insertion Procedure:
      Rules are inserted by adding new records to the appropriate zone.
      If a Rule produces a Key that exists in a particular zone then
      only the entity that has administrative control of that zone can
      specify the Rule associated with that Key.

Mealling                Expires January 12, 2001                [Page 5]

Internet-Draft             DDDS DNS Database                   July 2000

4. NAPTR RR Format

4.1 Packet Format

   The packet format of the NAPTR RR is given below. The DNS type code
   for NAPTR is 35.

         The packet format for the NAPTR record is as follows
                                          1  1  1  1  1  1
            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                     ORDER                     |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |                   PREFERENCE                  |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                     FLAGS                     /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                   SERVICES                    /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                    REGEXP                     /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          /                  REPLACEMENT                  /
          /                                               /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   <character-string> and <domain-name> as used here are defined in
   RFC1035[1].

   ORDER
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed in order to accurately represent the
      ordered list of Rules.  The ordering is from lowest to highest.
      If two records have the same order value then they are considered
      to be the same rule and should be selected randomly unless the
      Preference numbers are different which means the randomization is
      weighted according to the ratio of the Preference values.

   PREFERENCE
      A 16-bit unsigned integer that specifies the order in which NAPTR
      records with equal Order values SHOULD be processed, low numbers
      being processed before high numbers. This is similar to the
      preference field in an MX record, and is used so domain
      administrators can direct clients towards more capable hosts or
      lighter weight protocols. A client MAY look at records with
      higher preference values if it has a good reason to do so such as
      not understanding some protocol or service.

Mealling                Expires January 12, 2001                [Page 6]

Internet-Draft             DDDS DNS Database                   July 2000

      The important difference between Order and Preference is that
      once a match is found the client MUST NOT consider records with a
      different Order but they MAY process records with the same Order
      but different Preferences. I.e. Preference is used to give weight
      to rules that are considered the same from an authority
      standpoint but not from a simple load balancing standpoint.

   FLAGS
      A <character-string> containing flags to control aspects of the
      rewriting and interpretation of the fields in the record. Flags
      are single characters from the set [A-Z0-9]. The case of the
      alphabetic characters is not significant.

      It is up to the Application specifying how it is using this
      Database to define the Flags in this field. It must define which
      ones are terminal and which ones are not.

   SERVICES
      A <character-string> that specifies the Service Parameters
      applicable to this this delegation path. It is up to the
      Application Specification to specify the values found in this
      field.

   REGEXP
      A <character-string> containing a substitution expression that is
      applied to the original string held by the client in order to
      construct the next domain name to lookup. See the DDDS Algorithm
      specification for the syntax of this field.

      As stated in the DDDS algorithm, The regular expressions MUST NOT
      be used in a cumulative fashion, that is, they should only be
      applied to the original string held by the client, never to the
      domain name produced by a previous NAPTR rewrite. The latter is
      tempting in some applications but experience has shown such use
      to be extremely fault sensitive, very error prone, and extremely
      difficult to debug.

   REPLACEMENT
      A <domain-name> which specifies the The next domain-name to query
      for depending on the potential values found in the flags field.
      This field is used when the regular expression is a simple
      replacement operation.  Any value in this field MUST be a fully
      qualified domain-name. Unless and until permitted by future
      standards action, name compression is not to be used for this
      field.

4.2 Master File Format

   The master file format follows the standard rules in RFC-1035[1].
   Order and preference, being 16-bit unsigned integers, shall be an
   integer between 0 and 65535. The Flags and Services and Regexp

Mealling                Expires January 12, 2001                [Page 7]

Internet-Draft             DDDS DNS Database                   July 2000

   fields are all quoted <character-string>s.  Since the Regexp field
   can contain numerous backslashes and thus should be treated with
   care. See Section 10 for how to correctly enter and escape the
   regular expression.

Mealling                Expires January 12, 2001                [Page 8]

Internet-Draft             DDDS DNS Database                   July 2000

5. Application Specifications

   This DDDS Database is usable by any application that makes use of
   the DDDS algorithm. In addition to the items required to specify a
   DDDS Application, an application wishing to use this Database must
   also define the following values:

   o  What DNS zone the Key that is produced by the First Well Known
      Rule belongs to. Any application must ensure that its rules do
      not collide with rules used by another application making use of
      this Database. For example, the 'foo' application might have all
      of its First Well Known Keys be found in the 'foo.net' zone.

   o  What the allowed values for the Services and Protocols fields are.

   o  What the expected output is of the terminal rewrite rule

Mealling                Expires January 12, 2001                [Page 9]

Internet-Draft             DDDS DNS Database                   July 2000

6. Examples

6.1 URN Example

   The NAPTR record was originally specified for use with the a Uniform
   Resource Name Resolver Discovery System. This example details how a
   particular URN would use the NAPTR record to find a resolver service
   that can answer questions about the URN. See [12] for the definitive
   specification for this Application.

   Consider a URN namespace based on MIME Content-Ids (this is very
   hypothetical so do not rely on this) . The URN might look like this:

   This Application's First Well Known Rule is to extract the
   characters between the first and second colon. For this URN that
   would be 'cid'. The Application also specifies that, in order to
   build a Database-valid Key, the string 'urn.arpa' should be appended
   to the result of the First Well Known Rule. The result is
   'cid.urn.arpa'.

   Next, the client queries the DNS for NAPTR records for the
   domain-name 'cid.urn.arpa'. The result is a single record:

     cid.urn.arpa.
     ;;       order pref flags service        regexp           replacement
     IN NAPTR 100   10   ""    ""  "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i"    .

   Since there is only one record, ordering the responses is not a
   problem.  The replacement field is empty, so the pattern provided in
   the regexp field is used . We apply that regexp to the entire URN to
   see if it matches, which it does.  The \2 part of the substitution
   expression returns the string "foo.com". Since the flags field is
   empty, the lookup is not terminal and our next probe to DNS is for
   more NAPTR records where the new domain is 'foo.com'.

   Note that the rule does not extract the full domain name from the
   CID, instead it assumes the CID comes from a host and extracts its
   domain.  While all hosts, such as 'bar', could have their very own
   NAPTR, maintaining those records for all the machines at a site
   could be an intolerable burden. Wildcards are not appropriate here
   since they only return results when there is no exactly matching
   names already in the system.

   The record returned from the query on "foo.com" might look like:

Mealling                Expires January 12, 2001               [Page 10]

Internet-Draft             DDDS DNS Database                   July 2000

     gatech.edu.
     ;;      order pref flags service           regexp  replacement
     IN NAPTR 100  50  "a"    "z3950+N2L+N2C"     ""    cidserver.foo.com.
     IN NAPTR 100  50  "a"    "rcds+N2C"          ""    cidserver.foo.com.
     IN NAPTR 100  50  "a"    "http+N2L+N2C+N2R"  ""    www.foo.com.

   Continuing with the example, note that the values of the order and
   preference fields are equal in all records, so the client is free to
   pick any record. The Application defines the flag 'a' to mean a
   terminal lookup and that the output of the rewrite will be a
   domain-name for which an A record should be queried. Once the client
   has done that, it has the following information: the host, its IP
   address, the protocol, and the services available via that protocol.
   Given these bits of information the client has enough to be able to
   contact that server and ask it questions about the URN.

   Recall that the regular expression used \2 to extract a domain name
   from the CID, and \. for matching the literal '.' characters
   separating the domain name components. Since '\' is the escape
   character, literal occurances of a backslash must be escaped by
   another backslash. For the case of the cid.urn.arpa record above,
   the regular expression entered into the master file should be
   "!urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i".  When the client code
   actually receives the record, the pattern will have been converted
   to "!urn:cid:.+@([^\.]+\.)(.*)$!\2!i".

6.2 E164 Example

   The ENUM Working Group in the IETF has specified a service that
   allows a telephone number to be mapped to a URI. The Application
   Unique String for the ENUM Application is the E.164 telephone number
   with the dashes removed.  The First Well Known Rule is to remove all
   characters from the the telephone number and then use the entire
   number as the first Key. For example, the phone number
   "770-555-1212" represented as an E.164 number would be
   "+1-770-555-1212". Converted to the Key it would be "17705551212".

   The ENUM Application at present only uses this Database. It
   specifies that, in order to convert the first Key into a form valid
   for this Database, periods are inserted between each digit, the
   entire Key is inverted and then append "e164.arpa" to the end. The
   above telephone number would then read
   "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to
   retrieve Rewrite Rules as NAPTR records.

   For this example telephone number we might get back the following
   NAPTR records:

   $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.

Mealling                Expires January 12, 2001               [Page 11]

Internet-Draft             DDDS DNS Database                   July 2000

    IN NAPTR 100 10 "u" "sip+N2R"  "!^.*$!sip:[email-masked]!"     .
    IN NAPTR 102 10 "u" "smtp+N2R" "!^.*$!mailto:[email-masked]!"  .

   ENUM uses the same 'u' flag as the URI Resolution Application. This
   flag states that the Rule is terminal and that the output is a URL
   which contains the information needed to contact that telephone
   service. ENUM also uses the same format for its Service Parameters.
   These state that the available protocols used to access that
   telephone's service are either the Session Initiation Protocol or
   SMTP mail.

Mealling                Expires January 12, 2001               [Page 12]

Internet-Draft             DDDS DNS Database                   July 2000

7. Advice for DNS Administrators

   Beware of regular expressions. Not only are they difficult to get
   correct on their own, but there is the previously mentioned
   interaction with DNS. Any backslashes in a regexp must be entered
   twice in a zone file in order to appear once in a query response.
   More seriously, the need for double backslashes has probably not
   been tested by all implementors of DNS servers.

   In order to mitigate zone file problems, administrators should
   encourage those writing rewrite rules to utilize the 'default
   delimiter' feature of the regular expression. In the DDDS
   specification the regular expression starts with the character that
   is to be the delimiter. Hence if the first character of the regular
   expression is an exclamation mark ('!') for example then the regular
   expression can usually be written without any backslashes.

Mealling                Expires January 12, 2001               [Page 13]

Internet-Draft             DDDS DNS Database                   July 2000

8. 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 Service Parameter combination.

      When multiple RRs have the same "order" and all other criteria
      being equal, the client should use the value of the preference
      field to select the next NAPTR to consider. However, because it
      will often be the case where preferred protocols or services
      exist, clients may use this additional 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.

Mealling                Expires January 12, 2001               [Page 14]

Internet-Draft             DDDS DNS Database                   July 2000

9. IANA Considerations

   The values for the Services and Flags fields will be determined by
   the Application that makes use of this DDDS Database. Those values
   may require a registration mechanism and thus may need some IANA
   resources. This specification by itself does not.

Mealling                Expires January 12, 2001               [Page 15]

Internet-Draft             DDDS DNS Database                   July 2000

10. Security Considerations

   The NAPTR record, like any other DNS record, can be signed and
   validated according to the procedures specified in DNSSEC.

   This Database makes 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.

Mealling                Expires January 12, 2001               [Page 16]

Internet-Draft             DDDS DNS Database                   July 2000

References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, BCP 14, March 1997.

   [2]  Mockapetris, P.V., "Domain names - implementation and
        specification", RFC 1035, STD 13, Nov 1987.

   [3]  Mockapetris, P.V., "Domain names - concepts and facilities",
        RFC 1034, STD 13, Nov 1987.

   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
        RFC 2234, November 1997.

   [6]  Danie1, R., "A Trivial Convention for using HTTP in URN
        Resolution", RFC 2169, June 1997.

   [7]  IEEE, "IEEE Standard for Information Technology - Portable
        Operating System Interface (POSIX) - Part 2: Shell and
        Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.

   [8]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
        1998.

   [9]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [10]  Sollins, K., "Architectural Principles of Uniform Resource
         Name Resolution", RFC 2276, January 1998.

   [11]  Mealling, M.M., "Dynamic Delegation Discovery System (DDDS)",
         Internet-Draft draft-ietf-urn-ddds-00.txt, May 2000.

   [12]  Mealling, M.M., "URI Resolution using the Dynamic Delegation
         Discovery System", Internet-Draft
         draft-ietf-urn-uri-res-ddds-00.txt, July 2000.

   [13]  Danie1, R. and M. Mealling, "Resolution of Uniform Resource
         Identifiers using the Domain Name System", RFC 2168, June 1997.

Mealling                Expires January 12, 2001               [Page 17]

Internet-Draft             DDDS DNS Database                   July 2000

Author's Address

   Michael Mealling
   Network Solutions, Inc.
   505 Huntmar Park Drive
   Herndon, VA  22070
   US

   Phone: +1 770 935 5492
   EMail: [email-masked]
   URI:   http://www.netsol.com

Mealling                Expires January 12, 2001               [Page 18]

Internet-Draft             DDDS DNS Database                   July 2000

Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.

Mealling                Expires January 12, 2001               [Page 19]