idnits 2.17.1 draft-lear-httpbis-svcinfo-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 316 has weird spacing: '...0 in ns ns1....' == Line 341 has weird spacing: '...0 in ns ns1....' == Line 366 has weird spacing: '...0 in ns ns1....' -- The document date (December 05, 2012) is 4159 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) == Missing Reference: 'X' is mentioned on line 395, but not defined -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems GmbH 4 Intended status: Standards Track December 05, 2012 5 Expires: June 06, 2013 7 A DNS Resource Record for Service Descriptions 8 draft-lear-httpbis-svcinfo-rr-00 10 Abstract 12 Certain application protocols are highly transactional and require 13 substantial care when dealing with latency. Queries for versioning 14 information are, in these circumstances, costly. In addition, there 15 is a desire to allow for a means to specify a lightweight means to 16 alternative transport protocols, such as making use of SCTP instead 17 of TCP. This memo specifies a new DNS RR with an eye toward the 18 least necessary roundtrips to determine various protocols, port 19 numbers, and options for a given service instance. 21 Note 23 [[NOTE: For httpbis, the first goal is to focus down on requirements. 24 Consider all this draft through the lens of "http" where one sees the 25 words "application protocol" or "service".]] 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 06, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Design Requirements . . . . . . . . . . . . . . . . . . . 3 62 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2.1. The DNS SRV Record . . . . . . . . . . . . . . . . . . 3 64 1.2.2. NAPTR . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2.3. The URI resource record . . . . . . . . . . . . . . . 4 66 1.2.4. Happy Eyeballs . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Overall approach . . . . . . . . . . . . . . . . . . . . . 4 68 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. The SVCINFO Record Format and Use . . . . . . . . . . . . . . 5 70 2.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3. Backward Compabitibility and Other Interactions . . . . . . . 6 73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 80 Appendix A. SRV example . . . . . . . . . . . . . . . . . . . . . 11 81 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 For an application protocol to survive over time, it must include 87 version information, and usually must have some sort of capability 88 statement or exchange. How this is done depends on a number of 89 characteristics of the protocol, such as whether it is half-duplex 90 and what performance characteristics it has. When using many 91 transactional connections, end-to-end latency will occur before new 92 capabilities can be used. 94 In addition, traditionally application protocol specifications have 95 indicated the transport protocol to be used. It is useful to be able 96 to declare in advance what protocol(s) a service instance runs atop. 97 For instance, it might be possible to a service instance on both TCP 99 [RFC0792] and SCTP [RFC4960]. 101 1.1. Design Requirements 103 We have the following five design requirements for any solution: 105 1. Application protocol version information must be discoverable 106 within the DNS. 108 2. Transport protocol version information for a service must be 109 discoverable within the DNS. 111 3. Performance of the application must not be unduly impacted. Some 112 additional latency may be tolerated. 114 4. It should be possible for multiple instances of an application to 115 be advertised on different ports by the same host. This is 116 particularly common with HTTP [RFC2616]. 118 5. While it may be possible to modify URI schema definitions, all 119 such modifications MUST be 100% backward compatible. 121 One additional potential requirement would be host-level redirection. 122 The benefit of host-level redirection in the DNS is that it would 123 allow for a virtual server to securely offer TLS for multiple domains 124 without the need for multiple IP addresses, as different ports are 125 offered for different virtual hosts instead of different IP 126 addresses. 128 1.2. Related Work 130 There are a number of existing capabilities within the network that 131 can address some or all of the requirements above. 133 1.2.1. The DNS SRV Record 135 It has been possible to make use of a new service name and query the 136 DNS for a SRV resource record [RFC2782], again perhaps running a 137 race. SRV provides a mechanism to locate one or more server and port 138 for a given service. There are two concerns with SRV. First, one 139 must indicate the transport protocol as part of the QNAME. This 140 means that discovery of multiple transport protocols requires 141 multiple queries. 143 In addition, common enterprise deployments create a _TCP zone for 144 purposes such as load balancing of SRV responses separate from a 145 parent domain. Keeping in mind that the goal is to reduce the number 146 of queries to determine version and protocol parameters, multiple DNS 147 queries perform no better than an in-path application protocol 148 exchange. Additional information also cannot always be provided or 149 be trusted, because the authoritative name server for the service 150 name may not also be authoritative for the target domain. A detailed 151 example of the SRV record's performance is given in Appendix Appendix 152 A. 154 1.2.2. NAPTR 156 Another record that could be considered is NAPTR [RFC3402]. NAPTR is 157 a very powerful means for DNS clients to apply search-and-replace 158 rules to a given URI. Building upon the SRV record, NAPTR provides a 159 means to specify use of alternate services and transport protocols. 160 Because NAPTR may return either an A record or SRV record, one or 161 more follow-on query may be needed. In addition, this leaves us 162 without protocol version information. 164 1.2.3. The URI resource record 166 The URI resource record provides for a mapping from hostname to URI. 167 This record can be used to map a domain to multiple URIs, in fact. 168 What it lacks, however, is version information about the application 169 protocol. 171 1.2.4. Happy Eyeballs 173 One final approach is to run a race by initiating the protocol 174 exchange using two alternatives, and pursuing the alternative that 175 indicates success first, the assumption being that the service 176 exists. An example of this model is Happy Eyeballs [RFC6555], where 177 different versions of IP are tested. This work specifies that when 178 an AAAA record is specified, a race may be performed. DNS cannot in 179 general be used to determine reachability. Hence, a race may yet be 180 appropriate in some circumstances, when a service is advertised. 182 1.3. Overall approach 184 To allow hosts to advertise a service using multiple versions of 185 application protocols or multiple transport protocols, a method is 186 needed to efficiently advertise that there exists an equivalence. To 187 accomplish this, we define a new RRtype that states each way to 188 connect to the service by using as an initial index the port and 189 service that the application intends to connect to, and then 190 providing an additional index known as an "InstanceId" that then 191 establishes an equivalence between the instant record and any other 192 record returned in the query with the same InstanceId. Examples of 193 this approach are found in Section 4. This additional index is 194 useful in circumstances where multiple applications making use of the 195 same service (such as HTTP) are running on a single host. The 196 InstanceId can be used to indicate to the client which application is 197 instantiated through multiple protocols (such as a database 198 application making use of both HTTP 1.1 and HTTP 2.0). 200 1.4. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 2. The SVCINFO Record Format and Use 207 The SVCINFO RR is queried with DNS type code TBD. The format of the 208 SVCINFO resource record is as follows: 210 domain TTL Class SVCINFO InstanceId Priority Proto Port Version 212 The fields are defined as follows: 214 Domain, TTL, Class: These are specified in [RFC1035]. 216 SVCINFO: This is the resource record type. 218 InstanceId: This 16-bit number identifies an instance of a service. 219 If the same InstanceId appears in multiple SVCINFO records, then 220 the services on those ports atop those protocols are said by the 221 service owner to be equivalent. 223 Priority: This eight-bit number has similar meaning to "Priority" as 224 defined in [RFC2782]. Its use and interaction with other fields 225 is described below. 227 Proto: This field indicates the textual name found in the IANA 228 "Assigned Internet Protocol Numbers" database. Records MUST 229 contain only transport protocols that directly make use of service 230 to port mappings. 232 Port: This is a port number associated with the service running on a 233 host. The value must be a legal value for the assocated transport 234 protocol. 236 Version: This field indicates a version number and any additional 237 capabilities for a given service. Note that the interpretation of 238 this field is to be defined by individual services. 240 [[DISCUSS: An alternative approach would be to combine proto and 241 version into a single "profile" field. This would recognize the 242 tight binding between application protocol and transport protocol. 243 While it reduces the number of fields, it abstracts information out 244 of DNS.]] 246 2.1. Usage 247 When a host offers an equivalent service in two different ways it 248 will advertise those ways in the DNS with the SVCINFO record, using 249 the same InstanceId. When a host wants to make use of a service, it 250 then queries the DNS with QNAME=domain, QCLASS=IN, and QTYPE=SVCINFO. 251 It processes the information as follows: 253 [[DISCUSS: Is class IN really correct?]] 255 1. If the reply is NOERROR and ANCOUNT=0 is returned, the host 256 attempts to connect using either the configured port and 257 transport protocol or the port associated with the service in the 258 IANA registry. 260 2. If the reply is NOERROR and ANCOUNT > 0, the host searches for 261 the port and transport protocol that it would expect to connect 262 to, absent the SVCINFO record. Upon a match, it notes the 263 InstanceId of that record, and any matching InstanceId of other 264 SVCINFO records returned in the answer. 266 3. The host then attempts to connect to the protocol and port with 267 the lowest number priority that matches the protocol and version 268 that it understands. Two records that have the same priority may 269 be tried in any order, or raced a'la Happy EyeBalls. 271 2.2. Notes 273 Zones MUST NOT publish multiple SVCINFO records for the same domain 274 that use the same protocol AND port. Resolvers SHOULD ignore such 275 SVCINFO records. 277 A client resolver MUST parse all RRs in the reply in order to 278 properly determine priority. Accordingly, clients MUST handle 279 truncated responses using the rules described in [RFC2181]. 281 In all cases when an SVCINFO record is returned, all A and AAAA 282 record for the domain SHOULD be returned in the additional 283 information section. This eliminates excess queries without adding 284 additional risk of cache poisoning. 286 When the application loses communication with the other side, it 287 SHOULD re-apply the rules above in attempting to re-establish 288 connectivity. When doing so, applications making use of the SVCINFO 289 record MAY cache results, but MUST observe TTLs. 291 3. Backward Compabitibility and Other Interactions 293 There are several side effects of using SVCINFO. The first, is that 294 by its nature, SVCINFO requires backward compatibility. A service 295 must always run on a port that is advertised, be that as an IANA- 296 assigned port, through specification within a URI, or some other 297 means. At the same time, when SVCINFO *is* used by the client, an 298 observer may not see the client connect to a server on a port 299 specified by a given URI. 301 4. Examples 303 Case 1: Different versions of HTTP, same transport protocol 305 Consider the case of host www.example.com, which is running an 306 HTTP1.1 server on port 80 and an HTTP2.0 server on port 49080, both 307 using TCP, both serving the same content. A records for this service 308 might appear as follows: 310 www.example.com 86400 in svcinfo 1 10 tcp 80 1.1 311 www.example.com 86400 in svcinfo 1 5 tcp 49080 2.0 313 Additional Information: 314 www.example.com 86400 in a 192.0.2.1 315 www.example.com 86400 in aaaa 2001:db8::1 316 example.com 604800 in ns ns1.example.com 318 When a web client attempted to connect to http://www.example.com, it 319 would know that the transport protocol is TCP and the port is 80. 320 When it queries for the svcinfo record of www.example.com, it 321 receives the above response. It then sees that the InstanceId on 322 port 80 for TCP is 1. It also sees that the InstanceId for port 323 49080 is also 1. It now knows that these two services are 324 equivalent, and sees that it should attempt to connect to tcp/49080 325 if it understands the version specified (2.0). If the client doesn't 326 understand HTTP 2.0, it should connect to port 80. 328 Case two: Same service running on multiple transport protocols 330 In the next case, we change the case slightly from above by allowing 331 for the idea that http2.0 will make use of SCTP in addition to TCP. 332 Therefore the records might appear as follows: 334 www.example.com 86400 in svcinfo 1 10 tcp 80 1.1 335 www.example.com 86400 in svcinfo 1 5 tcp 49080 2.0 336 www.example.com 86400 in svcinfo 1 1 sctp 80 2.0 338 Additional Information: 339 www.example.com 86400 in a 192.0.2.1 340 www.example.com 86400 in aaaa 2001:db8::1 341 example.com 604800 in ns ns1.example.com 343 Now when the web client attempts to connect to http:// 344 www.example.com, after seeing that all three responses for 345 www.example.com have an InstanceId of 1 (including that of port 80), 346 if it knows how to speak sctp, it should first try to connect to port 347 80 using sctp, but only if it understands http2.0. Otherwise it 348 behaves as it did the previous example. 350 Case 3: Multiple services 352 In this case the client is attempting to connect to http:// 353 www.example.com:8080, where www.example.com runs multiple http 354 servers. The DNS configuration appears as follows: 356 www.example.com 86400 in svcinfo 1 10 tcp 80 1.1 357 www.example.com 86400 in svcinfo 1 5 tcp 49080 2.0 358 www.example.com 86400 in svcinfo 1 1 sctp 80 2.0 359 www.example.com 86400 in svcinfo 2 10 tcp 8080 1.1 360 www.example.com 86400 in svcinfo 2 5 tcp 8081 2 361 www.example.com 86400 in svcinfo 2 1 sctp 8080 2 363 Additional Information: 364 www.example.com 86400 in a 192.0.2.1 365 www.example.com 86400 in aaaa 2001:db8::1 366 example.com 604800 in ns ns1.example.com 368 When the client queries for www.example.com and receives the above 369 information, it notes that port 8080 has an InstanceId of 2. It 370 matches that InstanceId with the records that use 8081/tcp and 8080/ 371 sctp. It ignores all other records that contain InstanceIds other 372 than 2. The client then attempts to connect first on SCTP, if it 373 understands HTTP 2. If it doesn't understand HTTP2, it will connect 374 on port 8080 and proceed with HTTP 1.1. 376 5. Security Considerations 378 Absent the use of DNSSEC [RFC4035], it is important that alternatives 379 offered by this service have the same security properties, lest a 380 downgrade attack be introduced. 382 When published to the world, this record would divulge that the 383 likely presence of services running on a particular set of ports. It 384 may not be all that difficult to divine what is running, either based 385 on a simple probe, or the version number in the response. 387 6. IANA Considerations 389 The IANA is requested to allocate a DNS RRTYPE with the following 390 information: 392 A. Submission Date: 394 B. Submission Type: 395 [X] New RRTYPE 396 [ ] Modification to existing RRTYPE 398 C. Contact Information for submitter (will be publicly posted): 399 Name: TBD 400 Email Address: TBD 401 International telephone number: TBD 402 Other contact handles: TBD 404 D. Motivation for the new RRTYPE application. 405 Please keep this part at a high level to inform the Expert and 406 reviewers about uses of the RRTYPE. Most reviewers will be DNS 407 experts that may have limited knowledge of your application 408 space. 410 Please see Section 1 of this document. 412 E. Description of the proposed RR type. 413 This description can be provided in-line in the template, as an 414 attachment, or with a publicly available URL. 416 Please see Section 1 of this document. 418 F. What existing RRTYPE or RRTYPEs come closest to filling that 419 need and why are they unsatisfactory? 421 Please see Section 1 of this document. 423 G. What mnemonic is requested for the new RRTYPE (optional)? 424 Note: this can be left blank and the mnemonic decided after the 425 template is accepted. 427 SVCINFO 429 H. Does the requested RRTYPE make use of any existing IANA registry 430 or require the creation of a new IANA sub-registry in DNS 431 Parameters? If so, please indicate which registry is to be used 432 or created. If a new sub-registry is needed, specify the 433 allocation policy for it and its initial contents. Also include 434 what the modification procedures will be. 436 This RRType refers to the IANA Assigned Internet Protocol 437 Numbers registry, but requires no allocations from it. 439 I. Does the proposal require/expect any changes in DNS 440 servers/resolvers that prevent the new type from being processed 441 as an unknown RRTYPE (see [RFC3597])? 443 No. 445 J. Comments: 447 None. 449 7. Acknowledgments 451 This work largely builds upon the experience gathered with SRV 452 records, as originally defined by Paul Vixie. SRV records are still 453 appropriate in many, if not most, circumstances. Thanks also go to 454 Joe Hildebrand, Dan Wing, and Mark Nottingham for their reviews. 456 8. References 458 8.1. Normative References 460 [RFC1035] Mockapetris, P., "Domain names - implementation and 461 specification", STD 13, RFC 1035, November 1987. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, March 1997. 466 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 467 Specification", RFC 2181, July 1997. 469 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 470 specifying the location of services (DNS SRV)", RFC 2782, 471 February 2000. 473 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 474 (RR) Types", RFC 3597, September 2003. 476 8.2. Informative References 478 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 479 RFC 792, September 1981. 481 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 482 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 483 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 485 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 486 Part Two: The Algorithm", RFC 3402, October 2002. 488 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D. and S. 489 Rose, "Protocol Modifications for the DNS Security 490 Extensions", RFC 4035, March 2005. 492 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 493 4960, September 2007. 495 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 496 Dual-Stack Hosts", RFC 6555, April 2012. 498 Appendix A. SRV example 500 Consider the fictional case where http version 2 requires querying 501 the DNS for _http2._tcp.example.com to get to example.com. The SRV 502 record might look something like this: 504 _http2._tcp.example.com 86400 in srv 10 10 49080 www.example.com 506 To fully resolve http://example.com to the necessary components of an 507 ip address,transport protocol, and a port, a full service resolver 508 must make the following queries: 510 1. A query for _http2._tcp.example.com to name servers for 511 example.com will either return the SRV record or name servers for 512 _tcp.example.com. 514 2. A query is made where there is a zone cut for _tcp.example.com. 515 We now have the SRV record. We may also have an A record for 516 www.example.com if it appears in an additional information 517 section in the same zone. 519 3. If we do not have the A record for www.example.com, we will then 520 query for it separately. 522 Step 2 is a common step that is necessary today in many enterprise 523 deployments, even if the client being served is not within that 524 enterprise. The last step may actually be several steps if the 525 target domain is not in the same zone as the name found in the QNAME. 526 A check of one highly optimized common news site found ten separate 527 and distinct domains. Risking an average query response time of 528 60ms, use of SRV records could inject 600ms on the initial start up 529 for that site. 531 What we conclude is that the fundamental issue with SRV (and any 532 record where a zone split is likely) is that the service name 533 requires additional A records for a host to connect to the service 534 that may not be possible to provide in a single query. 536 Appendix B. Changes 538 This section to be removed prior to publication. 540 o 00 Initial Revision. 542 Author's Address 543 Eliot Lear 544 Cisco Systems GmbH 545 Richtistrasse 7 546 Wallisellen, ZH CH-8304 547 Switzerland 549 Phone: +41 44 878 9200 550 Email: lear@cisco.com