rfc2915.txt

bind 9.3结合mysql数据库

7.3 Example 3

   A non-URI example is the ENUM application which uses a NAPTR record
   to map an e.164 telephone number to a URI.  In order to convert the
   phone number to a domain name for the first iteration all characters
   other than digits are removed from the the telephone number, the
   entire number is inverted, periods are put between each digit and the
   string ".e164.arpa" is put on the left-hand side.  For example, the
   E.164 phone number "[phone]" converted to a domain-name it
   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."

   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:[e-mail]!"     .
 IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:[e-mail]!"  .

   This application uses the same 'u' flag as the URI Resolution
   application. 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
   field except that it defines the 'E2U' service instead of the 'I2*'
   services that URI resolution uses.  The example above states that the
   available protocols used to access that telephone's service are
   either the Session Initiation Protocol or SMTP mail.

8. DNS Packet Format

         The packet format for the NAPTR record is:

                                          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                  /
          /                                               /
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+




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


    where:

   FLAGS A <character-string> which contains various flags.

   SERVICES A <character-string> which contains protocol and service
      identifiers.

   REGEXP A <character-string> which contains a regular expression.

   REPLACEMENT A <domain-name> which specifies the new value in the
      case where the regular expression is a simple replacement
      operation.

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

9. 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
   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.

10. 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.

   The "a" flag allows the next lookup to be for address records (A,
   AAAA, A6) rather than SRV records.  Since there is no place for a
   port specification in the NAPTR record, when the "A" flag is used the
   specified protocol must be running on its default port.

   The URN Syntax draft defines a canonical form for each URN, which
   requires %encoding characters outside a limited repertoire.  The
   regular expressions MUST be written to operate on that canonical
   form.  Since international character sets will end up with extensive
   use of %encoded characters, regular expressions operating on them
   will be essentially impossible to read or write by hand.





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


11. Notes

   o  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.

   o  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.

   o  If the lookup after a rewrite fails, clients are strongly
      encouraged to report a failure, rather than backing up to pursue
      other rewrite paths.

   o  Note that SRV RRs impose additional requirements on clients.

12. IANA Considerations

   The only registration function that impacts the IANA is for the
   values that are standardized for the Services and Flags fields.  To
   extend the valid values of the Flags field beyond what is specified
   in this document requires a published specification that is approved
   by the IESG.

   The values for the Services field will be determined by the
   application that makes use of the NAPTR record.  Those values must be
   specified in a published specification and approved by the IESG.

13. Security Considerations

   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 service, but has not
   discussed any detail of how the communication with that service takes
   place.  There are significant security considerations attached to the



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


   communication with a service.  Those considerations are outside the
   scope of this document, and must be addressed by the specifications
   for particular communication protocols.

14. Acknowledgments

   The editors would like to thank Keith Moore for all his consultations
   during the development of this memo.  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]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

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

   [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]  Daniel, R., "A Trivial Convention for using HTTP in URN
        Resolution", RFC 2169, June 1997.

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

   [8]  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.

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







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


Authors' Addresses

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

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.netsol.com


   Ron Daniel
   DATAFUSION, Inc.
   139 Townsend Street, Ste. 100
   San Francisco, CA  94107
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.datafusion.net





























Mealling & Daniel           Standards Track                    [Page 17]

RFC 2915                      NAPTR DNS RR                September 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 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 & Daniel           Standards Track                    [Page 18]