Re: [hybi] Alternative for SRV proposal

Willy Tarreau <> Sun, 24 July 2011 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D474F21F8829 for <>; Sun, 24 Jul 2011 12:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.559
X-Spam-Status: No, score=-4.559 tagged_above=-999 required=5 tests=[AWL=-2.816, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cj8+QqioPu0y for <>; Sun, 24 Jul 2011 12:56:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E432621F86BD for <>; Sun, 24 Jul 2011 12:56:04 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6OJu0SE027354; Sun, 24 Jul 2011 21:56:00 +0200
Date: Sun, 24 Jul 2011 21:56:00 +0200
From: Willy Tarreau <>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <>
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/
Subject: Re: [hybi] Alternative for SRV proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jul 2011 19:56:05 -0000

On Sun, Jul 24, 2011 at 09:16:58PM +0200, Iñaki Baz Castillo wrote:
> Hi, it's clear enough for me that DNS SRV will be not implemented in
> web browsers for WebSocket URIs resolution. I understand some of the
> reasons (not all however).
> So I'm thinking about a future (extension) for WebSocket protocol and
> API (sorry, I don't know yet the propose WS API so I use pseudo-code):
> a) Let's suppose a JavaScript code contains a WS connection, something
> like this:
>     var mysocket = new WebSocket("ws://", null);
> Note that there is a second parameter that is null. It would mean (as
> the current spec states) that a DNS A query should be performed for
> the given URI (or not if there is already a TCP connection).
> b) I propose an optional second argument:
>     var mysocket = new WebSocket("ws://", "ws://");
> If the browser supports the new WS extension I'm suggesting, the
> browser could *decide* whenever perform DNS A for the first URI or a
> DNS SRV for the second URI. For example, WS clients within mobile
> devices could decide to always use the first URI so just DNS A would
> be done (or not if it was already resolved and connected). In the
> other side, desktop web browsers implementing this new extension would
> use, by default, the second URI with all the SRV stuff.

It is even worse, because it's error-prone and will make it harder for
site authors to maintain. And you'd have to convince the WHATWG too for
an API change.

Instead, why not keep the single parameter ?

 $ host -t srv has SRV record 5 0 5269 has SRV record 5 0 5269 has SRV record 5 0 5269

 $ host -t aaaa has no AAAA record

 $ host -t a is an alias for is an alias for is an alias for

The browsers configured for SRV would first run the SRV request, and fall
back to AAAA/A while the other ones would skip SRV.

We could even refine the process : you could make it mandatory that for an
SRV record to be presented, the main host would necessarily have a CNAME
record. The idea is that most of the time, CNAME records will point to the
same entries as SRV records. Thus you can avoid the slowdown for most
situations that way :

   1) resolve
   2) if it has at least a CNAME and if SRV is enabled, then retry with SRV
   3) if not, or if SRV fails, use AAAA/A as returned

That way you can make use of SRV by default without impacting too
many sites (only those with a CNAME).

I'm not saying it's beautiful, but it can be a tradeoff between costs and
chances of adoption.