Re: [hybi] Alternative for SRV proposal

Willy Tarreau <w@1wt.eu> Sun, 24 July 2011 20:51 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A2D21F8582 for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 13:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.472
X-Spam-Level:
X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[AWL=-2.729, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbI0Xo9XP03p for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 13:51:24 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B85D421F8570 for <hybi@ietf.org>; Sun, 24 Jul 2011 13:51:23 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6OKpKXp027511; Sun, 24 Jul 2011 22:51:20 +0200
Date: Sun, 24 Jul 2011 22:51:20 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110724205120.GH22405@1wt.eu>
References: <CALiegfni83KAFTeo1vo_XLmLhVSAR_BxYwLoSkOizJ1ToHfqhw@mail.gmail.com> <20110724195600.GF22405@1wt.eu> <CALiegfn8B4YzbAz9zp8s6t=47nSqCaqc3SjH3LE5m6ffC3Ht+w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALiegfn8B4YzbAz9zp8s6t=47nSqCaqc3SjH3LE5m6ffC3Ht+w@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Alternative for SRV proposal
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 24 Jul 2011 20:51:24 -0000

On Sun, Jul 24, 2011 at 10:21:20PM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <w@1wt.eu>eu>:
> > 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).
> 
> 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).

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.

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

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