rfc2915.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

Network Working Group                                         M. Mealling
Request for Comments: 2915                        Network Solutions, Inc.
Updates: 2168                                                   R. Daniel
Category: Standards Track                                DATAFUSION, Inc.
                                                           September 2000


        The Naming Authority Pointer (NAPTR) DNS Resource Record

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 (2000). All Rights Reserved.

Abstract

   This document describes a Domain Name System (DNS) resource record
   which specifies a regular expression based rewrite rule that, when
   applied to an existing string, will produce a new domain label or
   Uniform Resource Identifier (URI).  Depending on the value of the
   flags field of the resource record, the resulting domain label or URI
   may be used in subsequent queries for the Naming Authority Pointer
   (NAPTR) resource records (to delegate the name lookup) or as the
   output of the entire process for which this system is used (a
   resolution server for URI resolution, a service URI for ENUM style
   e.164 number to URI mapping, etc).

   This allows the DNS to be used to lookup services for a wide variety
   of resource names (including URIs) which are not in domain name
   syntax.  Reasons for doing this range from URN Resource Discovery
   Systems to moving out-of-date services to new domains.

   This document updates the portions of RFC 2168 specifically dealing
   with the definition of the NAPTR records and how other, non-URI
   specific applications, might use NAPTR.









Mealling & Daniel           Standards Track                     [Page 1]

RFC 2915                      NAPTR DNS RR                September 2000


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18

1. Introduction

   This RR was originally produced by the URN Working Group [3] 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.

   The function of rewriting a string according to the rules in a record
   has usefulness in several different applications.  This document
   defines the basic assumptions to which all of those applications must
   adhere to.  It does not define the reasons the rewrite is used, what
   the expected outcomes are, or what they are used for.  Those are
   specified by applications that define how they use the NAPTR record
   and algorithms within their contexts.

   Flags and other fields are also specified in the RR to control the
   rewrite procedure in various ways or to provide information on how to
   communicate with the host at the domain name that was the result of
   the rewrite.





Mealling & Daniel           Standards Track                     [Page 2]

RFC 2915                      NAPTR DNS RR                September 2000


   The final result is a RR that has several fields that interact in a
   non-trivial but implementable way.  This document specifies those
   fields and their values.

   This document does not define applications that utilizes this rewrite
   functionality. Instead it specifies just the mechanics of how it is
   done.  Why its done, what the rules concerning the inputs, and the
   types of rules used are reserved for other documents that fully
   specify a particular application.  This separation is due to several
   different applications all wanting to take advantage of the rewrite
   rule lookup process.  Each one has vastly different reasons for why
   and how it uses the service, thus requiring that the definition of
   the service be generic.

      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 RFC 2119.

      All references to Uniform Resource Identifiers in this document
      adhere to the 'absoluteURI' production of the "Collected ABNF"
      found in RFC 2396 [9].  Specifically, the semantics of URI
      References do not apply since the concept of a Base makes no sense
      here.

2. NAPTR RR Format

   The format of the NAPTR RR is given below.  The DNS type code [1] for
   NAPTR is 35.

   Domain TTL Class Type Order Preference Flags Service Regexp
   Replacement

   Domain
      The domain name to which this resource record refers.  This is the
      'key' for this entry in the rule database.  This value will either
      be the first well known key (<something>.uri.arpa for example) or
      a new key that is the output of a replacement or regexp rewrite.
      Beyond this, it has the standard DNS requirements [1].

   TTL
      Standard DNS meaning [1].

   Class
      Standard DNS meaning [1].

   Type
      The Type Code [1] for NAPTR is 35.




Mealling & Daniel           Standards Track                     [Page 3]

RFC 2915                      NAPTR DNS RR                September 2000


   Order
      A 16-bit unsigned integer specifying the order in which the NAPTR
      records MUST be processed to ensure the correct ordering of
      rules.  Low numbers are processed before high numbers, and once a
      NAPTR is found whose rule "matches" the target, the client MUST
      NOT consider any NAPTRs with a higher value for order (except as
      noted below for the Flags field).

   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 the preferred protocol or service.

      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.

      At this time only four flags, "S", "A", "U", and "P", are
      defined.  The "S", "A" and "U" flags denote a terminal lookup.
      This means that this NAPTR record is the last one and that the
      flag determines what the next stage should be.  The "S" flag
      means that the next lookup should be for SRV records [4].  See
      Section 5 for additional information on how NAPTR uses the SRV
      record type.  "A" means that the next lookup should be for either
      an A, AAAA, or A6 record.  The "U" flag means that the next step
      is not a DNS lookup but that the output of the Regexp field is an
      URI that adheres to the 'absoluteURI' production found in the
      ABNF of RFC 2396 [9].  Since there may be applications that use
      NAPTR to also lookup aspects of URIs, implementors should be
      aware that this may cause loop conditions and should act
      accordingly.






Mealling & Daniel           Standards Track                     [Page 4]

RFC 2915                      NAPTR DNS RR                September 2000


      The "P" flag says that the remainder of the application side
      algorithm shall be carried out in a Protocol-specific fashion.
      The new set of rules is identified by the Protocol specified in
      the Services field.  The record that contains the 'P' flag is the
      last record that is interpreted by the rules specified in this
      document.  The new rules are dependent on the application for
      which they are being used and the protocol specified.  For
      example, if the application is a URI RDS and the protocol is WIRE
      then the new set of rules are governed by the algorithms
      surrounding the WIRE HTTP specification and not this document.

      The remaining alphabetic flags are reserved for future versions
      of the NAPTR specification.  The numeric flags may be used for
      local experimentation.  The S, A, U and P flags are all mutually
      exclusive, and resolution libraries MAY signal an error if more
      than one is given.  (Experimental code and code for assisting in
      the creation of NAPTRs would be more likely to signal such an
      error than a client such as a browser).  It is anticipated that
      multiple flags will be allowed in the future, so implementers
      MUST NOT assume that the flags field can only contain 0 or 1
      characters.  Finally, if a client encounters a record with an
      unknown flag, it MUST ignore it and move to the next record.  This
      test takes precedence even over the "order" field.  Since flags
      can control the interpretation placed on fields, a novel flag
      might change the interpretation of the regexp and/or replacement
      fields such that it is impossible to determine if a record
      matched a given target.

      The "S", "A", and "U"  flags are called 'terminal' flags since
      they halt the looping rewrite algorithm.  If those flags are not
      present, clients may assume that another NAPTR RR exists at the
      domain name produced by the current rewrite rule.  Since the "P"
      flag specifies a new algorithm, it may or may not be 'terminal'.
      Thus, the client cannot assume that another NAPTR exists since
      this case is determined elsewhere.

      DNS servers MAY interpret these flags and values and use that
      information to include appropriate SRV and A,AAAA, or A6 records
      in the additional information portion of the DNS packet.  Clients
      are encouraged to check for additional information but are not
      required to do so.

   Service
      Specifies the service(s) available down this rewrite path.  It may
      also specify the particular protocol that is used to talk with a
      service.  A protocol MUST be specified if the flags field states
      that the NAPTR is terminal.  If a protocol is specified, but the
      flags field does not state that the NAPTR is terminal, the next



Mealling & Daniel           Standards Track                     [Page 5]

RFC 2915                      NAPTR DNS RR                September 2000


      lookup MUST be for a NAPTR.  The client MAY choose not to perform
      the next lookup if the protocol is unknown, but that behavior
      MUST NOT be relied upon.

      The service field may take any of the values below (using the
      Augmented BNF of RFC 2234 [5]):

                 service_field = [ [protocol] *("+" rs)]
                 protocol      = ALPHA *31ALPHANUM
                 rs            = ALPHA *31ALPHANUM
                 ; The protocol and rs fields are limited to 32
                 ; characters and must start with an alphabetic.

      For example, an optional protocol specification followed by 0 or
      more resolution services.  Each resolution service is indicated by
      an initial '+' character.

      Note that the empty string is also a valid service field.  This
      will typically be seen at the beginning of a series of rules,
      when it is impossible to know what services and protocols will be
      offered by a particular service.

      The actual format of the service request and response will be
      determined by the resolution protocol, and is the subject for
      other documents.  Protocols need not offer all services.  The
      labels for service requests shall be formed from the set of
      characters [A-Z0-9].  The case of the alphabetic characters is
      not significant.

      The list of "valid" protocols for any given NAPTR record is any
      protocol that implements some or all of the services defined for
      a NAPTR application.  Currently, THTTP [6] is the only protocol
      that is known to make that claim at the time of publication.  Any
      other protocol that is to be used must have documentation
      specifying:

      *  how it implements the services of the application

      *  how it is to appear in the NAPTR record (i.e., the string id
         of the protocol)

      The list of valid Resolution Services is defined by the documents
      that specify individual NAPTR based applications.

      It is worth noting that the interpretation of this field is
      subject to being changed by new flags, and that the current
      specification is oriented towards telling clients how to talk
      with a URN resolver.



Mealling & Daniel           Standards Track                     [Page 6]