idnits 2.17.1 draft-andrews-http-srv-01.txt: -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(203): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 46 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RFC1034], [RFC1035], [RFC1738], [RFC2782]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2002) is 8106 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 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Andrews (ISC) 3 T. Kottelin 4 Updates: RFC 2782 February 2002 6 Use of SRV records in conjuction with HTTP and URIs. 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Comments should be sent to the authors. 31 This draft expires on August 2002 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All rights reserved. 37 Abstract 39 The combined use of SRV records for HTTP along with URIs is not as 40 straight forward as it would appear at first glance. This document 41 looks at the issues involved and recommends solutions. 43 Introduction 45 Many of todays HTTP sites are virtual, that is they are hosted on a 46 machine that is not known by the name the HTTP site is known by. 47 This leads to the problem of how to rationally give these HTTP sites 48 IP addresses. This has traditionally been done by using CNAMES 49 [RFC1034][RFC1035] or by using explicit IP address records where 50 CNAMES are illegal due to restrictions in the DNS. 52 Both of these solutions have undesired side effects. CNAMES are not 53 protocol specific. Using IP address records is a logistic nightmare 54 for large servers with many virtual sites. This is becoming a bigger 55 problem as companies move away from identifying their HTTP site with 56 a ``www'' prefix and just use their delegated domain name, e.g. 57 ``http://example.com/''. 59 Using SRV [RFC2782] records would seem to be a natural solution to 60 this problem in that they are protocol specific and will work where 61 CNAMES are illegal in the DNS. 63 There are problems with doing this without thought however in that 64 URIs [RFC1738] can specify a port and SRV records do specify a port. 65 When this occurs which one do you honour? 67 In addition to this SRV records provide for load balancing. For most 68 protocols this is straight forward as there will only be a single 69 connection made. For HTTP however there are often many connections 70 made in a session. Should each of these individual connections be 71 load balanced or should the load balancing be on a per session basis? 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119. 77 1. URIs without an explicit port specification 79 If the URI does not explicitly specify a port to connect to, i.e. the 80 URI does not contain a ``:'' part, there is no port conflict. 81 In this case a client MUST follow the logic specified in [RFC2782], 82 including the server selection mechanism provided by the priority and 83 weight fields. If SRV records do not exist then the client MUST fall 84 back to looking for IP address records. 86 Once a server is selected it SHOULD be continued to be used for the 87 rest of the session if possible after an initial connection is made. 88 If a server has multiple addresses the client SHOULD continue to use 89 the same address while possible taking into consideration ttl values 90 on address records. If connections to this address fail it SHOULD 91 try the other addresses for the server first before attempting other 92 servers. 94 Examples: 96 Single SRV record: 98 URI: http://example.com/ 99 SRV RR: _http._tcp.example.com. SRV 10 0 8080 host1.example.com. 100 A RRs: example.com. A 10.0.0.2 101 host1.example.com. A 10.0.1.1 103 Connect to: 10.0.1.1 port 8080 105 Multiple SRV records: 107 URI: http://example.com/ 108 SRV RRs: _http._tcp.example.com. SRV 10 1 8080 host1.example.com. 109 _http._tcp.example.com. SRV 10 3 8080 host2.example.com. 110 _http._tcp.example.com. SRV 20 0 8080 host3.example.com. 111 A RRs: example.com. A 10.0.0.4 112 host1.example.com. A 10.0.1.2 113 host2.example.com. A 10.0.2.2 114 host3.example.com. AAAA 1080::8:800:200C:417A 116 Connect to: 10.0.1.2 port 8080 or 10.0.2.2 port 8080 if either is 117 available (the probability of being selected should be 25% for 118 10.0.1.2 port 8080, and 75% for 10.0.2.2 port 8080); otherwise, try 119 1080::8:800:200C:417A port 8080. 121 2. URIs with a explicit port specification 123 If the URI does explicitly specify a port to connect to then there is 124 a potential conflict in the port specification between the URI and 125 the SRV records, and the SRV record is ignored. In this case the 126 user agent MUST query for address records for the host name in the 127 URI (instead of SRV records). 129 If the server has multiple addresses the client SHOULD continue to 130 use the same address while possible taking into consideration ttl 131 values on address records. 133 Examples: 135 Default port specified: 137 URI: http://example.com:80/ 138 SRV RR: _http._tcp.example.com. SRV 10 1 8080 host2.example.com. 139 A RRs: example.com. A 10.0.0.1 140 host2.example.com. A 10.0.2.2 142 Connect to: 10.0.0.1 port 80 144 Non-default port specified: 146 URI: http://example.com:8080/ 147 SRV RR: _http._tcp.example.com. SRV 10 1 80 host2.example.com. 148 CNAME RR: example.com. CNAME host1.example.com. 149 A RRs: host1.example.com. A 10.0.0.1 150 host2.example.com. AAAA 1080::8:800:200C:417A 152 Connect to: 10.0.0.1 port 8080 154 3. Transitioning Considerations 156 When transitioning from using a non-SRV solution to using a SRV based 157 solution old, non-SRV aware, clients will continue to look for 158 address records. It may be necessary to use redirection at the HTTP 159 layer to direct these clients to the new servers if the SRV records 160 point to a different tuple. 162 It will also be necessary to continue to provide the existing address 163 / CNAME records until there is a significant percentage of SRV aware 164 clients. Experience has shown that this should be within one to two 165 years of the introduction of the first SRV aware client, for HTTP. 167 In cases where you are just trying to replace the A or CNAME record 168 referring to a service providers machine with a SRV record the 169 following should suffice. 171 The service provider is hosting the service on machine.example.net 172 and you are example.com. 174 example.com. A 175 _http._tcp.example.com. SRV 0 0 80 machine.example.net. 177 Security Considerations 179 The authors believe the algorithm described in this document to not 180 cause any new security problems. However care should be taken as SRV 181 and non-SRV aware clients may be directed to different locations. 183 IANA Considerations 185 A well known label has to be allocated for the first label of the 186 http SRV record. This document has used ``_http''. 188 References 190 [RFC1034] 191 Domain names - concepts and facilities. P.V. Mockapetris. 192 Nov-01-1987. STD 0013, RFC 1034. 194 [RFC1035] 195 Domain names - implementation and specification. P.V. Mockapetris. 196 Nov-01-1987. STD 0013, RFC 1035. 198 [RFC1738] 199 Uniform Resource Locators (URL). T. Berners-Lee, L. Masinter, M. McC� 200 ahill. December 1994. RFC 1738. 202 [RFC2782] 203 A DNS RR for specifying the location of services (DNS SRV). A. Gul� 204 brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782. 206 Authors' Addresses 207 Mark Andrews 208 Internet Software Consortium 209 1 Seymour St. 210 Dundas Valley, NSW 2117, Australia 211 +61 2 9871 4742 212 Mark.Andrews@isc.org 214 Thor Kottelin 215 Laivalahden puistotie 10 C 37 216 FIN-00810 Helsinki, Finland 217 +358 400878169 218 thor@anta.net