Re: [hybi] DNS SRV for WebSocket

Iñaki Baz Castillo <ibc@aliax.net> Mon, 28 March 2011 17:28 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD7128C0F1 for <hybi@core3.amsl.com>; Mon, 28 Mar 2011 10:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.042
X-Spam-Level:
X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ytawarHB1M for <hybi@core3.amsl.com>; Mon, 28 Mar 2011 10:28:39 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5F4303A689A for <hybi@ietf.org>; Mon, 28 Mar 2011 10:28:39 -0700 (PDT)
Received: by qwg5 with SMTP id 5so2436720qwg.31 for <hybi@ietf.org>; Mon, 28 Mar 2011 10:30:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.63.154 with SMTP id b26mr2341216qci.163.1301333416752; Mon, 28 Mar 2011 10:30:16 -0700 (PDT)
Received: by 10.229.35.72 with HTTP; Mon, 28 Mar 2011 10:30:16 -0700 (PDT)
In-Reply-To: <e0g1p6tuimb0foemn8la0f3r8hpd4ha03t@hive.bjoern.hoehrmann.de>
References: <BANLkTi=G6bc=FquLM8agKWojmDkD9FohxA@mail.gmail.com> <4D90BE10.8050801@callenish.com> <BANLkTimLdsPnWZ1cLhEi2NdW0eizsfQhqQ@mail.gmail.com> <e0g1p6tuimb0foemn8la0f3r8hpd4ha03t@hive.bjoern.hoehrmann.de>
Date: Mon, 28 Mar 2011 19:30:16 +0200
Message-ID: <BANLkTinz4AGb58YfnOK7oa2PFKEpMnh0TQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] DNS SRV for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 17:28:42 -0000

2011/3/28 Bjoern Hoehrmann <derhoermi@gmx.net>:
> * Iñaki Baz Castillo wrote:
>>So the WS client should check for the existence of a SRV record for
>>the given domain (if no port is given), but the SRV record could exist
>>or not. It's very flexible but, of course, in order to work properly,
>>it should be mandatory for WS clients.
>
> It would seem very unlikely that all client implementations will do this
> (because the feature is obscure to many, lack of test servers, lack of
> proper DNS libraries that make this easy, not getting around to it, not
> caring, and so on). As I understand it, not supporting SRV lookups is a
> common problem with simpler XMPP implementations, for instance. So, if
> this was mandatory for Websocket clients, we'd likely be looking at many
> non-compliant implementations. Putting it the other way around, usually
> people don't implement features just because they are formally required.

A WS client could not support SRV and still work. Example:


- For domain mydomain.org there are a DNS SRV record and 3 DNS A records:

  SRV record:

     _ws._tcp.mydomain.org. IN SRV 1 0 80 mydomain.org.
     _ws._tcp.mydomain.org. IN SRV 2 0 8080 backup.mydomain.org.

  A records:

      mydomain.org.                 1.1.1.1
      backup.mydomain.org.      1.1.1.2


- The web page indicates the following WS URI:  ws://mydomain.org.



case 1) SRV capable WS client
-----------------------------------------------------------------------

- It performs a SRV query for domain=mydomain.org, service=ws and transport=tcp.

- It gets the SRV record with two entries and chooses the first one
(with best priority).

- So it performs a DNS A query for domain "mydomain.org" and gets 1.1.1.1.

- Then it connects to 1.1.1.1:80.

- In case the server is unreachable, the client tries the second
location by performing a DNS A query for backup.mydomain.org and gets
1.1.1.2, so it connects to 1.1.1.2:8080 (failover, oh yeah !!!).



case 2) Non-SRV capable WS client
-----------------------------------------------------------------------

- It performs a DNS A query for domain=mydomain.org and gets 1.1.1.1.

- Then it connects to 1.1.1.1:80.

- In case the server is unreachable the client cannot do failover due
to its limitation (it doesn't support SRV, sorry).



So, as you can see, it's not fully required that the client supports
SRV, but if it does, it can take COOL advantages from it.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>