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.

Table of Contents

• 1. Introduction
• 2. Conventions
• 3. Client Usage
• 3.1. SRV Lookup
• 3.2. Fallback Process
• 3.3. WebSocket Establishment Fails
• 4. Reusing TCP Connection
• 5. Examples
• 5.1. Load Balancing
• 5.2. Load Balancing and Failover
• 5.3. Reusing TCP Connection
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Change Log (to be removed by RFC Editor prior to publication)
• Appendix A.1. Changes in -01
• Appendix A.2. Changes in -00
• Author's Address

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.

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].

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].
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:

• TCP connection is not possible due to timeout or server side rejection.
• The server does not return a valid HTTP response for the WebSocket handshake request within a specified ammount of time (TODO: specify such ammount).
• 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).

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.

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.

              
$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
              
            

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.

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]).

8. References

8.1. Normative References

8.2. Informative References

Appendix A. Change Log (to be removed by RFC Editor prior to publication)

Appendix A.1. Changes in -01

• Editorial fixes.
• Avoid the word "target" when referring to connection addresses.
• Improvements in Examples.

Appendix A.2. Changes in -00

• Initial version.

Author's Address