Subject: [hybi] Alternative for SRV proposal

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 24 Jul 2011 21:16:58 +0200

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://www.mydomain.org", 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://www.mydomain.org", "ws://mydomain.org");

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.

I don't like it too much as the service provider cannot anticipate how
clients would resolve the WS server, but for me is better than just
playing with A records and server side failover / load-balancing.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 21:56:00 +0200

> 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 ?

Eg:
 $ host -t srv _ws-server._tcp.www.mydomain.org
 _ws-server._tcp.www.mydomain.org has SRV record 5 0 5269 ws1.mydomain.org
 _ws-server._tcp.www.mydomain.org has SRV record 5 0 5269 ws2.mydomain.org
 _ws-server._tcp.www.mydomain.org has SRV record 5 0 5269 ws3.mydomain.org

 $ host -t aaaa www.mydomain.org
 www.mydomain.org has no AAAA record

 $ host -t a www.mydomain.org
 www.mydomain.org is an alias for ws1.mydomain.org
 www.mydomain.org is an alias for ws2.mydomain.org
 www.mydomain.org is an alias for ws3.mydomain.org

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 www.mydomain.org
   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.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 24 Jul 2011 22:21:20 +0200

> many sites (only those with a CNAME).

But that would require two DNS queries (in case of CNAME), am I wrong?
and that seems to be a problem (due to explanations given in the other
thread).

Why not just making SRV optional but ensuring that the domain in the
URI also has a A/AAAA resolution? This is:

ws://mydomain.org

1) ~# host -t A mydomain.org
    1.2.3.4

2) ~# host -t srv _ws._tcp.mydomain.org
    1 50 server01.mydomain.org
    1 50 server02.mydomain.org
    2  0 server-backup.mydomain.org

2a) ~# host -t A server01.mydomain.org
       1.2.3.4

2b) ~# host -t A server02.mydomain.org
       1.2.3.5

2b) ~# host -t A server-backup.mydomain.org
       9.9.9.9

Clients with no SRV support (or disabled as mobile browsers) should
just perform step 1 while other WS clients would/could try step 2 (and
2a, 2b, 2c...).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 24 Jul 2011 22:51:20 +0200

> and that seems to be a problem (due to explanations given in the other

Exact, but that would only be the case where the entry is declared as a
CNAME, not always. CNAME will be needed as a fallback for SRV if SRV is
made optional anyway.

> just perform step 1 while other WS clients would/could try step 2 (and

But that would cause the second request (SRV) to be performed all the
time when it is enabled. You can be sure that many users will disable
it when they notice that their web is faster without.

With the CNAME trick, the second request only happens if the first one
returns a CNAME.

In fact, I think we're missing a "SERVICES" record which would return
for a given host the list of services that are known to run on it. That
way you could run "host -a mydomain.org" and see :
;; ANSWER SECTION:
mydomain.org.       159     IN      A 1.2.3.4
mydomain.org.       159     IN      SERVICES _ws._tcp.
mydomain.org.       159     IN      SERVICES _http._tcp.

That way with a single request you could get the address *and* be informed
of the running services, making it worth trying again for those.

Regards,
Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 25 Jul 2011 03:16:58 +0200

> CNAME, not always. CNAME will be needed as a fallback for SRV if SRV is

Hummm, AFAIK some local DNS resolvers automatically resolve the CNAME
domain to an IP before passing the DNS result to the application, so
the application would not be aware of the existence of a CNAME record.

> of the running services, making it worth trying again for those.

I think you mean NAPTR records ;)

Those NAPTR records are used in SIP protocol to discover which
transport (UDP, TCP, TLS-TCP, SCTP...) to use (by preference of the
destination domain administrator).

In WS it could be something like:

  example.org  IN   NAPTR 1 0 "S" "WS+D2T" "" _ws._tcp.example.org.

But this would be an extra DNS query so there would be:

a) NAPTR + SRV +`A/AAAA

or

b) NAPTR + A/AAAA

It does not fit well with constrains exposed in the other mail thread.

Regards.
-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 25 Jul 2011 06:37:51 +0200

> the application would not be aware of the existence of a CNAME record.

I'm not aware of that and it sounds strange to me.

>   example.org  IN   NAPTR 1 0 "S" "WS+D2T" "" _ws._tcp.example.org.

OK, I didn't know them, so that's fine this way.

> It does not fit well with constrains exposed in the other mail thread.

It does fit well as something at the option of the end user, because as
Mark says, one can send the NAPTR + A + AAAA "at zero cost" (assuming
the uplink is infinite). It does not require extra round trips, just
extra bandwidth and some extra synchronization from the client.

Willy

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 25 Jul 2011 11:51:25 +0200

> I'm not aware of that and it sounds strange to me.

I was not exactly right. I use a local DNS cache/resolver (called
Unbound for Linux).

- I query it a DNS A for ghs.google.com.
- Unbound queries it to the DNS server.
- It receives a reply telling that ghs.google.com has just a CNAME
record (ghs.l.google.com).
- Unbound then queries DNS A for ghs.l.google.com.
- It receives "209.85.147.121".
- Then Unbound replies to my client with two answers:
    1) ghs.google.com: CNAME, cname ghs.l.google.com
    2) ghs.l.google.com: A, addr 209.85.147.121

So yes, by inspecting the DNS response the client can realize of the
presence of a CNAME for the queried domain.

> extra bandwidth and some extra synchronization from the client.

It sounds good but, wouldn't it be too much not required information?
this is, a DNS ANY query retrievesa all the resource records for the
given domain.

-- 
Iñaki Baz Castillo
<[email-masked]>