One document matched: draft-yamamoto-naptr-service-discovery-00.txt

Internet Engineering Task Force                              S. Yamamoto
INTERNET-DRAFT                                                 H. Yokata
Jul 6, 2004                                                KDDI R&D Labs 
Expires Jan 5, 2005                                          C. Williams
                                                           KDDI Labs USA
                                                               A. Durand
                                                  Sun Microsystems, Inc.




             Service Discovery using NAPTR records in DNS
            <draft-yamamoto-naptr-service-discovery-00.txt>




Status of this Memo



   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


   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 a "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html"



Abstract


   This document describes a method to store and retrieve local
   configuration information from the DNS using NAPTR records in the
   reverse path DNS tree.  It works for both IPv4 in-addr.arpa and IPv6
   ip6.arpa.




1. Introduction


   DHCP is the protocol of choice to pass configuration information and
   perform service discovery in well defined environment. However,
   defining and getting new options for DHCP is a slow process, as it
   requires not only standardization steps but also need to be
   implemented in all potential clients and server.


   This memo proposes a new approach based on NAPTR records in the
   reverse path tree of the DNS. Defining new options for experimental
   purposes can be done with very little to no code change in the
   clients and none on the server.


   This protocol can be deployed independently of DHCP and only requires
   the operation of a regular DNS server.


   This protocol is also suitable when the administrative authority who
   manages the service is different from the administrative authority
   who manages DHCP. This is true in particular in deployment using NAT
   where the NAT box act as a local DHCP server and is usually not
   configured (or cannot be configured) to get the missing data from an
   upstream DHCP server.


   Using the reverse path DNS tree instead of the forward path DNS tree
   has two major advantages:
      - it does not require to reserve any label,
      - it matches nicely the underlying topology.




2. NAPTR Record


2.1 NAPTR


   NAPTR records are defined in RFC3403 [1]. The format of the NAPTR RR,
   whose DNS type code is 35, is:


      NAPTR order        16 bits
            preference   16 bits
            flags        character-string
            service      character-string
            regexp       character-string
            replacement  domain-name


2.2 Defining Services


   When defining a new type of configuration or a new service to be
   discovered, one has only to standardize the different relevant NAPTR
   parameters, the most important being the name of the "service" tag.
   For the sake of illustration, the following services are defined.


2.2.1 Isatap


   The isatap router service discovery within a site can be done using
   the following record:


      flags = "",
      service = "isatap",
      regexp =  "",
      replacement = Fully Qualified Domain Name of the isatap router


   For example:


      flags = "",
      service = "isatap",
      regexp =  "",
      replacement = "r21.example.com"



2.2.2 Tunnel Broker


   The Tunnel Broker discovery within an ISP can be done using the
   following record:


      flags = "",
      service = "TB",
      regexp =  "",
      replacement = Fully Qualified Domain Name of the Tunnel Broker


   For example:


      flags = "",
      service = "TB",
      regexp =  "",
      replacement = "tb.example.com"



2.3 Populating the DNS


   The administrative authority in charge of the service to be
   discovered using this method will populate the reverse path DNS tree
   associated to the address space it controls with the relevant
   records.


   For example, a site deploying isatap will put isatap NAPTR records
   for every single node of the site in the reverse path DNS tree in the
   form:


   9.1.6.10.in-addr.arpa. 0 IN NAPTR 10 10 "" isatap "" r21.example.com


   In another example, an ISP deploying a tunnel broker service will put
   TB NAPRT records for every single node in the reverse path DNS tree
   for all its customers in the form:


   9.1.6.1.in-addr.arpa. 0 IN NAPTR 10 10 "" TB "" tb.example.com


   The administrative entity in charge of the reverse path DNS tree can
   use several methods to populate the tree with NATPR records. It can
   use scripts to generate the zone, use wildcards or use some extension
   to the auto-generation methods present in most DNS servers.


   When wildcard are used, they are only working on the last level of
   delegation. That is, if there is a zone delegated under the zone
   where the wildcard is placed, that zone won't be covered by the
   wildcard. In practice, this means putting a wildcard in every
   terminating zone. This is not a problem in the reverse tree, as those
   zones usually already exist at the subnet boundaries for the PTR
   records and are most of the time populated via scripts.  Note that
   using wildcards does not prevent to populate more specific address
   with different NAPTR records, as long as they are on the same zone.


   When a very large number of NAPTR records have to be generated, an
   alternative to wildcards is to have the DNS server dynamically
   generate the corresponding records on demand according to predefined
   rules.


   The entire tree does not have to be populated. An ISP could, for
   example, only populate the records for tunnel brokers for the IP
   addresses of its customers who actually subscribed for the service.


   Note:


   When several services are to be discovered using this method, several
   NAPTR records would be created per node in the reverse path DNS tree
   representing an IP address, as many as the number of services to be
   discovered. It is actually possible to have several NAPRT records for
   the same service, the quering host would then decide which one(s) to
   use.



3. Discovering Services


   When a client node wants to discover a given service, it creates a
   corresponding NAPRT DNS query for its IP address and send it as a
   regular DNS query.  For example, the node 10.6.1.9 trying to discover
   its isatap router will send the following query:


      query(type=NAPTR, node=9.1.6.10.in-addr.arpa.)


   and then filter all the responses to retain those which service field
   is equal to "isatap". The fully qualified domain name (FQDN) of the
   isatap router to use will be contained in the replacement fields.
   Note: several NAPTR records could match, and then the node will end
   up with as many potential isatap routers to try. Mapping this FQDN to
   an IP address will required a supplementary DNS request for an A
   record for that FQDN.


   A similar algorithm can be used by clients willing to discover their
   ISP tunnel broker. The NAPTR query would be the same, but this time,
   the client will filter the responses to retain those which service
   field is equal to "TB"



4. Operational Considerations


   This methods works well when finding the name of a server is enough
   to complete the service discovery bootstrap phase. As most of the
   time the DNS data is publicly readable, no sensitive data should be
   place within those NAPTR records.


   DNS administrator concerned about not revealing to the outside world
   details about their internal service configuration can use two face
   DNS servers to only server those NAPTR records internally.


   In the case where NAT and private address space are expected to be
   used, the administrative authority in charge of the service to be
   discovered can pre-populate the RFC1918 [2] private address space
   with the relevant NAPTR records.




5. IANA Considerations


   The definition of NAPTR service fields should be standardized at IETF
   and recorded with IANA. A special category should be created for
   that. Service fields used in this memo are there only to server as
   examples an in no way should be used like this.





6. Security Considerations


   Administrator concerned about the security of the discovery mechanism
   discussed here should deploy DNSsec [3]. Limiting the propagation of
   DNS data linked to this mechanism to "internal" customers as
   described in section 4 is also a good way to limit security risks.
   Also, as DNS data always end up leaking, one should refrain from
   placing sensitive information in the DNS.




7. Authors Addresses


   Shu Yamamoto
   Hidetoshi Yokota
   KDDI R&D Labs
   Kamifukuoka-Shi
   Saitama 356-8502
   Japan
   EMail: shu@kddilabs.jp


   Carl Williams
   KDDI Labs USA
   Palo Alto, CA 94301
   USA
   Phone: +1.650.279.5903
   EMail: carlw@kddilabs.com


   Hidetoshi Yokota
   KDDI R&D Labs
   Kamifukuoka-Shi
   Saitama 356-8502
   Japan
   Phone: 81 (49) 278-7894
   EMail: yokota@kddlabs.co.jp


   Alain Durand
   SUN Microsystems, Inc
   USA
   Mail: Alain.Durand@sun.com





8. Normative References


   [1] RFC3403. Dynamic Delegation Discovery System (DDDS) Part Three:
       The Domain Name System (DNS) Database. M. Mealling. October 2002.





8. Informative References


   [2] RFC1918. Address Allocation for Private Internets. Y. Rekhter, B.
       Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996.


   [3] RFC2535. Domain Name System Security Extensions. D. Eastlake 3rd.
       March 1999.




10. Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.