idnits 2.17.1 draft-jennings-http-srv-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 25, 2009) is 5538 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: 3 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 25, 2009 5 Expires: August 29, 2009 7 DNS SRV Records for HTTP 8 draft-jennings-http-srv-04 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. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 29, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document specifies a new URI scheme called http+srv which uses a 57 DNS SRV lookup to locate a HTTP server. The http+srv scheme operates 58 in the same way as an http scheme but instead of the normal DNS 59 lookup that a http scheme would use, it first tries an DNS SRV 60 lookup. This memo also defines a https+srv scheme that operates in 61 the same was as an https URI but uses DNS SRV lookups. 63 The draft is being discussed on the apps-discuss@ietf.org list. 65 Legal 67 This documents and the information contained therein are provided on 68 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 69 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 70 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 71 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 72 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 73 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 74 FOR A PARTICULAR PURPOSE. 76 1. Introduction 78 Web services often define APIs where software running on machine in a 79 data center acts as an HTTP client and performs some http 80 transactions to another HTTP server. For example, a portal such as 81 Facebook can act as a http client and call specific HTTP-based APIs 82 on other http servers. The reality of current networks is a large 83 portion of the hosts have NATed addresses and often can not run on 84 port 80. This is likely to become more common with the deployment of 85 Carrier Grade NAT. DNS SRV records allow a DNS lookup of a name like 86 www.example.com to provide both a port and the IP addresses of the 87 HTTP server. 89 This specification defines two new URI schemes, http+srv, and https+ 90 srv which are like http and https respectively. When a http client 91 uses one of theses schemes to locate a web server, it starts by doing 92 a DNS SRV record lookup and if one is found, uses that result. If no 93 SRV record is found, it falls back to a DNS address (A or AAAA) 94 record. The specification does not update or modify HTTP in any way. 96 It is not expected that most web browsers would support these schemes 97 for generic web use. It would instead be used for particular 98 applications using HTTP such as specific web APIs. These APIs would 99 be defined to require the use of this specification. In this 100 situation, the end user's web browser might not do the SRV lookup 101 when it browsed to the portal web pages, but the HTTP calls that the 102 portal made out to other sites to generate the content would use this 103 mechanism. As such architectures become more common, DNS SRV would 104 allow many servers that are just providing an API to run on ports 105 other than 80 even though main portal sites may still be running on 106 the well known ports. Eventually, web browsers may end up supporting 107 these SRV lookups, as the implementation is trivial and has very 108 little downside. 110 This technique is useful where users wish to run a web server behind 111 a NAT but cannot control which port the NAT will allocate for the 112 service. It is also useful where several users want to run different 113 web servers on the same machine. A third use case for HTTP SRV is a 114 situation in which all requests should be sent to a primary server, 115 but if that server is down, then requests should fall back to an 116 alternative server. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Mechanisms 126 Applications compliant with this specification MUST perform an SRV 127 lookup as specified in [RFC2782] when resolving the host portion of a 128 http+srv or https+srv URI. As defined in the IANA port numbers 129 registry, the service names used are _http and _https respectively. 130 As described in RFC 2782, if no SRV record is present, the resolution 131 will fall back on using other DNS records that would be used by a 132 http scheme as defined in HTTP[RFC2616]. The rest of the http+srv 133 URI is processed in the same way as an http URI in RFC 2616 while the 134 rest of a https+srv scheme URI is processed the same way as a https 135 URI as defined in [RFC2818]. 137 4. Example 139 In the following example, the client will do a lookup on the URI, 140 which finds the SRV record that then points at the A record that 141 points at the IP address. 143 URI: https+srv://example.com 144 DNS SRV RR: _https._tcp.example.com. SRV 1 0 8080 host1.example.com. 145 DNS A RR: host1.example.com. A 192.0.2.88 147 Figure 1 149 In this case the client would form a TCP connection to 192.0.2.88: 150 8080 then start TLS over that connection. Note that the certificate 151 in the TLS handshake would be matched to example.com as that was the 152 names used in the URI and it would not be matched to 153 host1.example.com. 155 5. IANA Considerations 157 This specification registers two provisional URI schemes. 159 5.1. http+srv URI scheme 161 URI scheme name: 163 http+srv 165 Status: 167 provisional 169 URI scheme syntax: 171 Identical to http URI as defined in RFC 2616 but using the 'http+ 172 srv' protocol identifier in place of the 'http' protocol 173 identifier 175 URI scheme semantics: 177 See draft-jennings-http-uri 179 Encoding considerations: 181 No special considerations 183 Applications/protocols that use this URI scheme name: 185 Applications which need to lookup http servers using DNS SRV 187 Interoperability considerations.: 189 None known 191 Security considerations.: 193 Same as http URI. See RFC 2616 195 Contact.: 197 Cullen Jennings 199 Author/Change controller.: 201 Cullen Jennings 203 References.: 205 draft-jennings-http-srv 207 RFC 3986 209 RFC 2616 211 5.2. https+srv URI scheme 213 URI scheme name: 215 https+srv 217 Status: 219 provisional 221 URI scheme syntax: 223 Identical to http URI as defined in RFC 2818 but using the 'https+ 224 srv' protocol identifier in place of the 'https' protocol 225 identifier 227 URI scheme semantics: 229 See draft-jennings-http-uri 231 Encoding considerations: 233 No special considerations 235 Applications/protocols that use this URI scheme name: 237 Applications which need to lookup http servers using DNS SRV 239 Interoperability considerations.: 241 None known 243 Security considerations.: 245 Same as https URI. See RFC 2818 247 Contact.: 249 Cullen Jennings 251 Author/Change controller.: 253 Cullen Jennings 255 References.: 257 draft-jennings-http-srv 259 RFC 3986 261 RFC 2818 263 6. Security Considerations 265 This introduces no new security considerations beyond the common 266 usage of HTTP. It is analogous to DNS CNAME records that redirect 267 address records. 269 7. Acknowledgements 271 Variants of this idea has been proposed by many people, including 272 Mark Andrews and Thor Kottelin in an internet draft in 2000. fooo 274 Some text came from various documents by Ted Hardie. Thanks to good 275 feedback from many people including Ted Hardie, Mr. Moonesamy, Cyrus 276 Daboo, Stefanos Harhalakis, Ray Bellis, John Klensin, and Eran 277 Hammer-Lahav. 279 8. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 285 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 286 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 288 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 289 specifying the location of services (DNS SRV)", RFC 2782, 290 February 2000. 292 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 294 Author's Address 296 Cullen Jennings 297 Cisco Systems 298 170 West Tasman Drive 299 Mailstop SJC-30 300 San Jose, CA 95134 301 USA 303 Phone: +1 408 902-3341 304 Email: fluffy@cisco.com