Network Working Group I. Baz Castillo
Internet-Draft XtraTelecom S.A.
Intended status: Informational April 12, 2011
Expires: October 14, 2011
DNS SRV Resource Records for the WebSocket Protocol
draft-ibc-websocket-dns-srv-01
Abstract
This document specifies the usage of DNS SRV resource records by
WebSocket clients when resolving a "ws:" or "wss:" Uniform Resource
Identifier (URI). The DNS SRV mechanism confers load-balancing and
failover capabilities for WebSocket service providers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 14, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Baz Castillo Expires October 14, 2011 [Page 1]
Internet-Draft DNS SRV for WebSocket April 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Client Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRV Lookup . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Fallback Process . . . . . . . . . . . . . . . . . . . . . 6
3.3. WebSocket Establishment Fails . . . . . . . . . . . . . . 6
4. Reusing TCP Connection . . . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Load Balancing and Failover . . . . . . . . . . . . . . . 9
5.3. Reusing TCP Connection . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change Log (to be removed by RFC Editor prior to
publication) . . . . . . . . . . . . . . . . . . . . 14
A.1. Changes in -01 . . . . . . . . . . . . . . . . . . . . . . 14
A.2. Changes in -00 . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Baz Castillo Expires October 14, 2011 [Page 2]
Internet-Draft DNS SRV for WebSocket April 2011
1. Introduction
DNS SRV [RFC2782] is widely implemented in realtime communication
protocols as SIP [RFC3261] and XMPP [RFC6120]. In both cases clients
perform a DNS SRV query to locate the transport, IP address and port
of the server they want to contact. The administrator of the domain
can configure its DNS SRV records in a way that they provide
automatic load-balancing along with redundancy/failover capability.
By introducing DNS SRV records into WebSocket protocol
[I-D.ietf-hybi-thewebsocketprotocol], WebSocket providers can,
optionally, take same advantages and offer robust services without
requiring expensive server-side solutions.
This specification mandates the usage of DNS SRV queries by WebSocket
clients when resolving a "ws:" or "wss:" URI, but still leaves the
decision of using SRV records up to the service administrator.
Baz Castillo Expires October 14, 2011 [Page 3]
Internet-Draft DNS SRV for WebSocket April 2011
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Baz Castillo Expires October 14, 2011 [Page 4]
Internet-Draft DNS SRV for WebSocket April 2011
3. Client Usage
This specification mandates the implementation of DNS SRV mechanism
in WebSocket clients (usually web browsers). DNS SRV lookup just
applies when the host component of a WebSocket URI is a domain and
the URI does not contain an explicit port. If this is not the case,
the client MUST attemp the fallback process described in Section 3.2.
To clarify it, a WebSocket URI like "ws://example.org/myservice"
requires the client to perform SRV resolution while
"ws://example.org:80/myservice" does not (as the port is explicitly
present in the URI).
3.1. SRV Lookup
Given a WebSocket URI ("ws:" or "wss:") in which the host component
is a domain ("example.org") and the port is not present, the
WebSocket client MUST perform the following steps:
1. If the scheme is "ws:", perform a DNS SRV query whose inputs are:
* Service: "ws"
* Proto: "tcp"
* Name: The host component of the URI
The resulting query looks like "_ws._tcp.example.org".
2. If the scheme is "wss:", perform a DNS SRV query whose inputs
are:
* Service: "wss"
* Proto: "tcp"
* Name: The host component of the URI
The resulting query looks like "_wss._tcp.example.org".
3. If there is no SRV result, attempt the fallback process described
in Section 3.2 and omit next steps.
4. If there is SRV result, it will contain one or more combinations
of a port and FQDN, each of which contains a priority and weight
attributes as described in DNS SRV [RFC2782].
Baz Castillo Expires October 14, 2011 [Page 5]
Internet-Draft DNS SRV for WebSocket April 2011
5. Choose at least one of the returned FQDNs to resolve (following
the rules in DNS SRV [RFC2782]) by performing DNS A or AAAA
lookups on the FQDN. This will result in an IPv4 or IPv6
address.
6. The client uses the IP address(es) from the successfully resolved
FQDN (with the corresponding port number returned by the SRV
lookup) as the connection address for the WebSocket service.
* The client MAY now perform steps in Section 4 and reuse an
existing TCP connection if available.
7. If the WebSocket establishment fails (according to Section 3.3)
using that IP address but the A or AAAA lookups returned more
than one IP address, then use the next resolved IP address for
that FQDN as the connection address.
8. If the WebSocket establishment fails using all resolved IP
addresses for a given FQDN, then repeat the process of resolution
and connection for the next FQDN returned by the SRV lookup based
on the priority and weight as defined in DNS SRV [RFC2782] until
all the SRV record entries are tryed (in that case internally
report the WebSocket establishment error).
When the client constructs the WebSocket handshake HTTP request, the
URI MUST be set as described in Section 3.2 of
[I-D.ietf-hybi-thewebsocketprotocol] regardless of the usage of SRV
mechanism. This is, DNS SRV resolution over a "ws:" or "wss:" URI
does not alter the usual construction of the WebSocket handshake
request.
3.2. Fallback Process
The fallback process SHOULD be a normal A or AAAA address record
resolution to determine the IPv4 or IPv6 address of the URI host
component (or URI host value without DNS resolution if it contains an
IP address).
The server connection port is obtained as stated in Section 3.1 of
[I-D.ietf-hybi-thewebsocketprotocol].
3.3. WebSocket Establishment Fails
TODO: This section should be present in
[I-D.ietf-hybi-thewebsocketprotocol] rather than here.
A WebSocket establishment fails if one of the following cases occurs
when contacting the server:
Baz Castillo Expires October 14, 2011 [Page 6]
Internet-Draft DNS SRV for WebSocket April 2011
o TCP connection is not possible due to timeout or server side
rejection.
o The server does not return a valid HTTP response for the WebSocket
handshake request within a specified ammount of time (TODO:
specify such ammount).
o The server replies a 500 or 503 HTTP error response for the
WebSocket handshake meaning that it suffers of internal problems
(i.e. congestion) and that it is not currently capable of handling
the request.
* If HTTP response code other than 101 (success), 500 or 503 is
returned by the server, it MUST NOT be considered a WebSocket
establishment failure. TODO:
[I-D.ietf-hybi-thewebsocketprotocol] should describe how to
handle different HTTP response codes (as 401 or 302).
Baz Castillo Expires October 14, 2011 [Page 7]
Internet-Draft DNS SRV for WebSocket April 2011
4. Reusing TCP Connection
When using HTTP/1.1 [RFC2616] the client is able to mantain
persistent connections with the server and reuse them for sending new
HTTP requests. Reusing an existing connection (when available) for
WebSocket communication is a desirable behavior which just can take
place when both the HTTP server and WebSocket server listen on the
same IP address and port.
This section defines how to reuse an existing connection after
resolving the location of the WebSocket server using the DNS SRV
mechanism specified in this document:
1. The WebSocket client performs the steps in Section 3 and gets an
ordered list of connection addresses (pairs of IP address and
port) by following rules in DNS SRV [RFC2782].
2. For each connection address the client selects to communicate
with, it first checks whether there already exists an established
TCP connection against same IP address and port.
3. If so, the client MAY reuse the existing TCP connection for
sending the WebSocket handshake request rather than openning a
new one.
Baz Castillo Expires October 14, 2011 [Page 8]
Internet-Draft DNS SRV for WebSocket April 2011
5. Examples
By properly configuring domain SRV records, the WebSocket service
administrator can take advantage of load-balancing and failover
capabilities inherent in DNS SRV [RFC2782]. Sections below show some
usage cases.
5.1. Load Balancing
Assuming there are two hosts providing the WebSocket service for the
URI "ws://example.org/myservice", the first one listening into IP
address 1.1.1.1 and port 80, and the second one listening into IP
address 1.1.1.2 and port 90, the following zone file for a fictional
example.org domain provides load-balancing for WebSocket service by
dispatching the traffic over both servers as both have same SRV
priority value (the first one will handle the 75% of the traffic due
to its SRV weight value which is 3 times higher than the weight value
of the second server).
$ORIGIN example.org.
@ SOA dns.example.org. root.example.org.
(2011040501 3600 3600 604800 86400)
NS dns.example.org.
_ws._tcp SRV 0 3 80 ws1.example.org.
_ws._tcp SRV 0 1 90 ws2.example.org.
dns A 1.1.1.100
ws1 A 1.1.1.1
ws2 A 1.1.1.2
5.2. Load Balancing and Failover
Same case as above but adding a third server for the case in which
both initial servers are not accessible (i.e. both are down). The
new server listens on IP 1.1.1.3 and port 80. Its lower SRV priority
confers this server a backup status.
The WebSocket client would first try servers "ws1.example.org" and
"ws2.example.org" as they have the highest priority. If the TCP
connection fails in both cases (according to Section 3.3) the
WebSocket client would choose "ws3.example.org" (the only with less
priority) as failover server.
Baz Castillo Expires October 14, 2011 [Page 9]
Internet-Draft DNS SRV for WebSocket April 2011
$ORIGIN example.org.
@ SOA dns.example.org. root.example.org.
(2011040501 3600 3600 604800 86400)
NS dns.example.org.
_ws._tcp SRV 0 3 80 ws1.example.org.
_ws._tcp SRV 0 1 90 ws2.example.org.
_ws._tcp SRV 1 0 80 ws3.example.org.
dns A 1.1.1.100
ws1 A 1.1.1.1
ws2 A 1.1.1.2
ws2 A 1.1.1.3
5.3. Reusing TCP Connection
In this case "www.example.org" is used for both HTTP and WebSocket
traffic, while a second server "ws2.example.com" is used for
balancing the WebSocket traffic.
The client (presumably a web browser) would open one or more TCP
connections with "www.example.org" and port 80 for the usual HTTP
communication. As the retrieved data contains a WebSocket URI
"ws://example.org/myservice" the client would also initialize a
WebSocket communication. As per target selection rules in DNS SRV
[RFC2782] it is expected that half of the clients would choose
"www.example.org" FQDN and port 80 as the WebSocket communication
address so they MAY reuse the existing TCP connection previously
opened rather than opening a new one.
$ORIGIN example.org.
@ SOA dns.example.org. root.example.org.
(2011040501 3600 3600 604800 86400)
NS dns.example.org.
_ws._tcp SRV 0 1 80 www.example.org.
_ws._tcp SRV 0 1 80 ws2.example.org.
dns A 1.1.1.100
www A 1.1.1.1
ws2 A 1.1.1.2
Baz Castillo Expires October 14, 2011 [Page 10]
Internet-Draft DNS SRV for WebSocket April 2011
6. Security Considerations
Any Internet protocol offering DNS SRV resource records for locating
servers is sensitive to security issues described in
[I-D.barnes-hard-problem]. Usage of DNS security extensions (DNSSEC)
as described in [RFC4033] is recommended to mitigate the problem.
Baz Castillo Expires October 14, 2011 [Page 11]
Internet-Draft DNS SRV for WebSocket April 2011
7. IANA Considerations
This specification registers two new SRV Service Labels:
ws: MUST be used when constructing a DNS SRV query to locate the
WebSocket service address (for regular WebSocket connections).
wss: MUST be used when constructing a DNS SRV query to locate the
WebSocket service address (for WebSocket connections tunneled
over TLS [RFC5246]).
Baz Castillo Expires October 14, 2011 [Page 12]
Internet-Draft DNS SRV for WebSocket April 2011
8. References
8.1. Normative References
[I-D.ietf-hybi-thewebsocketprotocol]
Fette, I., "The WebSocket protocol",
draft-ietf-hybi-thewebsocketprotocol-06 (work in
progress), February 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
8.2. Informative References
[I-D.barnes-hard-problem]
Barnes, R. and P. Saint-Andre, "High Assurance Re-
Direction (HARD) Problem Statement",
draft-barnes-hard-problem-00 (work in progress),
July 2010.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
Baz Castillo Expires October 14, 2011 [Page 13]
Internet-Draft DNS SRV for WebSocket April 2011
Appendix A. Change Log (to be removed by RFC Editor prior to
publication)
A.1. Changes in -01
o Editorial fixes.
o Avoid the word "target" when referring to connection addresses.
o Improvements in Examples.
A.2. Changes in -00
o Initial version.
Baz Castillo Expires October 14, 2011 [Page 14]
Internet-Draft DNS SRV for WebSocket April 2011
Author's Address
Inaki Baz Castillo
XtraTelecom S.A.
Barakaldo, Basque Country
Spain
Email: ibc@aliax.net
Baz Castillo Expires October 14, 2011 [Page 15]