idnits 2.17.1 draft-durand-naptr-service-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 270. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 370 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 10 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 79 has weird spacing: '...acement domai...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Apr 18, 2005) is 6947 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Durand 2 INTERNET-DRAFT Sun Microsystems, Inc. 3 Oct 17, 2004 4 Expires Apr 18, 2005 6 Service Discovery using NAPTR records in DNS 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html" 32 Abstract 34 This document describes a method to store and retrieve local 35 configuration information from the DNS using NAPTR records in the 36 reverse path DNS tree. It works for both IPv4 in-addr.arpa and IPv6 37 ip6.arpa. 39 1. Introduction 41 DHCP is the protocol of choice to pass configuration information and 42 perform service discovery in well defined environment. However, 43 defining and getting new options for DHCP is a slow process, as it 44 requires not only standardization steps but also need to be 45 implemented in all potential clients and server. 47 This memo proposes a new approach based on NAPTR records in the 48 reverse path tree of the DNS. Defining new options for experimental 49 purposes can be done with very little to no code change in the 50 clients and none on the server. 52 This protocol can be deployed independently of DHCP and only requires 53 the operation of a regular DNS server. 55 This protocol is also suitable when the administrative authority who 56 manages the service is different from the administrative authority 57 who manages DHCP. This is true in particular in deployment using NAT 58 where the NAT box act as a local DHCP server and is usually not 59 configured (or cannot be configured) to get the missing data from an 60 upstream DHCP server. 62 Using the reverse path DNS tree instead of the forward path DNS tree 63 has two major advantages: 64 - it does not require to reserve any label, 65 - it matches nicely the underlying topology. 67 2. NAPTR Record 69 2.1 NAPTR 71 NAPTR records are defined in RFC3403 [1]. The format of the NAPTR RR, 72 whose DNS type code is 35, is: 74 NAPTR order 16 bits 75 preference 16 bits 76 flags character-string 77 service character-string 78 regexp character-string 79 replacement domain-name 81 2.2 Defining Services 83 When defining a new type of configuration or a new service to be 84 discovered, one has only to standardize the different relevant NAPTR 85 parameters, the most important being the name of the "service" tag. 86 For the sake of illustration, the following services are defined. 88 2.2.1 Isatap 90 The isatap router service discovery within a site can be done using 91 the following record: 93 flags = "", 94 service = "isatap", 95 regexp = "", 96 replacement = Fully Qualified Domain Name of the isatap router 98 For example: 100 flags = "", 101 service = "isatap", 102 regexp = "", 103 replacement = "r21.example.com" 105 2.2.2 Tunnel Broker 107 The Tunnel Broker discovery within an ISP can be done using the 108 following record: 110 flags = "", 111 service = "TB", 112 regexp = "", 113 replacement = Fully Qualified Domain Name of the Tunnel Broker 115 For example: 117 flags = "", 118 service = "TB", 119 regexp = "", 120 replacement = "tb.example.com" 122 2.3 Populating the DNS 124 The administrative authority in charge of the service to be 125 discovered using this method will populate the reverse path DNS tree 126 associated to the address space it controls with the relevant 127 records. 129 For example, a site deploying isatap will put isatap NAPTR records 130 for every single node of the site in the reverse path DNS tree in the 131 form: 133 9.1.6.10.in-addr.arpa. 0 IN NAPTR 10 10 "" isatap "" r21.example.com 135 In another example, an ISP deploying a tunnel broker service will put 136 TB NAPRT records for every single node in the reverse path DNS tree 137 for all its customers in the form: 139 9.1.6.1.in-addr.arpa. 0 IN NAPTR 10 10 "" TB "" tb.example.com 141 The administrative entity in charge of the reverse path DNS tree can 142 use several methods to populate the tree with NATPR records. It can 143 use scripts to generate the zone, use wildcards or use some extension 144 to the auto-generation methods present in most DNS servers. 146 When wildcard are used, they are only working on the last level of 147 delegation. That is, if there is a zone delegated under the zone 148 where the wildcard is placed, that zone won't be covered by the 149 wildcard. In practice, this means putting a wildcard in every 150 terminating zone. This is not a problem in the reverse tree, as those 151 zones usually already exist at the subnet boundaries for the PTR 152 records and are most of the time populated via scripts. Note that 153 using wildcards does not prevent to populate more specific address 154 with different NAPTR records, as long as they are on the same zone. 156 When a very large number of NAPTR records have to be generated, an 157 alternative to wildcards is to have the DNS server dynamically 158 generate the corresponding records on demand according to predefined 159 rules. 161 The entire tree does not have to be populated. An ISP could, for 162 example, only populate the records for tunnel brokers for the IP 163 addresses of its customers who actually subscribed for the service. 165 Note: 167 When several services are to be discovered using this method, several 168 NAPTR records would be created per node in the reverse path DNS tree 169 representing an IP address, as many as the number of services to be 170 discovered. It is actually possible to have several NAPRT records for 171 the same service, the quering host would then decide which one(s) to 172 use. 174 3. Discovering Services 176 When a client node wants to discover a given service, it creates a 177 corresponding NAPRT DNS query for its IP address and send it as a 178 regular DNS query. For example, the node 10.6.1.9 trying to discover 179 its isatap router will send the following query: 181 query(type=NAPTR, node=9.1.6.10.in-addr.arpa.) 183 and then filter all the responses to retain those which service field 184 is equal to "isatap". The fully qualified domain name (FQDN) of the 185 isatap router to use will be contained in the replacement fields. 186 Note: several NAPTR records could match, and then the node will end 187 up with as many potential isatap routers to try. Mapping this FQDN to 188 an IP address will required a supplementary DNS request for an A 189 record for that FQDN. 191 A similar algorithm can be used by clients willing to discover their 192 ISP tunnel broker. The NAPTR query would be the same, but this time, 193 the client will filter the responses to retain those which service 194 field is equal to "TB" 196 4. Operational Considerations 198 This methods works well when finding the name of a server is enough 199 to complete the service discovery bootstrap phase. As most of the 200 time the DNS data is publicly readable, no sensitive data should be 201 place within those NAPTR records. 203 DNS administrator concerned about not revealing to the outside world 204 details about their internal service configuration can use two face 205 DNS servers to only server those NAPTR records internally. 207 Great care should be used when choosing a TTL value for the NAPTR value. 208 In first approach, a value similar as the one given to DHCP lease makes 209 sense. 211 As the right hand side of the NATPR record format suggested here are names, 212 DNS servers can be easily modified to return the A record associated 213 to those names in the additional section, the same way this is done with CNAME. 214 That would speed-up the resolution process, as one query/response 215 will be enough instead of two. 217 In the case where NAT and private address space are expected to be 218 used, the administrative authority in charge of the service to be 219 discovered can pre-populate the RFC1918 [2] private address space 220 with the relevant NAPTR records. 222 5. IANA Considerations 224 The definition of NAPTR service fields should be standardized at IETF 225 and recorded with IANA. A special category should be created for 226 that. Service fields used in this memo are there only to server as 227 examples an in no way should be used like this. 229 6. Security Considerations 231 Administrator concerned about the security of the discovery mechanism 232 discussed here should deploy DNSsec [3]. Limiting the propagation of 233 DNS data linked to this mechanism to "internal" customers as 234 described in section 4 is also a good way to limit security risks. 235 Also, as DNS data always end up leaking, one should refrain from 236 placing sensitive information in the DNS. 238 7. Authors Addresses 240 Alain Durand 241 SUN Microsystems, Inc 242 USA 243 Mail: Alain.Durand@sun.com 245 8. Normative References 247 [1] RFC3403. Dynamic Delegation Discovery System (DDDS) Part Three: 248 The Domain Name System (DNS) Database. M. Mealling. October 2002. 250 8. Informative References 252 [2] RFC1918. Address Allocation for Private Internets. Y. Rekhter, B. 253 Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. 255 [3] RFC2535. Domain Name System Security Extensions. D. Eastlake 3rd. 256 March 1999. 258 10. Copyright Statement 260 Copyright (C) The Internet Society (2004). This document is subject 261 to the rights, licenses and restrictions contained in BCP 78, and 262 except as set forth therein, the authors retain all their rights. 264 This document and the information contained herein are provided on an 265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 267 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 268 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 269 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.