Re: [hybi] Alternative for SRV proposal

[Willy Tarreau <[e-mail]>]

On Mon, Jul 25, 2011 at 03:16:58AM +0200, Iñaki Baz Castillo wrote:
> 2011/7/24 Willy Tarreau <[e-mail]>:
> >> 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