idnits 2.17.1 draft-daigle-snaptr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 22) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 586 has weird spacing: '...example exam...' -- 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 (June 29, 2004) is 7240 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 normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 3401 (ref. '4') ** Obsolete normative reference: RFC 2434 (ref. '7') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '8') (Obsoleted by RFC 3986) == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-dreg-06 == Outdated reference: A later version (-07) exists of draft-ietf-crisp-iris-beep-04 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-06 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Daigle 2 Internet-Draft A. Newton 3 Expires: December 28, 2004 VeriSign, Inc. 4 June 29, 2004 6 Domain-based Application Service Location Using SRV RRs and the 7 Dynamic Delegation Discovery Service (DDDS) 8 draft-daigle-snaptr-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on December 28, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo defines a generalized mechanism for application service 40 naming that allows service location without relying on rigid domain 41 naming conventions (so-called name hacks). The proposal defines a 42 Dynamic Delegation Discovery System (DDDS) Application to map domain 43 name, application service name, and application protocol to target 44 server and port, dynamically. 46 [Note to be removed for RFC publication: this work was originally 47 referred to as "napstr", and draft-daigle-napstr-04 is the immediate 48 precursor of draft-daigle-snaptr-00.] 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 4 54 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . 5 56 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . 5 57 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . 6 58 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . 6 59 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . 6 60 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . 7 61 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1 Guidelines for Application Protocol Developers . . . . . . 7 63 3.1.1 Registration of application service and protocol 64 tags . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.2 Definition of conditions for retry/failure . . . . . . 8 66 3.1.3 Server identification and handshake . . . . . . . . . 9 67 3.2 Guidelines for Domain Administrators . . . . . . . . . . . 9 68 3.3 Guidelines for Client Software Writers . . . . . . . . . . 9 69 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.2 Service Discovery within a Domain . . . . . . . . . . . . 10 72 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . 11 73 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 12 74 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . 13 75 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . 14 76 5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 15 77 5.1 So, why not just SRV records? . . . . . . . . . . . . . . 15 78 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . 16 79 6. Formal Definition of 80 Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16 81 6.1 Application Unique String . . . . . . . . . . . . . . . . 17 82 6.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 17 83 6.3 Expected Output . . . . . . . . . . . . . . . . . . . . . 17 84 6.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.5 Service Parameters . . . . . . . . . . . . . . . . . . . . 17 86 6.5.1 Application Services . . . . . . . . . . . . . . . . . 18 87 6.5.2 Application Protocols . . . . . . . . . . . . . . . . 18 88 6.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . 18 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 7.1 Application Service Tag IANA Registry . . . . . . . . . . 19 92 7.2 Application Protocol Tag IANA Registry . . . . . . . . . . 19 93 7.3 Registration Process . . . . . . . . . . . . . . . . . . . 19 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 98 10.2 Informative References . . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 100 A. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . . 22 101 A.1 Finding the first (best) target . . . . . . . . . . . . . 22 102 A.2 Finding subsequent targets . . . . . . . . . . . . . . . . 23 103 B. Availability of Sample Code . . . . . . . . . . . . . . . . . 24 104 Intellectual Property and Copyright Statements . . . . . . . . 25 106 1. Introduction 108 This memo defines a generalized mechanism for application service 109 naming that allows service location without relying on rigid domain 110 naming conventions (so-called name hacks). The proposal defines a 111 Dynamic Delegation Discovery System (DDDS -- see [4]) Application to 112 map domain name, application service name, and application protocol 113 to target server and port, dynamically. 115 As discussed in Section 5, existing approaches to using DNS records 116 to dynamically determining the current host for a given application 117 service are limited in terms of the use cases supported. To address 118 some of the limitations, this document defines a DDDS Application to 119 map service+protocol+domain to specific server addresses using both 120 NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as 121 a more general version of the use of SRV and/or a very restricted 122 application of the use of NAPTR resource records. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC2119 ([1]). 128 2. Straightforward-NAPTR (S-NAPTR) Specification 130 The precise details of the specification of this DDDS application are 131 given in Section 6. This section defines the usage of the DDDS 132 application. 134 2.1 Key Terms 136 An "application service" is a generic term for some type of 137 application, indpendent of the protocol that may be used to offer it. 138 Each application service will be associated with an IANA-registered 139 tag. For example, retrieving mail is a type of application service, 140 which can be implemented by different application-layer protocols 141 (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered 142 for it. (N.B.: this has not been done, and there are no plans to do 143 so at the time of this writing). 145 An "application protocol" is used to implement the application 146 service. These are also associated with IANA-registered tags. Using 147 the mail example above, "POP3" and "IMAP4" could be registered as 148 application protocol tags. In the case where multiple transports are 149 available for the application, separate tags should be defined for 150 each transport. 152 The intention is that the combination of application service and 153 protocol tags should be specific enough that finding a known pair 154 (e.g., "RetMail:POP3" is sufficient for a client to identify a server 155 with which it can communicate. 157 Some protocols support multiple application services. For example, 158 LDAP is an application protocol, and can be found supporting various 159 services (e.g., "whitepages", "directory enabled networking", etc). 161 2.2 S-NAPTR DDDS Application Usage 163 As defined in Section 6, NAPTR records are used to store application 164 service+protocol information for a given domain. Following the DDDS 165 standard, these records are looked up, and the rewrite rules 166 (contained in the NAPTR records) are used to determine the successive 167 DNS lookups, until a desirable target is found. 169 For the rest of this section, refer to the set of NAPTR resource 170 records for example.com shown in the figure below, where "WP" is the 171 imagined application service tag for "white pages", and "EM" is the 172 application service tag for an imagined "Extensible Messaging" 173 application service. 175 example.com. 176 ;; order pref flags 177 IN NAPTR 100 10 "" "WP:whois++" ( ; service 178 "" ; regexp 179 bunyip.example. ; replacement 180 ) 181 IN NAPTR 100 20 "s" "WP:ldap" ( ; service 182 "" ; regexp 183 _ldap._tcp.myldap.example.com. ; replacement 184 ) 185 IN NAPTR 200 10 "" "EM:protA" ( ; service 186 "" ; regexp 187 someisp.example. ; replacement 188 ) 189 IN NAPTR 200 30 "a" "EM:protB" ; service 190 "" ; regexp 191 myprotB.example.com.; replacement 192 ) 194 2.2.1 Ordering and Preference 196 A client retrieves all of the NAPTR records associated with the 197 target domain name (example.com, above). These are to be sorted in 198 terms of increasing ORDER, and increasing PREF within each ORDER. 200 2.2.2 Matching and non-Matching NAPTR Records 202 Starting with the first sorted NAPTR record, the client examines the 203 SERVICE field to find a match. In the case of the S-NAPTR DDDS 204 application, that means a SERVICE field that includes the tags for 205 the desired application service and a supported application protocol. 207 If more than one NAPTR record matches, they are processed in 208 increasing sort order. 210 2.2.3 Terminal and Non-Terminal NAPTR Records 212 A NAPTR record with an empty FLAG field is "non-terminal". That is, 213 more NAPTR RR lookups are to be performed. Thus, to process a NAPTR 214 record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is 215 used as the target of the next DNS lookup -- for NAPTR RRs. 217 In S-NAPTR, the only terminal flags are "S" and "A". These are 218 called "terminal" NAPTR lookups because they denote the end of the 219 DDDS/NAPTR processing rules. In the case of an "S" flag, the 220 REPLACEMENT field is used as the target of a DNS query for SRV RRs, 221 and normal SRV processing is applied. In the case of an "A" flag, an 222 address record is sought for the REPLACEMENT field target (and the 223 default protocol port is assumed). 225 2.2.4 S-NAPTR and Successive Resolution 227 As shown in the example NAPTR RR set above, it is possible to have 228 multiple possible targets for a single application service+protocol 229 pair. These are to be pursued in order until a server is 230 successfully contacted or all possible matching NAPTR records have 231 been successively pursued to terminal lookups and servers contacted. 232 That is, a client must backtrack and attempt other resolution paths 233 in the case of failure. 235 "Failure" is declared, and backtracking must be used when 237 o the designated remote server (host and port) fail to provide 238 appropriate security credentials for the *originating* domain 239 o connection to the designated remote server otherwise fails -- the 240 specifics terms of which are defined when an application protocol 241 is registered 242 o the S-NAPTR-designated DNS lookup fails to yield expected results 243 -- e.g., no A RR for an "A" target, no SRV record for an "S" 244 target, or no NAPTR record with appropriate application service 245 and protocol for a NAPTR lookup. Except in the case of the very 246 first NAPTR lookup, this last is a configuration error: the fact 247 that example.com has a NAPTR record pointing to "bunyip.example" 248 for the "WP:Whois++" service and protocol means the administrator 249 of example.com believes that service exists. If bunyip.example 250 has no "WP:Whois++" NAPTR record, the application client MUST 251 backtrack and try the next available "WP:Whois++" option from 252 example.com. As there is none, the whole resolution fails. 254 An application client first queries for the NAPTR RRs for the domain 255 of a named application service. The application client MUST select 256 one protocol to choose The PREF field of the NAPTR RRs may be used by 257 the domain administrator to The first DNS query is for the NAPTR RRs 258 in the original target domain (example.com, above). 260 2.2.5 Clients Supporting Multiple Protocols 262 In the case of an application client that supports more than one 263 protocol for a given application service, it MUST pursue S-NAPTR 264 resolution completely for one protocol, exploring all potential 265 terminal lookups in PREF and ORDER ranking, until the application 266 connects successfully or there are no more possibilities for that 267 protocol. 269 That is, what the client MUST NOT do is start looking for one 270 protocol, observe that a successive NAPTR RR set supports another of 271 its preferred protocols, and continue the S-NAPTR resolution based on 272 that protocol. For example, even if someisp.example offers the "EM" 273 service with protocol "ProtB", there is no reason to believe it does 274 so on behalf of example.com (since there is no such pointer in 275 example.com's NAPTR RR set). 277 It MAY choose which protocol to try first based on its own 278 preference, or from the PREF ranking in the first set of NAPTR 279 records (i.e., those for the target named domain). However, the 280 chosen protocol MUST be listed in that first NAPTR RR set. 282 It MAY choose to run simultaneous DDDS resolutions for more than one 283 protocol, in which case the requirements above apply for each 284 protocol independently. That is, do not switch protocols 285 mid-resolution. 287 3. Guidelines 289 3.1 Guidelines for Application Protocol Developers 291 The purpose of S-NAPTR is to provide application standards developers 292 with a more powerful framework (than SRV RRs alone) for naming 293 service targets, without requiring each application protocol (or 294 service) standard to define a separate DDDS application. 296 Note that this approach is intended specifically for use when it 297 makes sense to associate services with particular domain names (e.g., 298 e-mail addresses, SIP addresses, etc). A non-goal is having all 299 manner of label mapped into domain names in order to use this. 301 Specifically not addressed in this document is how to select the 302 domain for which the service+protocol is being sought. It is up to 303 other conventions to define how that might be used (e.g., new 304 messaging standards can define what domain to use from their URIs, 305 how to step down from foobar.example.com to example.com, and so on, 306 if that is applicable). 308 Although this document proposes a DDDS application that does not use 309 all the features of NAPTR resource records, it does not mean to imply 310 that DNS resolvers should fail to implement all aspects of the NAPTR 311 RR standard. A DDDS application is a client use convention. 313 The rest of this section outlines the specific elements that protocol 314 developers must determine and document in order to make use of 315 S-NAPTR. 317 3.1.1 Registration of application service and protocol tags 319 Application protocol developers that wish to make use of S-NAPTR must 320 make provision to register any relevant application service and 321 application protocol tags, as described in Section 7. 323 3.1.2 Definition of conditions for retry/failure 325 One other important aspect that must be defined is the expected 326 behaviour for interacting with the servers that are reached via 327 S-NAPTR. Specifically, under what circumstances should the client 328 retry a target that was found via S-NAPTR? What should it consider a 329 failure that causes it to return to the S-NAPTR process to determine 330 the next serviceable target (a less preferred target)? 332 For example, if the client gets a "connection refused" from a server, 333 should it retry for some (protocol-dependent) period of time? Or, 334 should it try the next-preferred target in the S-NAPTR chain of 335 resolution? Should it only try the next-preferred target if it 336 receives a protocol-specific permanent error message? 338 The most important thing is to select one expected behaviour and 339 document it as part of the use of S-NAPTR. 341 As noted earlier, failure to provide appropriate credentials to 342 identify the server as being authoritative for the original taret 343 domain is always considered a failure condition. 345 3.1.3 Server identification and handshake 347 As noted in Section 8, use of the DNS for server location increases 348 the importance of using protocol-specific handshakes to determine and 349 confirm the identity of the server that is eventually reached. 351 Therefore, application protocol developers using S-NAPTR should 352 identify the mechanics of the expected identification handshake when 353 the client connects to a server found through S-NAPTR. 355 3.2 Guidelines for Domain Administrators 357 Although S-NAPTR aims to provide a "straightforward" application of 358 DDDS and use of NAPTR records, it is still possible to create very 359 complex chains and dependencies with the NAPTR and SRV records. 361 Therefore, domain administrators are called upon to use S-NAPTR with 362 as much restraint as possible, while still achieving their service 363 design goals. 365 The complete set of NAPTR, SRV and A RRs that are "reachable" through 366 the S-NAPTR process for a particular application service can be 367 thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR 368 or SRV records; each SRV record points to several A record lookups. 369 Even though a particular client can "prune" the tree to use only 370 those records referring to application protocols supported by the 371 client, the tree could be quite deep, and retracing the tree to retry 372 other targets can become expensive if the tree has many branches. 374 Therefore, 375 o Fewer branches is better: for both NAPTR and SRV records, provide 376 different targets with varying preferences where appropriate 377 (e.g., to provide backup services, etc), but don't look for 378 reasons to provide more. 379 o Shallower is better: avoid using NAPTR records to "rename" 380 services within a zone. Use NAPTR records to identify services 381 hosted elsewhere (i.e., where you cannot reasonably provide the 382 SRV records in your own zone). 384 3.3 Guidelines for Client Software Writers 386 To properly understand DDDS/NAPTR, an implementor must read [4]. 387 However, the most important aspect to keep in mind is that, if one 388 target fails to work for the application, it is expected that the 389 application will continue through the S-NAPTR tree to try the (less 390 preferred) alternatives. 392 4. Illustrations 394 4.1 Use Cases 396 The basic intended use cases for which S-NAPTR has been developed 397 are: 398 o Service discovery within a domain. For example, this can be used 399 to find the "authoritative" server for some type of service within 400 a domain (see the specific example in Section 4.2). 401 o Multiple protocols. This is increasingly common as new 402 application services are defined. This includes the case of 403 extensible messaging (a hypothetical service) which can be offered 404 with multiple protocols (see Section 4.3). 405 o Remote hosting. Each of the above use cases applies within the 406 administration of a single domain. However, one domain operator 407 may elect to engage another organization to provide an application 408 service. See Section 4.4 for an example that cannot be served by 409 SRV records alone. 411 4.2 Service Discovery within a Domain 413 There are occasions when it is useful to be able to determine the 414 "authoritative" server for a given application service within a 415 domain. This is "discovery", because there is no a priori knowledge 416 as to whether or where the service is offered; it is therefore 417 important to determine the location and characteristics of the 418 offered service. 420 For example, there is growing discussion of having a generic 421 mechanism for locating the keys or certificates associated with 422 particular application (servers) operated in (or for) a particular 423 domain. Here's a hypothetical case for storing application key or 424 certificate data for a given domain. The premise is that some 425 credentials registry (CredReg) service has been defined to be a leaf 426 node service holding the keys/certs for the servers operated by (or 427 for) the domain. Furthermore, it is assumed that more than one 428 protocol is available to provide the service for a particular domain. 429 This DDDS-based approach is used to find the CredReg server that 430 holds the information. 432 Thus, the set of NAPTR records for thinkingcat.example might look 433 like this: 435 thinkingcat.example. 436 ;; order pref flags 437 IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service 438 "" ; regexp 439 theserver.thinkingcat.example. ; replacement 440 ) 442 Note that another domain, offering the same application service, 443 might offer it using a different set of application protocols: 445 anotherdomain.example. 446 ;; order pref flags 447 IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service 448 "" ; regexp 449 foo.anotherdomain.example. ; replacement 450 ) 452 4.3 Multiple Protocols 454 A hypothetical application service, extensible messaging, will be 455 used for the purpose of illustration. (For an example of a real 456 application service with multiple protocols, see [9] and [10]). 457 Assuming that "EM" was registered as an application service, this 458 DDDS application could be used to determine the available services 459 for delivering to a target. 461 Two particular features of this hypothetical extensible messaging 462 should be noted: 463 1. gatewaying is expected to bridge communications across protocols 464 2. extensible messaging servers are likely to be operated out of a 465 different domain than the extensible messaging address, and 466 servers of different protocols may be offered by independent 467 organizations 469 For example, "thinkingcat.example" may support its own servers for 470 the "ProtA" extensible messaging protocol, but rely on outsourcing 471 from "example.com" for "ProtC" and "ProtB" servers. 473 Using this DDDS-based approach, thinkingcat.example can indicate a 474 preference ranking for the different types of servers for the 475 extensible messaging service, and yet the out-sourcer can 476 independently rank the preference and ordering of servers. This 477 independence is not achievable through the use of SRV records alone. 479 Thus, to find the EM services for thinkingcat.example, the NAPTR 480 records for thinkingcat.example are retrieved: 482 thinkingcat.example. 483 ;; order pref flags 484 IN NAPTR 100 10 "s" "EM:ProtA" ( ; service 485 "" ; regexp 486 _ProtA._tcp.thinkingcat.example. ; replacement 487 ) 488 IN NAPTR 100 20 "s" "EM:ProtB" ( ; service 489 "" ; regexp 490 _ProtB._tcp.example.com. ; replacement 491 ) 492 IN NAPTR 100 30 "s" "EM:ProtC" ( ; service 493 "" ; regexp 494 _ProtC._tcp.example.com. ; replacement 495 ) 497 and then the administrators at example.com can manage the preference 498 rankings of the servers they use to support the ProtB service: 500 _ProtB._tcp.example.com. 501 ;; Pref Weight Port Target 502 IN SRV 10 0 10001 bigiron.example.com. 503 IN SRV 20 0 10001 backup.em.example.com. 504 IN SRV 30 0 10001 nuclearfallout.australia-isp.example. 506 4.4 Remote Hosting 508 In the Instant Message hosting example in Section 4.3, the service 509 owner (thinkingcat.example) had to host pointers to the hosting 510 service's SRV records in the thinkingcat.example domain. 512 A better way to approach this is to have one NAPTR RR in the 513 thinkingcat.example domain pointing to all the hosted services, and 514 the hosting domain has NAPTR records for each service to map them to 515 whatever local hosts it chooses (and may change from time to time). 517 thinkingcat.example. 518 ;; order pref flags 519 IN NAPTR 100 10 "s" "EM:ProtA" ( ; service 520 "" ; regexp 521 _ProtA._tcp.thinkingcat.example. ; replacement 522 ) 523 IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service 524 "" ; regexp 525 thinkingcat.example.com. ; replacement 526 ) 528 and then the administrators at example.com can break out the 529 individual application protocols and manage the preference rankings 530 of the servers they use to support the ProtB service (as before): 532 thinkingcat.example.com. 533 ;; order pref flags 534 IN NAPTR 100 10 "s" "EM:ProtC" ( ; service 535 "" ; regexp 536 _ProtC._tcp.example.com. ; replacement 537 ) 538 IN NAPTR 100 20 "s" "EM:ProtB" ( ; service 539 "" ; regexp 540 _ProtB._tcp.example.com. ; replacement 541 ) 543 _ProtC._tcp.example.com. 544 ;; Pref Weight Port Target 545 IN SRV 10 0 10001 bigiron.example.com. 546 IN SRV 20 0 10001 backup.em.example.com. 547 IN SRV 30 0 10001 nuclearfallout.australia-isp.example. 549 4.5 Sets of NAPTR RRs 551 Note that the above sections assumed that there was one service 552 available (via S-NAPTR) per domain. Often, that will not be the 553 case. Assuming thinkingcat.example had the CredReg service set up as 554 described in Section 4.2 and the extensible messaging service set up 555 as described in Section 4.4, then a client querying for the NAPTR RR 556 set from thinkingcat.com would get the following answer: 558 thinkingcat.example. 559 ;; order pref flags 560 IN NAPTR 100 10 "s" "EM:ProtA" ( ; service 561 "" ; regexp 562 _ProtA._tcp.thinkingcat.example. ; replacement 563 ) 564 IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service 565 "" ; regexp 566 thinkingcat.example.com. ; replacement 567 ) 568 IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service 569 "" ; regexp 570 bouncer.thinkingcat.example. ; replacement 571 ) 573 Sorting them by increasing "ORDER", the client would look through the 574 SERVICE strings to determine if there was a NAPTR RR that matched the 575 application service it was looking for, with an application protocol 576 it could use. The first (lowest PREF) record that so matched is the 577 one the client would use to continue. 579 4.6 Sample sequence diagram 581 Consider the example in Section 4.3. Visually, the sequence of steps 582 required for the client to reach the final server for a "ProtB" 583 service for EM for the thinkingcat.example domain is as follows: 585 Client NS for NS for 586 thinkingcat.example example.com backup.em.example.com 587 | | | 588 1 -------->| | | 589 2 <--------| | | 590 3 ------------------------------>| | 591 4 <------------------------------| | 592 5 ------------------------------>| | 593 6 <------------------------------| | 594 7 ------------------------------>| | 595 8 <------------------------------| | 596 9 ------------------------------------------------->| 597 10 <-------------------------------------------------| 598 11 ------------------------------------------------->| 599 12 <-------------------------------------------------| 600 (...) 602 1. the name server (NS) for thinkingcat.example is reached with a 603 request for all NAPTR records 604 2. the server responds with the NAPTR records shown in Section 4.3. 605 3. the second NAPTR record matches the desired criteria; that has an 606 "s" flag and a replacement fields of "_ProtB._tcp.example.com". 607 So, the client looks up SRV records for that target, ultimately 608 making the request of the NS for example.com. 609 4. the response includes the SRV records listed in Section 4.3. 610 5. the client attempts to reach the server with the lowest PREF in 611 the SRV list -- looking up the A record for the SRV record's 612 target (bigiron.example.com). 613 6. the example.com NS responds with an error message -- no such 614 machine! 615 7. the client attempts to reach the second server in the SRV list, 616 and looks up the A record for backup.em.example.com 618 8. the client gets the A record with the IP address for 619 backup.em.example.com from example.com's NS. 620 9. the client connects to that IP address, on port 10001 (from the 621 SRV record), using ProtB over tcp. 622 10. the server responds with an "OK" message. 623 11. the client uses ProtB to challenge that this server has 624 credentials to operate the service for the original domain 625 (thinkingcat.example) 626 12. the server responds, and the rest is EM. 628 5. Motivation and Discussion 630 Increasingly, application protocol standards are using domain names 631 to identify server targets, and stipulating that clients should look 632 up SRV resource records to determine the host and port providing the 633 server. This enables a distinction between naming an application 634 service target and actually hosting the server. It also increases 635 flexibility in hosting the target service: 636 o the server may be operated by a completely different organization 637 without having to list the details of that organization's DNS 638 setup (SRVs) 639 o multiple instances can be set up (e.g., for load balancing or 640 secondaries) 641 o it can be moved from time to time without disrupting clients' 642 access, etc. 643 This is quite useful, but Section 5.1 outlines some of the 644 limitations inherent in the approach. 646 That is, while SRV records can be used to map from a specific service 647 name and protocol for a specific domain to a specific server, SRV 648 records are limited to one layer of indirection, and are focused on 649 server administration rather than on application naming. And, while 650 the DDDS specification and use of NAPTR allows multiple levels of 651 redirection before locating the target server machine with an SRV 652 record, this proposal requires only a subset of NAPTR strictly bound 653 to domain names, without making use of the REGEXP field of NAPTR. 654 These restrictions make the client's resolution process much more 655 predictable and efficient than with some potential uses of NAPTR 656 records. This is dubbed "S-NAPTR" -- a "S"traightforward use of 657 NAPTR records. 659 5.1 So, why not just SRV records? 661 An expected question at this point is: this is so similar in 662 structure to SRV records, why are we doing this with DDDS/NAPTR? 664 Limitations of SRV include: 666 o SRV provides a single layer of indirection -- the outcome of an 667 SRV lookup is a new domain name for which the A RR is to be found. 668 o the purpose of SRV is focused on individual server administration, 669 not application naming: as stated in [3] "The SRV RR allows 670 administrators to use several servers for a single domain, to move 671 services from host to host with little fuss, and to designate some 672 hosts as primary servers for a service and others as backups." 673 o target servers by "service" (e.g., "ldap") and "protocol" (e.g., 674 "tcp") in a given domain. The definition of these terms implies 675 specific things (e.g., that protocol should be one of UDP or TCP) 676 without being precise. Restriction to UDP and TCP is insufficient 677 for the uses described here. 679 The basic answer is that SRV records provide mappings from protocol 680 names to host and port. The use cases described herein require an 681 additional layer -- from some service label to servers that may in 682 fact be hosted within different administrative domains. We could 683 tweak SRV to say that the next lookup could be something other than 684 an address record, but that is more complex than is necessary for 685 most applications of SRV. 687 5.2 So, why not just NAPTR records? 689 That's a trick question. NAPTR records cannot appear in the wild -- 690 see [4]. They must be part of a DDDS application. 692 The purpose here is to define a single, common mechanism (the DDDS 693 application) to use NAPTR when all that is desired is simple 694 DNS-based location of services. This should be easy for applications 695 to use -- some simple IANA registrations and it's done. 697 Also, NAPTR has very powerful tools for expressing "rewrite" rules. 698 That power (==complexity) makes some protocol designers and service 699 administrators nervous. The concern is that it can translate into 700 unintelligible, noodle-like rule sets that are difficult to test and 701 administer. 703 This proposed DDDS application specifically uses a subset of NAPTR's 704 abilities. Only "replacement" expressions are allowed, not "regular 705 expressions". 707 6. Formal Definition of Application of 708 DDDS 710 This section formally defines the DDDS application, as described in 711 [4]. 713 6.1 Application Unique String 715 The Application Unique String is domain label for which an 716 authoritative server for a particular service is sought. 718 6.2 First Well Known Rule 720 The "First Well Known Rule" is identity -- that is, the output of the 721 rule is the Application Unique String, the domain label for which the 722 authoritative server for a particular service is sought. 724 6.3 Expected Output 726 The expected output of this Application is the information necessary 727 to connect to authoritative server(s) (host, port, protocol) for an 728 application service within a given a given domain. 730 6.4 Flags 732 This DDDS Application uses only 2 of the Flags defined for the URI/ 733 URN Resolution Application ([6]): "S" and "A". No other Flags are 734 valid. 736 Both are for terminal lookups. This means that the Rule is the last 737 one and that the flag determines what the next stage should be. The 738 "S" flag means that the output of this Rule is a domain label for 739 which one or more SRV [3] records exist. "A" means that the output 740 of the Rule is a domain name and should be used to lookup address 741 records for that domain. 743 Consistent with the DDDS algorithm, if the Flag string is empty the 744 next lookup is for another NAPTR record (for the replacement target). 746 6.5 Service Parameters 748 Service Parameters for this Application take the form of a string of 749 characters that follow this ABNF ([2]): 751 service-parms = [ [app-service] *(":" app-protocol)] 752 app-service = experimental-service / iana-registered-service 753 app-protocol = experimental-protocol / iana-registered-protocol 754 experimental-service = "x-" 1*30ALPHANUMSYM 755 experimental-protocol = "x-" 1*30ALPHANUMSYM 756 iana-registered-service = ALPHA *31ALPHANUMSYM 757 iana-registered-protocol = ALPHA *31ALPHANUM 758 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 759 DIGIT = %x30-39 ; 0-9 760 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 761 ALPHANUMSYM = ALPHA / DIGIT / SYM 762 ; The app-service and app-protocol tags are limited to 32 763 ; characters and must start with an alphabetic character. 764 ; The service-parms are considered case-insensitive. 766 Thus, the Service Parameters may consist of an empty string, just an 767 app-service, or an app-service with one or more app-protocol 768 specifications separated by the ":" symbol. 770 Note that this is similar to, but not the same as the syntax used in 771 the URI DDDS application ([6]). The DDDS DNS database requires each 772 DDDS application to define the syntax of allowable service strings. 773 The syntax here is expanded to allow the characters that are valid in 774 any URI scheme name (see [8]). Since "+" (the separator used in the 775 RFC3404 service parameter string) is an allowed character for URI 776 scheme names, ":" is chosen as the separator here. 778 6.5.1 Application Services 780 The "app-service" must be an IANA-registered service; see Section 7 781 for instructions on registering new application service tags. 783 6.5.2 Application Protocols 785 The protocol identifiers that are valid for the "app-protocol" 786 production are standard, registered protocols; see Section 7 for 787 instructions on registering new application protocol tags. 789 6.6 Valid Rules 791 Only substitution Rules are permitted for this application. That is, 792 no regular expressions are allowed. 794 6.7 Valid Databases 796 At present only one DDDS Database is specified for this Application. 797 [5] specifies a DDDS Database that uses the NAPTR DNS resource record 798 to contain the rewrite rules. The Keys for this database are encoded 799 as domain-names. 801 The First Well Known Rule produces a domain name, and this is the Key 802 that is used for the first lookup -- the NAPTR records for that 803 domain are requested. 805 DNS servers MAY interpret Flag values and use that information to 806 include appropriate NAPTR, SRV or A records in the Additional 807 Information portion of the DNS packet. Clients are encouraged to 808 check for additional information but are not required to do so. See 809 the Additional Information Processing section of [5] for more 810 information on NAPTR records and the Additional Information section 811 of a DNS response packet. 813 7. IANA Considerations 815 This document calls for 2 IANA registries: one for application 816 service tags, and one for application protocol tags. 818 7.1 Application Service Tag IANA Registry 820 IANA is to establish and maintain a registry for S-NAPTR Application 821 Service Tags, listing at least the following information for each 822 such tag: 823 o Application Service Tag: a string conformant with the 824 iana-registered-service defined in Section 6.5. 825 o Defining publication: the RFC used to define the Application 826 Service Tag, as defined in the registration process, below. 828 An initial Application Service Tag registration is contained in [9]. 830 7.2 Application Protocol Tag IANA Registry 832 IANA is to establish and maintain a registry for S-NAPTR Application 833 Protocol Tags, listing at least the following information for each 834 such tag: 835 o Application Protocol Tag: a string conformant with the 836 iana-registered-protocol defined in Section 6.5. 837 o Defining publication: the RFC used to define the Application 838 Protocol Tag, as defined in the registration process, below. 840 An initial Application Protocol Tag registration is defined in [10]. 842 7.3 Registration Process 844 All application service and protocol tags that start with "x-" are 845 considered experimental, and no provision is made to prevent 846 duplicate use of the same string. Use them at your own risk. 848 All other application service and protocol tags are registered based 849 on the "specification required" option defined in [7], with the 850 further stipulation that the "specification" is an RFC (of any 851 category). 853 There are no further restrictions placed on the tags other than that 854 they must conform with the syntax defined below (Section 6.5). 856 The defining RFC must clearly identify and describe, for each tag 857 being registered: 858 o Application protocol or service tag 859 o Intended usage 860 o Interoperability considerations 861 o Security considerations (see Section 8 of this document for 862 further discussion of the types of considerations that are 863 applicable) 864 o Any relevant related publications 866 8. Security Considerations 868 The security of this approach to application service location is only 869 as good as the security of the DNS servers along the way. If any of 870 them is compromised, bogus NAPTR and SRV records could be inserted to 871 redirect clients to unintended destinations. This problem is hardly 872 unique to S-NAPTR (or NAPTR in general). A full discussion of the 873 security threats pertaining to DNS can be found in [11]. 875 To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] 876 can be used to ensure the validity of the DNS records received. 878 Whether or not DNSSEC is used, applications should define some form 879 of end-to-end authentication to ensure that the correct destination 880 has been reached. Many application protocols such as HTTPS, BEEP, 881 IMAP, etc... define the necessary handshake mechansims to accomplish 882 this task. Newly-defined application protocols should take this into 883 consideration and incorporate appropriate mechanisms. 885 The basic mechanism works in the following way: 886 1. During some portion of the protocol handshake, the client sends 887 to the server the original name of the desired destination (i.e. 888 no transformations that may have resulted from NAPTR 889 replacements, SRV targets, or CNAME changes). In certain cases 890 where the application protocol does not have such a feature but 891 TLS may be used, it is possible to use the "server_name" TLS 892 extension. 893 2. The server sends back to the client a credential with the 894 appropriate name. For X.509 certificates, the name would either 895 be in the subjectDN or subjectAltName fields. For Kerberos, the 896 name would be a service principle name. 897 3. Using the matching semantics defined by the application protocol, 898 the client compares the name in the credential with the name sent 899 to the server. 900 4. If the names match and the credentials have integrity, there is 901 reasonable assurance that the correct end point has been reached. 902 5. The client and server establish an integrity-protected channel. 904 It is important to note that this document does not define either the 905 handshake mechanism, the specific credential naming fields, nor the 906 name matching semantics. Definitions of S-NAPTR for particular 907 application protocols MUST define these. 909 9. Acknowledgements 911 Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted 912 Hardie for discussion and input that has (hopefully!) provoked 913 clarifying revisions of this document. 915 10. References 917 10.1 Normative References 919 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 920 Levels", BCP 14, RFC 2119, March 1997. 922 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 923 Specifications: ABNF", RFC 2234, November 1997. 925 [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 926 specifying the locatio n of services (DNS SRV)", RFC 2782, 927 February 2000. 929 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 930 One: The Comprehensive DDDS", RFC 3401, October 2002. 932 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 933 Three: The Domain Name System (DNS) Database", RFC 3403, October 934 2002. 936 [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 937 Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 938 2002. 940 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 941 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 943 10.2 Informative References 945 [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 946 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 947 1998. 949 [9] Newton, A. and M. Sanz, "IRIS Domain Registry Schema", 950 draft-ietf-crisp-iris-dreg-06 (work in progress), April 2004. 952 [10] Newton, A. and M. Sanz, "Using the Internet Registry 953 Information Service (IRIS) over the Blocks Extensible Exchange 954 Protocol (BEEP)", draft-ietf-crisp-iris-beep-04 (work in 955 progress), April 2004. 957 [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name 958 System", draft-ietf-dnsext-dns-threats-07 (work in progress), 959 April 2004. 961 [12] Arends, R., Larson, M., Austein, R. and D. Massey, "Protocol 962 Modifications for the DNS Security Extensions", 963 draft-ietf-dnsext-dnssec-protocol-06 (work in progress), May 964 2004. 966 Authors' Addresses 968 Leslie Daigle 969 VeriSign, Inc. 970 21355 Ridgetop Circle 971 Dulles, VA 20166 972 US 974 EMail: leslie@verisignlabs.com; leslie@thinkingcat.com 976 Andrew Newton 977 VeriSign, Inc. 978 21355 Ridgetop Circle 979 Dulles, VA 20166 980 US 982 EMail: anewton@verisignlabs.com 984 Appendix A. Pseudo pseudocode for S-NAPTR 986 A.1 Finding the first (best) target 988 Assuming the client supports 1 protocol for a particular application 989 service, the following pseudocode outlines the expected process to 990 find the first (best) target for the client, using S-NAPTR. 992 target = [initial domain] 993 naptr-done = false 995 while (not naptr-done) 996 { 997 NAPTR-RRset = [DNSlookup of NAPTR RRs for target] 998 [sort NAPTR-RRset by ORDER, and PREF within each ORDER] 999 rr-done = false 1000 cur-rr = [first NAPTR RR] 1002 while (not rr-done) 1003 if ([SERVICE field of cur-rr contains desired application 1004 service and application protocol]) 1005 rr-done = true 1006 target= [REPLACEMENT target of NAPTR RR] 1007 else 1008 cur-rr = [next rr in list] 1010 if (not empty [FLAG in cur-rr]) 1011 naptr-done = true 1012 } 1014 port = -1 1016 if ([FLAG in cur-rr is "S"]) 1017 { 1018 SRV-RRset = [DNSlookup of SRV RRs for target] 1019 [sort SRV-RRset based on PREF] 1020 target = [target of first RR of SRV-RRset] 1021 port = [port in first RR of SRV-RRset] 1022 } 1024 ; now, whether it was an "S" or an "A" in the NAPTR, we 1025 ; have the target for an A record lookup 1027 host = [DNSlookup of target] 1029 return (host, port) 1031 A.2 Finding subsequent targets 1033 The pseudocode in Appendix A is crafted to find the first, most 1034 preferred, host-port pair for a particular application service an 1035 protocol. If, for any reason, that host-port pair did not work 1036 (connection refused, application-level error), the client is expected 1037 to try the next host-port in the S-NAPTR tree. 1039 The pseudocode above does not permit retries -- once complete, it 1040 sheds all context of where in the S-NAPTR tree it finished. 1041 Therefore, client software writers could 1042 o entwine the application-specific protocol with the DNS lookup and 1043 RRset processing described in the pseudocode and continue the 1044 S-NAPTR processing if the application code fails to connect to a 1045 located host-port pair; 1046 o use callbacks for the S-NAPTR processing; 1047 o use an S-NAPTR resolution routine that finds *all* valid servers 1048 for the required application service and protocol from the 1049 originating domain, and provides them in sorted order for the 1050 application to try in order. 1052 Appendix B. Availability of Sample Code 1054 Sample Python code for S-NAPTR resolution is available from 1055 http://www.verisignlabs.com/pysnaptr-0.1.tgz . 1057 Intellectual Property Statement 1059 The IETF takes no position regarding the validity or scope of any 1060 intellectual property or other rights that might be claimed to 1061 pertain to the implementation or use of the technology described in 1062 this document or the extent to which any license under such rights 1063 might or might not be available; neither does it represent that it 1064 has made any effort to identify any such rights. Information on the 1065 IETF's procedures with respect to rights in standards-track and 1066 standards-related documentation can be found in BCP-11. Copies of 1067 claims of rights made available for publication and any assurances of 1068 licenses to be made available, or the result of an attempt made to 1069 obtain a general license or permission for the use of such 1070 proprietary rights by implementors or users of this specification can 1071 be obtained from the IETF Secretariat. 1073 The IETF invites any interested party to bring to its attention any 1074 copyrights, patents or patent applications, or other proprietary 1075 rights which may cover technology that may be required to practice 1076 this standard. Please address the information to the IETF Executive 1077 Director. 1079 Full Copyright Statement 1081 Copyright (C) The Internet Society (2004). All Rights Reserved. 1083 This document and translations of it may be copied and furnished to 1084 others, and derivative works that comment on or otherwise explain it 1085 or assist in its implementation may be prepared, copied, published 1086 and distributed, in whole or in part, without restriction of any 1087 kind, provided that the above copyright notice and this paragraph are 1088 included on all such copies and derivative works. However, this 1089 document itself may not be modified in any way, such as by removing 1090 the copyright notice or references to the Internet Society or other 1091 Internet organizations, except as needed for the purpose of 1092 developing Internet standards in which case the procedures for 1093 copyrights defined in the Internet Standards process must be 1094 followed, or as required to translate it into languages other than 1095 English. 1097 The limited permissions granted above are perpetual and will not be 1098 revoked by the Internet Society or its successors or assignees. 1100 This document and the information contained herein is provided on an 1101 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1102 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1103 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1104 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1105 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1107 Acknowledgment 1109 Funding for the RFC Editor function is currently provided by the 1110 Internet Society.