Re: [hybi] Alternative for SRV proposal

Willy Tarreau <w@1wt.eu> Mon, 25 July 2011 04:37 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 8074F11E808B for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 21:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.353
X-Spam-Level:
X-Spam-Status: No, score=-4.353 tagged_above=-999 required=5 tests=[AWL=-2.610, 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 sfwgixcOfQVY for <hybi@ietfa.amsl.com>; Sun, 24 Jul 2011 21:37:55 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 103FC11E808A for <hybi@ietf.org>; Sun, 24 Jul 2011 21:37:54 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p6P4bpii028404; Mon, 25 Jul 2011 06:37:51 +0200
Date: Mon, 25 Jul 2011 06:37:51 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110725043751.GL22405@1wt.eu>
References: <CALiegfni83KAFTeo1vo_XLmLhVSAR_BxYwLoSkOizJ1ToHfqhw@mail.gmail.com> <20110724195600.GF22405@1wt.eu> <CALiegfn8B4YzbAz9zp8s6t=47nSqCaqc3SjH3LE5m6ffC3Ht+w@mail.gmail.com> <20110724205120.GH22405@1wt.eu> <CALiegfmw=emUhnyCvr8Lya00N9q7S06zOxvB9itg4ixjAH1kfg@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: <CALiegfmw=emUhnyCvr8Lya00N9q7S06zOxvB9itg4ixjAH1kfg@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: Mon, 25 Jul 2011 04:37:56 -0000

On Mon, Jul 25, 2011 at 03:16:58AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <w@1wt.eu>eu>:
> >> 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.
> 
> 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.

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

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

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

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

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