doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3403.txt b/doc/rfc/rfc3403.txt
new file mode 100644
index 0000000..fb08047
--- /dev/null
+++ b/doc/rfc/rfc3403.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                        M. Mealling
+Request for Comments: 3403                                      VeriSign
+Obsoletes: 2915, 2168                                       October 2002
+Category: Standards Track
+
+
+              Dynamic Delegation Discovery System (DDDS)
+           Part Three: The Domain Name System (DNS) Database
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document describes a Dynamic Delegation Discovery System (DDDS)
+   Database using the Domain Name System (DNS) as a distributed database
+   of Rules.  The Keys are domain-names and the Rules are encoded using
+   the Naming Authority Pointer (NAPTR) Resource Record (RR).
+
+   Since this document obsoletes RFC 2915, it is the official
+   specification for the NAPTR DNS Resource Record.  It is also part of
+   a series that is completely specified in "Dynamic Delegation
+   Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).
+   It is very important to note that it is impossible to read and
+   understand any document in this series without reading the others.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 1]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+Table of Contents
+
+   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.    DDDS Database Specification  . . . . . . . . . . . . . . . .  3
+   4.    NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .  5
+   4.1   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .  5
+   4.2   Additional Information Processing  . . . . . . . . . . . . .  7
+   4.2.1 Additional Section processing by DNS servers . . . . . . . .  7
+   4.2.2 Additional Section processing by resolver/applications . . .  7
+   4.3   Master File Format . . . . . . . . . . . . . . . . . . . . .  7
+   5.    Application Specifications . . . . . . . . . . . . . . . . .  8
+   6.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.1   URN Example  . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.2   E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.    Advice for DNS Administrators  . . . . . . . . . . . . . . . 10
+   8.    Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   9.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 11
+   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 11
+         References . . . . . . . . . . . . . . . . . . . . . . . . . 12
+         Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
+         Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
+
+1. Introduction
+
+   The Dynamic Delegation Discovery System (DDDS) is used to implement
+   lazy binding of strings to data, in order to support dynamically
+   configured delegation systems.  The DDDS functions by mapping some
+   unique string to data stored within a DDDS Database by iteratively
+   applying string transformation rules until a terminal condition is
+   reached.
+
+   This document describes the way in which the Domain Name System (DNS)
+   is used as a data store for the Rules that allow a DDDS Application
+   to function.  It does not specify any particular application or usage
+   scenario.  The entire series of documents is specified in "Dynamic
+   Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"
+   (RFC 3401) [1].  It is very important to note that it is impossible
+   to read and understand any document in that series without reading
+   the related documents.
+
+   The Naming Authority Pointer (NAPTR) DNS Resource Record (RR)
+   specified here was originally produced by the URN Working Group as a
+   way to encode rule-sets in DNS so that the delegated sections of a
+   Uniform Resource Identifiers (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.
+
+
+
+Mealling                    Standards Track                     [Page 2]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   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.
+
+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 [6].
+
+   All other terminology, especially capitalized terms, is taken from
+   [3].
+
+3. DDDS Database Specification
+
+   General Description:
+      This database uses the Domain Name System (DNS) as specified in
+      [8] and [7].
+
+      The character set used to specify the various values of the NAPTR
+      records is UTF-8 [17].  Care must be taken to ensure that, in the
+      case where either the input or the output to the substitution
+      expression contains code points outside of the ASCII/Unicode
+      equivalence in UTF-8, any UTF-8 is interpreted as a series of
+      code-points instead of as a series of bytes.  This is to ensure
+      that the internationalized features of the POSIX Extended Regular
+      Expressions are able to match their intended code-points.
+      Substitution expressions MUST NOT be written where they depend on
+      a specific POSIX locale since this would cause substitution
+      expressions to loose their ability to be universally applicable.
+
+      All DNS resource records have a Time To Live (TTL) associated with
+      them.  When the number of seconds has passed since the record was
+      retrieved the record is no longer valid and a new query must be
+      used to retrieve the new records.  Thus, as mentioned in the DDDS
+      Algorithm, there can be the case where a given Rule expires.  In
+      the case where an application attempts to fall back to previously
+      retrieved sets of Rules (either in the case of a bad delegation
+      path or some network or server failure) the application MUST
+      ensure that none of the records it is relying on have expired.  In
+      the case where even a single record has expired, the application
+      is required to start over at the beginning of the algorithm.
+
+
+
+
+Mealling                    Standards Track                     [Page 3]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   Key Format:
+      A Key is a validly constructed DNS 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 DNS
+      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.
+
+   Collision Avoidance:
+      In the case where two Applications may use this Database (which is
+      actually the case with the ENUM and URI Resolution Applications,
+      Section 6.2), there is a chance of collision between rules where
+      two NAPTR records appear in the same domain but they apply to more
+      than one Application.  There are three ways to avoid collisions:
+
+      *  create a new zone within the domain in common that contains
+         only NAPTR records that are appropriate for the application.
+         E.g., all URI Resolution records would exist under
+         urires.example.com and all ENUM records would be under
+         enum.example.com.  In the case where this is not possible due
+         to lack of control over the upstream delegation the second
+         method is used.
+
+      *  write the regular expression such that it contains enough of
+         the Application Unique string to disambiguate it from any
+         other.  For example, the URI Resolution Application would be
+         able to use the scheme name on the left hand side to anchor the
+         regular expression match to that scheme.  An ENUM specific
+         record in that same zone would be able to anchor the left hand
+         side of the match with the "+" character which is defined by
+         ENUM to be at the beginning of every Application Unique String.
+         This way a given Application Unique String can only match one
+         or the other record, not both.
+
+      *  if two Application use different Flags or Services values then
+         a record from another Application will be ignored since it
+         doesn't apply to the Services/Flags in question.
+
+
+
+Mealling                    Standards Track                     [Page 4]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+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 RFC
+   1035 [7].
+
+   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 based on the
+      combination of the Preference values and Services offered.
+
+   PREFERENCE
+      Although it is called "preference" in deference to DNS
+      terminology, this field is equivalent to the Priority value in the
+      DDDS Algorithm.  It is 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 supporting some protocol or service very well.
+
+
+
+
+Mealling                    Standards Track                     [Page 5]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+      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.  The only exception to this is noted in
+      the second important Note in the DDDS algorithm specification
+      concerning allowing clients to use more complex Service
+      determination between steps 3 and 4 in the algorithm.  Preference
+      is used to give communicate a higher quality of service to rules
+      that are considered the same from an authority standpoint but not
+      from a simple load balancing standpoint.
+
+      It is important to note that DNS contains several load balancing
+      mechanisms and if load balancing among otherwise equal services
+      should be needed then methods such as SRV records or multiple A
+      records should be utilized to accomplish load balancing.
+
+   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-Z and 0-9.  The case of the
+      alphabetic characters is not significant.  The field can be empty.
+
+      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.
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 6]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   REPLACEMENT
+      A <domain-name> which is 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.  Name compression is not to be used for this field.
+
+      This field and the REGEXP field together make up the Substitution
+      Expression in the DDDS Algorithm.  It is simply a historical
+      optimization specifically for DNS compression that this field
+      exists.  The fields are also mutually exclusive.  If a record is
+      returned that has values for both fields then it is considered to
+      be in error and SHOULD be either ignored or an error returned.
+
+4.2 Additional Information Processing
+
+   Additional section processing requires upgraded DNS servers, thus it
+   will take many years before applications can expect to see relevant
+   records in the additional information section.
+
+4.2.1 Additional Section Processing by DNS Servers
+
+   DNS servers MAY add RRsets to the additional information section that
+   are relevant to the answer and have the same authenticity as the data
+   in the answer section.  Generally this will be made up of A and SRV
+   records but the exact records depends on the application.
+
+4.2.2 Additional Section Processing by Resolver/Applications
+
+   Applications MAY inspect the Additional Information section for
+   relevant records but Applications MUST NOT require that records of
+   any type be in the Additional Information section of any DNS response
+   in order for clients to function.  All Applications must be capable
+   of handling responses from nameservers that never fill in the
+   Additional Information part of a response.
+
+4.3 Master File Format
+
+   The master file format follows the standard rules in RFC-1035.  Order
+   and preference, being 16-bit unsigned integers, shall be an integer
+   between 0 and 65535.  The Flags and Services and Regexp fields are
+   all quoted <character-string>s.  Since the Regexp field can contain
+   numerous backslashes and thus should be treated with care.  See
+   Section 7 for how to correctly enter and escape the regular
+   expression.
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 7]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+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 domain 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 in
+      addition to how the Flags are actually encoded and utilized.
+
+6. Examples
+
+6.1 URN Example
+
+   The NAPTR record was originally created for use with the Uniform
+   Resource Name (URN) Resolver Discovery Service (RDS) [15].  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
+   [2] 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:
+
+      urn:cid:199606121851.1@bar.example.com
+
+   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"    .
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 8]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   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 "example.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 'example.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 "example.com" might look like:
+
+example.com.
+;;      order pref flags service           regexp replacement
+IN NAPTR 100  50  "a"    "z3950+N2L+N2C"     ""   cidserver.example.com.
+IN NAPTR 100  50  "a"    "rcds+N2C"          ""   cidserver.example.com.
+IN NAPTR 100  50  "s"    "http+N2L+N2C+N2R"  ""   www.example.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 occurrences 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".
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                     [Page 9]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+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 [18].  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 "e164.arpa" is appended 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.
+ IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@foo.se!i"     .
+ IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i"  .
+
+   Both the ENUM [18] and URI  Resolution [4] Applications use the 'u'
+   flag.  This flag states that the Rule is terminal and that the output
+   is a URI 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.
+
+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.
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 10]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   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 with fewer backslashes.
+
+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.
+
+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.
+
+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 since arbitrary code can be included and
+   subsequently processed.
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 11]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+References
+
+   [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+       One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+   [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+       Two: The Algorithm", RFC 3402, October 2002.
+
+   [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+       Three: The Domain Name System (DNS) Database", RFC 3403, October
+       2002.
+
+   [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+       Four: The Uniform Resource Identifiers (URI) Resolution
+       Application", RFC 3404, October 2002.
+
+   [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+       Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [7] Mockapetris, P., "Domain names - implementation and
+       specification", STD 13, RFC 1035, November 1987.
+
+   [8] Mockapetris, P., "Domain names - concepts and facilities", STD
+       13, RFC 1034, November 1987.
+
+   [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+       specifying the location of services (DNS SRV)", RFC 2782,
+       February 2000.
+
+   [10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
+        RFC 2234, November 1997.
+
+   [11] Daniel, R., "A Trivial Convention for using HTTP in URN
+        Resolution", RFC 2169, June 1997.
+
+   [12] 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.
+
+   [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+   [14] Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+
+
+
+
+Mealling                    Standards Track                    [Page 12]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+   [15] Sollins, K., "Architectural Principles of Uniform Resource Name
+        Resolution", RFC 2276, January 1998.
+
+   [16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource
+        Identifiers using the Domain Name System", RFC 2168, June 1997.
+
+   [17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
+
+   [18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
+
+Author's Address
+
+   Michael Mealling
+   VeriSign
+   21345 Ridgetop Circle
+   Sterling, VA  20166
+   US
+
+   EMail: michael@neonym.net
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling                    Standards Track                    [Page 13]
+
+RFC 3403                   DDDS DNS Database                October 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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 implementation 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                    Standards Track                    [Page 14]
+