idnits 2.17.1 draft-andrews-http-srv-02.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 13 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 20, 2014) is 3627 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Expires: November 21, 2014 T. Kottelin 5 May 20, 2014 7 Use of SRV records in conjuction with HTTP and URIs" 8 draft-andrews-http-srv-02 10 Abstract 12 The combined use of SRV records for HTTP along with URIs is not as 13 straight forward as it would appear at first glance. This document 14 looks at the issues involved and recommends solutions. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 21, 2014. 33 Copyright Notice 35 Copyright (c) 2014 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. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. URIs without an explicit port specification . . . . . . . . . . 3 64 3. URIs with a explicit port specification . . . . . . . . . . . . 4 65 4. Transitioning Considerations . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Many of todays HTTP sites are virtual, that is they are hosted on a 74 machine that is not known by the name the HTTP site is known by. 75 This leads to the problem of how to rationally give these HTTP sites 76 IP addresses. This has traditionally been done by using CNAMES 77 [RFC1034] [RFC1035] or by using explicit IP address records where 78 CNAMES are illegal due to restrictions in the DNS. 80 Both of these solutions have undesired side effects. CNAMES are not 81 protocol specific. Using IP address records is a logistic nightmare 82 for large servers with many virtual sites. This is becoming a bigger 83 problem as companies move away from identifying their HTTP site with 84 a "www" prefix and just use their delegated domain name, e.g. 85 "http://example.com/". 87 Using SRV [RFC2782] records would seem to be a natural solution to 88 this problem in that they are protocol specific and will work where 89 CNAMES are illegal in the DNS. 91 There are problems with doing this without thought however in that 92 URIs [RFC3986] can specify a port and SRV records do specify a port. 93 When this occurs which one do you honour? 95 In addition to this SRV records provide for load balancing. For most 96 protocols this is straight forward as there will only be a single 97 connection made. For HTTP however there are often many connections 98 made in a session. Should each of these individual connections be 99 load balanced or should the load balancing be on a per session basis? 101 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT 102 RECOMMENDED", and "MAY" in this document are to be interpreted as 103 described in [RFC2119]. 105 2. URIs without an explicit port specification 107 If the URI does not explicitly specify a port to connect to, i.e. the 108 URI does not contain a ":" part, there is no port conflict. In 109 this case a client MUST follow the logic specified in [RFC2782], 110 including the server selection mechanism provided by the priority and 111 weight fields. If SRV records do not exist then the client MUST fall 112 back to looking for IP address records. 114 Once a server is selected it SHOULD be continued to be used for the 115 rest of the session if possible after an initial connection is made. 116 If a server has multiple addresses the client SHOULD continue to use 117 the same address while possible taking into consideration ttl values 118 on address records. If connections to this address fail it SHOULD 119 try the other addresses for the server first before attempting other 120 servers. 122 The use of a SRV record does not affect the contents of the "Host:" 123 field of the HTTP transaction. Its only effect is to potentially 124 change the address and port the client connects to. All other parts 125 of the HTTP transaction are not affected by the presence of a SRV 126 record. 128 Examples: 130 Single SRV record: 132 URI: http://example.com/ 133 SRV RR: _http._tcp.example.com. SRV 10 0 8080 host1.example.com. 134 A RRs: example.com. A 10.0.0.2 135 host1.example.com. A 10.0.1.1 137 Connect to: 10.0.1.1 port 8080 139 Multiple SRV records: 141 URI: http://example.com/ 142 SRV RRs: _http._tcp.example.com. SRV 10 1 8080 host1.example.com. 143 _http._tcp.example.com. SRV 10 3 8080 host2.example.com. 144 _http._tcp.example.com. SRV 20 0 8080 host3.example.com. 145 A RRs: example.com. A 10.0.0.4 146 host1.example.com. A 10.0.1.2 147 host2.example.com. A 10.0.2.2 148 host3.example.com. AAAA 1080::8:800:200C:417A 150 Connect to: 10.0.1.2 port 8080 or 10.0.2.2 port 8080 if either is 151 available (the probability of being selected should be 25% for 152 10.0.1.2 port 8080, and 75% for 10.0.2.2 port 8080); otherwise, try 153 1080::8:800:200C:417A port 8080. 155 3. URIs with a explicit port specification 157 If the URI does explicitly specify a port, other than the default 158 port, to connect to then there is a potential conflict in the port 159 specification between the URI and the SRV records, and the SRV record 160 is ignored. In this case the user agent MUST query for address 161 records for the host name in the URI (instead of SRV records). 163 If the server has multiple addresses the client SHOULD continue to 164 use the same address while possible taking into consideration ttl 165 values on address records. 167 Note [RFC3986], Section 6.2.3. Scheme-Based Normalization states 168 that URIs with a port value equal to the default port (80) are 169 identical to those with no port or a empty port. 171 Examples: 173 Default port specified: 175 URI: http://example.com:80/ 176 SRV RR: _http._tcp.example.com. SRV 10 1 8080 host2.example.com. 177 A RRs: example.com. A 10.0.0.1 178 host2.example.com. A 10.0.2.2 180 Connect to: 10.0.0.2 port 8080 182 Non-default port specified: 184 URI: http://example.com:8080/ 185 SRV RR: _http._tcp.example.com. SRV 10 1 80 host2.example.com. 186 CNAME RR: example.com. CNAME host1.example.com. 187 A RRs: host1.example.com. A 10.0.0.1 188 host2.example.com. AAAA 1080::8:800:200C:417A 190 Connect to: 10.0.0.1 port 8080 192 4. Transitioning Considerations 194 When transitioning from using a non-SRV solution to using a SRV based 195 solution old, non-SRV aware, clients will continue to look for 196 address records. It may be necessary to use redirection at the HTTP 197 layer to direct these clients to the new servers if the SRV records 198 point to a different tuple. 200 It will also be necessary to continue to provide the existing address 201 / CNAME records until there is a significant percentage of SRV aware 202 clients. Experience has shown that this should be within one to two 203 years of the introduction of the first SRV aware client. 205 In cases where you are just trying to replace the A or CNAME record 206 referring to a service providers machine with a SRV record the 207 following should suffice. 209 The service provider is hosting the service on machine.example.net 210 and you are example.com. 212 example.com. A 213 _http._tcp.example.com. SRV 0 0 80 machine.example.net. 215 5. Security Considerations 217 The authors believe the algorithm described in this document to not 218 cause any new security problems. However care should be taken as SRV 219 and non-SRV aware clients may be directed to different locations. 221 6. IANA Considerations 223 A well known label has to be allocated for the first label of the 224 http SRV record. This document has used "_http". 226 7. Normative References 228 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 229 STD 13, RFC 1034, November 1987. 231 [RFC1035] Mockapetris, P., "Domain names - implementation and 232 specification", STD 13, RFC 1035, November 1987. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 238 specifying the location of services (DNS SRV)", RFC 2782, 239 February 2000. 241 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 242 Resource Identifier (URI): Generic Syntax", STD 66, 243 RFC 3986, January 2005. 245 Authors' Addresses 247 M. Andrews 248 Internet Systems Consortium 249 950 Charter Street 250 Redwood City, CA 94063 251 US 253 Email: marka@isc.org 254 T. Kottelin 255 Laivalahden puistotie 10 C 37 256 Helsinki FIN-00810 257 Finland 259 Email: thor@anta.net