W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: on DNS records

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 15 Nov 2012 00:05:10 +0100
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Eliot Lear <lear@cisco.com>, Martin Thomson <martin.thomson@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20121114230510.GQ18082@1wt.eu>
Hi Pat,

On Wed, Nov 14, 2012 at 05:44:09PM -0500, Patrick McManus wrote:
> On Wed, Nov 14, 2012 at 5:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> >
> >
> > That was one of the issue I raised several times a few months ago
> > explaining why I think DNS alone cannot be a solution.
> >
> >
> it cannot do the job alone - but it can provide the best service (i.e.
> similar level of service as NPN on tls)

Except that NPN is not mangled by invisible intermediaries.

> for many best-practice use cases of
> http://. Other cases can use an additional approach (alternate-protocol,
> upgrade, etc..) which will certainly be necessary to fill in the gaps. SRV
> is essentially a routing mechanism, if you're doing routing some other way
> (i.e. a proxy, or a port in the URL, or something that manipulates your
> dns) then don't use it. We'll need to also provide another option.

But the problem is that you don't know that you're passing through proxies,
otherwise I would have no problem with this.

> But it is totally forseeable to see http://www.example.com/ generate
> A? www.example.com
> return
> A =
> Additional Records: {SRV _http2-npn._tcp.www.example.com port=443 host=
> www.example.com ,
>                               SRV
> _http2-cleartext._tcp.www.example.comport=81 host=
> www.example.com}
> and that's a pretty darn powerful sequence that should imo be enabled.

I don't claim it's not powerful, I'm saying that it does not offer benefits
from a deployment point of view above other solutions, but it comes with a
whole bunch of new issues.

After how long do you decide that port 81 fails to connect ? And how do
you offer the end-user the possibility to connect via port 80 which he
*knows* works ? Does "http://www.example.com:80/" suffice to force HTTP/1
over port 80 or will some browsers just attempt raw http2 over that port ?

Also the other issue here is that the web becomes totally fragmented, with
any user advertising random ports, including the port 6000 range that is
well-known to pass through many firewalls due to some X11 pass-through,
etc... In the end, for proxy and firewall admins, it becomes a nightmare
to minimally secure their installations.

You see, all these are issues that are overlooked from the DNS admin, but
which are realities on the end-user side. This is why I don't believe that
the server-side admin knows better than his visitors how they should connect
to the net.

Received on Wednesday, 14 November 2012 23:05:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC