idnits 2.17.1 draft-ibc-websocket-dns-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2011) is 4753 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) == Outdated reference: A later version (-17) exists of draft-ietf-hybi-thewebsocketprotocol-06 -- 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 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Baz Castillo 3 Internet-Draft XtraTelecom S.A. 4 Intended status: Standards Track April 14, 2011 5 Expires: October 16, 2011 7 DNS SRV Resource Records for the WebSocket Protocol 8 draft-ibc-websocket-dns-srv-02 10 Abstract 12 This document specifies the usage of DNS SRV resource records by 13 WebSocket clients when resolving a "ws:" or "wss:" Uniform Resource 14 Identifier (URI). The DNS SRV mechanism confers load-balancing and 15 failover capabilities for WebSocket service providers. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 16, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Client Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. SRV Lookup . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.2. Fallback Process . . . . . . . . . . . . . . . . . . . . . 7 57 4.3. Reusing TCP Connection . . . . . . . . . . . . . . . . . . 8 58 4.4. Server Failure . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 5.1. Load Balancing and Failover . . . . . . . . . . . . . . . 10 61 5.2. Reusing TCP Connection . . . . . . . . . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 67 Appendix A. Change Log (to be removed by RFC Editor prior to 68 publication) . . . . . . . . . . . . . . . . . . . . 15 69 A.1. Changes in -02 . . . . . . . . . . . . . . . . . . . . . . 15 70 A.2. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 DNS SRV [RFC2782] is widely implemented in realtime communication 76 protocols as SIP [RFC3261] and XMPP [RFC6120]. In both protocols the 77 clients perform a DNS SRV query to get a list of connection addresses 78 (pairs of IP address and port) for the given domain. The 79 administrator of the domain can configure its DNS SRV records in a 80 way that they provide automatic load-balancing along with redundancy/ 81 failover capability. 83 DNS SRV mechanism facilitates network applications scalability 84 without requiring an intermediary node distributing the traffic in 85 load-balancing or failover fashion. Instead, DNS SRV mechanism just 86 requires a proper DNS setup. 88 By introducing DNS SRV records into WebSocket protocol 89 [I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can, 90 optionally, take same advantages and provide scalable services with a 91 minimal infrastructure. 93 This specification mandates the usage of DNS SRV resource records by 94 WebSocket clients when resolving a "ws:" or "wss:" URI [RFC3986], but 95 still leaves the decision of using SRV records up to the service 96 administrator. 98 2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Implementation 106 This specification mandates the implementation of DNS SRV [RFC2782] 107 in WebSocket [I-D.ietf-hybi-thewebsocketprotocol] clients (usually 108 web browsers). Said that, WebSocket clients MUST implement this 109 specification. 111 The client application (usually JavaScript code executed by the web 112 browser) is not aware of the mechanism described in this document 113 which is fully transparent for web developers and JavaScript 114 developers. This is, the client application (usually JavaScript 115 code) does not deal with DNS SRV resolution but just passes the given 116 "ws:" or "wss:" URI to the WebSocket client which MUST perform steps 117 in Section 4. 119 It is up to the system administrator whether to set, or not, DNS SRV 120 resource records for the WebSocket protocol within the provided 121 service. This specification allows the system administrator to use 122 the DNS SRV [RFC2782] mechanism to improve the service reliability by 123 providing load-balancing and failover capabilities, but does not 124 mandate it (the system administrator could choose whichever 125 scalability strategy). 127 4. Client Usage 129 DNS SRV lookup just applies when the host component of a WebSocket 130 URI [RFC3986] is a domain and the URI does not contain an explicit 131 port. If this is not the case, the WebSocket client MUST attempt the 132 fallback process described in Section 4.2. 134 To clarify it, a WebSocket URI like "ws://example.org/myservice" 135 requires the client to perform SRV resolution while 136 "ws://example.org:80/myservice" does not (as the port is explicitly 137 present in the URI). 139 4.1. SRV Lookup 141 Given a WebSocket URI ("ws:" or "wss:") in which the host component 142 is a domain ("example.org") and the port is not present, the 143 WebSocket client MUST perform the following steps: 145 1. If the scheme is "ws:", perform a DNS SRV query whose inputs are: 147 * Service: "ws" 149 * Proto: "tcp" 151 * Name: The host component of the URI 153 The resulting query looks like "_ws._tcp.example.org". 155 2. If the scheme is "wss:", perform a DNS SRV query whose inputs 156 are: 158 * Service: "wss" 160 * Proto: "tcp" 162 * Name: The host component of the URI 164 The resulting query looks like "_wss._tcp.example.org". 166 3. If there is no SRV result, attempt the fallback process described 167 in Section 4.2 and omit next steps. 169 4. If there is SRV result, it will contain one or more DNS SRV 170 resource records (combinations of a domain target, port, priority 171 attribute and weight attribute as described in [RFC2782]). 173 5. Choose one of the returned DNS SRV resource records (following 174 the rules in [RFC2782]) and perform DNS A or AAAA lookups on the 175 corresponding domain target. This will result in a list of one 176 or more IPv4 or IPv6 addresses. 178 If the DNS A or AAAA lookup returns no result, it is 179 considered an error and next DNS SRV resource record 180 (according to rules in [RFC2782]) MUST be tried. 182 6. Use the first resolved IP address (with the corresponding port 183 number in the DNS SRV resource record) as the connection address 184 for the WebSocket service. 186 The client MAY now perform steps in Section 4.3 and reuse an 187 existing TCP connection if available. 189 7. If the WebSocket establishment fails using that connection 190 address because of a server failure (according to Section 4.4) 191 but the A or AAAA lookups returned more than one IP address, then 192 use the next resolved IP address for the connection address 193 (keeping same port). 195 8. If the WebSocket establishment fails using all the resolved IP 196 addresses for a given DNS SRV resource record, then repeat the 197 process for the next DNS SRV resource record based on priority 198 and weight attributes as defined in [RFC2782] until all the DNS 199 SRV resource records have been tried. 201 9. If all the attempts fail, internally report the WebSocket 202 establishment error. 204 When the client constructs the WebSocket handshake HTTP request, the 205 URI MUST be set as described in Section 3.2 of 206 [I-D.ietf-hybi-thewebsocketprotocol] regardless of the usage of SRV 207 mechanism. This is, DNS SRV resolution for a "ws:" or "wss:" URI 208 does not alter the usual construction of the WebSocket handshake 209 request. 211 4.2. Fallback Process 213 The fallback process SHOULD be a normal A or AAAA address record 214 resolution to determine the IPv4 or IPv6 address of the URI host 215 component (or URI host value without DNS resolution if it contains an 216 IP address). 218 The server connection port is obtained as stated in Section 3.1 of 219 [I-D.ietf-hybi-thewebsocketprotocol]. 221 If multiple IP addresses have been obtained from a DNS A or AAAA 222 lookup, the client MUST choose the first one and try to establish a 223 WebSocket communication with it. In case such attempt fails because 224 of a server failure (as defined in Section 4.4) the client MUST 225 repeat the process for each remaining IP address. 227 4.3. Reusing TCP Connection 229 A web browser is able to maintain persistent TCP connections with the 230 HTTP [RFC2616] server and reuse them for sending new HTTP requests. 231 Reusing an existing connection (when available) for WebSocket 232 communication is a desirable behavior which just can take place when 233 both the HTTP server and WebSocket server listen on the same IP 234 address and port. 236 This section defines how to reuse an existing connection after 237 resolving the location of the WebSocket server using the DNS SRV 238 procedures: 240 1. The WebSocket client performs the steps in Section 4 and gets an 241 ordered list of connection addresses (pairs of IP address and 242 port) by following rules in [RFC2782]. 244 2. For each connection address the client selects to communicate 245 with, it first checks whether there already exists an established 246 TCP connection against same IP address and port. 248 3. If so, the client MAY reuse the existing TCP connection for 249 initiating the WebSocket handshake rather than opening a new one. 251 4.4. Server Failure 253 A WebSocket server failure occurs if the WebSocket establishment (TCP 254 connection and WebSocket handshake procedure) fails because of a 255 cause listed below: 257 o TCP connection is not possible due to timeout or server side 258 rejection. 260 o The server does not return a valid HTTP response for the WebSocket 261 handshake request within a specified ammount of time (TODO: 262 specify such ammount). 264 o The server replies a 500 or 503 HTTP error response during the 265 WebSocket handshake meaning that it suffers of internal problems 266 (i.e. congestion) so it is not currently capable of handling the 267 request. 269 If HTTP response code other than 101 (success), 500 or 503 is 270 returned by the server, it MUST NOT be considered a server 271 failure. 273 TODO: [I-D.ietf-hybi-thewebsocketprotocol] should describe how 274 to handle different HTTP response codes (as 401 or 302). 276 5. Examples 278 By properly configuring domain SRV records, the WebSocket service 279 administrator can take advantage of load-balancing and failover 280 capabilities inherent in DNS SRV [RFC2782]. Sections below show some 281 usage cases. 283 5.1. Load Balancing and Failover 285 Assuming there are three hosts providing the WebSocket service for 286 the URI "ws://example.org/myservice", the following zone file for a 287 fictional example.org domain provides load-balancing and failover for 288 the WebSocket traffic: 290 $ORIGIN example.org. 291 @ SOA dns.example.org. root.example.org. 292 (2011040501 3600 3600 604800 86400) 293 NS dns.example.org. 294 _ws._tcp SRV 0 3 80 ws1.example.org. 295 _ws._tcp SRV 0 1 90 ws2.example.org. 296 _ws._tcp SRV 1 0 80 ws3.example.org. 298 dns A 1.1.1.100 299 ws1 A 1.1.1.1 300 ws2 A 1.1.1.2 301 ws2 A 1.1.1.3 303 o The first server with domain ws1.example.org listens on IP address 304 1.1.1.1 and port 80, and its associated DNS SRV record has 305 priority 0 and weight 3. 307 o The second server with domain ws2.example.org listens on IP 308 address 1.1.1.2 and port 90, and its associated DNS SRV record has 309 priority 0 and weight 1. 311 o The third server with domain ws3.example.org listens on IP address 312 1.1.1.3 and port 80, and its associated DNS SRV record has 313 priority 1 and weight 0. 315 By following the steps in Section 4, 75% of WebSocket clients would 316 choose the first server and the other 25% would choose the second 317 server to communicate with (as both have the higest SRV priority 0 in 318 their respective DNS SRV resource records, and the first server has a 319 SRV weight value which triples the value of the second server). 321 In case the WebSocket establishment fails because of a server failure 322 (as defined in Section 4.4), WebSocket clients would try the other 323 one. 325 If the WebSocket establishment fails with both the first and second 326 servers, WebSocket clients would then try the third server (as the 327 priority value in its respective DNS SRV resource record is lower). 329 5.2. Reusing TCP Connection 331 In this case a server resolving to www.example.org is used for both 332 HTTP and WebSocket traffic, while a second server resolving to 333 ws2.example.com is used for balancing the WebSocket traffic. 335 $ORIGIN example.org. 336 @ SOA dns.example.org. root.example.org. 337 (2011040501 3600 3600 604800 86400) 338 NS dns.example.org. 339 _ws._tcp SRV 0 1 80 www.example.org. 340 _ws._tcp SRV 0 1 80 ws2.example.org. 342 dns A 1.1.1.100 343 www A 1.1.1.1 344 ws2 A 1.1.1.2 346 The client (presumably a web browser) would open one or more TCP 347 connections with www.example.org and port 80 for the usual HTTP 348 communication. As the retrieved data contains a WebSocket URI 349 "ws://example.org/myservice" the client would also initialize a 350 WebSocket communication so would perform steps in Section 4. 352 Such DNS resolution would return two DNS SRV resource records (the 353 first one with www.example.org as domain target and the second one 354 with ws2.example.org as domain target), both of them with same 355 priority and weight attributes. 357 As per target selection rules in [RFC2782] it is expected that half 358 of the clients would choose www.example.org domain target and port 80 359 as the WebSocket communication address so they MAY reuse an existing 360 TCP connection previously opened rather than creating a new one. 362 6. Security Considerations 364 Any Internet protocol offering DNS SRV resource records for locating 365 servers is sensitive to security issues described in 366 [I-D.barnes-hard-problem]. Usage of DNS security extensions (DNSSEC) 367 as described in [RFC4033] is recommended to mitigate the problem. 369 7. IANA Considerations 371 This specification registers two new SRV Service Labels: 373 ws: MUST be used when constructing a DNS SRV query to locate the 374 WebSocket service address (for regular WebSocket connections). 376 wss: MUST be used when constructing a DNS SRV query to locate the 377 WebSocket service address (for WebSocket connections tunneled 378 over TLS [RFC5246]). 380 8. References 382 8.1. Normative References 384 [I-D.ietf-hybi-thewebsocketprotocol] 385 Fette, I., "The WebSocket protocol", 386 draft-ietf-hybi-thewebsocketprotocol-06 (work in 387 progress), February 2011. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 393 specifying the location of services (DNS SRV)", RFC 2782, 394 February 2000. 396 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 397 Resource Identifier (URI): Generic Syntax", STD 66, 398 RFC 3986, January 2005. 400 8.2. Informative References 402 [I-D.barnes-hard-problem] 403 Barnes, R. and P. Saint-Andre, "High Assurance Re- 404 Direction (HARD) Problem Statement", 405 draft-barnes-hard-problem-00 (work in progress), 406 July 2010. 408 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 409 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 410 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 412 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 413 A., Peterson, J., Sparks, R., Handley, M., and E. 414 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 415 June 2002. 417 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 418 Rose, "DNS Security Introduction and Requirements", 419 RFC 4033, March 2005. 421 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 422 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 424 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 425 Protocol (XMPP): Core", RFC 6120, March 2011. 427 Appendix A. Change Log (to be removed by RFC Editor prior to 428 publication) 430 A.1. Changes in -02 432 o Category changed to "std" (Standards-Track document). 434 o Editorial fixes. 436 o Section "Introduction" extended. 438 o Added a section "Implementation". 440 o Use "DNS SRV resource record" to refer a record in the DNS SRV 441 lookup. 443 o Improvements in section "Fallback Process". 445 o Section "Websocket Establishment Fails" renamed to "Server 446 Failure". 448 o Section "Examples" simplified. 450 A.2. Changes in -01 452 o Editorial fixes. 454 o Avoid the word "target" when referring to connection addresses. 456 o Improvements in section "Examples". 458 Author's Address 460 Inaki Baz Castillo 461 XtraTelecom S.A. 462 Barakaldo, Basque Country 463 Spain 465 Email: ibc@aliax.net