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