idnits 2.17.1 draft-jennings-http-srv-01.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2009) is 5535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Informational February 22, 2009 5 Expires: August 26, 2009 7 DNS SRV Records for HTTP 8 draft-jennings-http-srv-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 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 Internet- 18 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 August 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 This document may contain material from IETF Documents or IETF 46 Contributions published or made publicly available before November 47 10, 2008. The person(s) controlling the copyright in some of this 48 material may not have granted the IETF Trust the right to allow 49 modifications of such material outside the IETF Standards Process. 50 Without obtaining an adequate license from the person(s) controlling 51 the copyright in such materials, this document may not be modified 52 outside the IETF Standards Process, and derivative works of it may 53 not be created outside the IETF Standards Process, except to format 54 it for publication as an RFC or to translate it into languages other 55 than English. 57 Abstract 59 This document specifies a new URI scheme called http+srv which uses a 60 DNS SRV lookup to locate a HTTP server. The http+srv scheme operates 61 in the same way as an http scheme but instead of the normal DNS A 62 record lookup that a http scheme would use, it uses an DNS SRV 63 lookup. This memo also defines a https+srv scheme that operates in 64 the same was a an https URI but uses DNS SRV lookups. 66 The draft is being discussed on the apps-discuss@ietf.org list. 68 Legal 70 This documents and the information contained therein are provided on 71 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 72 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 73 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 74 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 75 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 76 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 77 FOR A PARTICULAR PURPOSE. 79 1. Introduction 81 Web services often define APIs where software running on machine in a 82 data center acts as an HTTP client and performs some http 83 transactions to another HTTP server. For example, a portal such as 84 Facebook can act as a http client and call specific HTTP-based APIs 85 on other http servers. The reality of current networks is a large 86 portion of the hosts have NATed addresses and often can not run on 87 port 80. This is likely to become more common with the deployment of 88 Carrier Grade NAT. DNS SRV records allow a DNS lookup of a name like 89 www.example.com to provide both a port and the IP addresses of the 90 HTTP server. 92 This specification defines two new URI schemes, http+srv, and https+ 93 srv which are like http and https respectively. When a http client 94 uses one of theses schemes to locate a web server, it starts by doing 95 a DNS SRV record lookup and if one is found, uses that result. If no 96 SRV record is found, it falls back to a DNS A record. The 97 specification does not update or modify HTTP in any way. 99 It is not expected that most web browsers would support these schemes 100 for generic web use. It would instead be used for particular 101 applications using HTTP such as specific web APIs. These APIs would 102 be defined to require the use of this specification. In this 103 situation, the end user's web browser might not do the SRV lookup 104 when it browsed to the portal web pages, but the HTTP calls that the 105 portal made out to other sites to generate the content would use this 106 mechanism. As such architectures become more common, DNS SRV would 107 allow many servers that are just providing an API to run on ports 108 other than 80 even though main portal sites may still be running on 109 the well known ports. Eventually, web browsers may end up supporting 110 these SRV lookups, as the implementation is trivial and has very 111 little downside. 113 This technique is useful where users wish to run a web server behind 114 a NAT but cannot control which port the NAT will allocate for the 115 service. It is also useful where several users want to run different 116 web servers on the same machine. A third use case for HTTP SRV is a 117 situation in which all requests should be sent to a primary server, 118 but if that server is down, then requests should fall back to an 119 alternative server. 121 2. Terminology 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 RFC 2119 [RFC2119]. 127 3. Mechanisms 129 Applications compliant with this specification MUST perform an SRV 130 lookup as specified in [RFC2782] when resolving the host portion of a 131 http+srv or https+srv URI. As defined in the IANA port numbers 132 registry, the service names used are _http and _https respectively. 133 As described in RFC 2782, if no SRV record is present, the resolution 134 will fall back on using other DNS records that would be used by a 135 http scheme as defined in HTTP[RFC2616]. The rest of the http+srv 136 URI is processed in the same way as an http URI in RFC 2616 while the 137 rest of a https+srv scheme URI is processed the same way as a https 138 URI as defined in [RFC2818]. 140 4. Example 142 In the following example, the client will do a lookup on the URI, 143 which finds the SRV record that then points at the A record that 144 points at the IP address. 146 URI: https+srv://example.com 147 DNS SRV RR: _http._tcp.example.com. SRV 1 0 8080 host1.example.com. 148 DNS A RR: host1.example.com. A 192.0.2.88 150 Figure 1 152 In this case the client would form a TCP connection to 192.0.2.88: 153 8080 then start TLS over that connection. Note that the certificate 154 in the TLS handshake would be matched to example.com as that was the 155 names used in the URI and it would not be matched to 156 host1.example.com. 158 5. IANA Considerations 160 This specification registers two provisional URI schemes. 162 5.1. http+srv URI scheme 164 URI scheme name: 166 http+srv 168 Status: 170 provisional 172 URI scheme syntax: 174 Identical to http URI as defined in RFC 2616 but using the 'http+ 175 srv' protocol identifier in place of the 'http' protocol 176 identifier 178 URI scheme semantics: 180 See draft-jennings-http-uri 182 Encoding considerations: 184 No special considerations 186 Applications/protocols that use this URI scheme name: 188 Applications which need to lookup http servers using DNS SRV 190 Interoperability considerations.: 192 None known 194 Security considerations.: 196 Same as http URI. See RFC 2616 198 Contact.: 200 Cullen Jennings 202 Author/Change controller.: 204 Cullen Jennings 206 References.: 208 draft-jennings-http-srv 210 RFC 3986 212 RFC 2616 214 5.2. https+srv URI scheme 216 URI scheme name: 218 https+srv 220 Status: 222 provisional 224 URI scheme syntax: 226 Identical to http URI as defined in RFC 2818 but using the 'https+ 227 srv' protocol identifier in place of the 'https' protocol 228 identifier 230 URI scheme semantics: 232 See draft-jennings-http-uri 234 Encoding considerations: 236 No special considerations 238 Applications/protocols that use this URI scheme name: 240 Applications which need to lookup http servers using DNS SRV 242 Interoperability considerations.: 244 None known 246 Security considerations.: 248 Same as https URI. See RFC 2818 250 Contact.: 252 Cullen Jennings 254 Author/Change controller.: 256 Cullen Jennings 258 References.: 260 draft-jennings-http-srv 262 RFC 3986 264 RFC 2818 266 6. Security Considerations 268 This introduces no new security considerations beyond the common 269 usage of HTTP. It is analogous to DNS CNAME records that redirect to 270 other A records. 272 7. Acknowledgements 274 Variants of this idea has been proposed by many people, including 275 Mark Andrews and Thor Kottelin in an internet draft in 2000. Some 276 text came from various documents by Ted Hardie. 278 8. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 284 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 285 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 287 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 288 specifying the location of services (DNS SRV)", RFC 2782, 289 February 2000. 291 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 293 Author's Address 295 Cullen Jennings 296 Cisco Systems 297 170 West Tasman Drive 298 Mailstop SJC-30 299 San Jose, CA 95134 300 USA 302 Phone: +1 408 902-3341 303 Email: fluffy@cisco.com