Re: on DNS records

On Wed, Nov 14, 2012 at 08:18:45PM +0100, Eliot Lear wrote:
> Martin,
> On 11/14/12 8:13 PM, Martin Thomson wrote:
> > On 14 November 2012 11:09, Eliot Lear <lear@cisco.com> wrote:
> >> That's a fair point.  Question: how would you handle SRV with
> >> http://www.example.com:49080?
> > That was raised in the meeting.  SRV isn't enough for that reason
> > alone.  I know too many hosts that operate on different ports.
> > Obviously, each port could be given a new name, but that eventually
> > leads to an increase in the number of wildcard certificates out there.
> >
> >
> 
> Thanks.  So you would prefer some other record that simply indicates
> what version runs on what port and dump transport protocol?  What do
> others think?

That was one of the issue I raised several times a few months ago
explaining why I think DNS alone cannot be a solution.

The problem we have with DNS is that it's only server-centric. One single
authority decides what to advertise as the way to connect to their site.
That can work for new ports. But not for port 80. The reason is that on
port 80, you have many components along the chain doing many things such
as simple protocol inspection, load balancing, proxying, caching, etc...
that neither the server not the client sides are aware of !

Thus it's foolish to assume that a different protocol can be talked on port
80 without prior upgrade.

Using DNS to advertise a different port could be a solution to avoid the
HTTP Upgrade, because it could allow users to detect that HTTP/2.0 is
spoken natively on a specific port on the server. However it would still
not take into account the fact that client-side filtering on firewalls
and proxies generally don't allow unknown ports to pass.

A new problem with advertising random ports in DNS records is that it
would be much harder to gain unfiltered access than by advertising only
a standardized port. And if we have a standard port we don't need to
advertise the port in the DNS record.

Ports still cause two new troubles :
  - how to decide what protocol version to use on port XYZ ? (I've seen
    Phillip's proposal, I still think that another natural solution would
    be a dedicated scheme)

  - how can we know that the new port it controlled by the same authorities
    as ports 80/443 along the whole path ?

I'm still thinking that we should do more research on the scheme :

   - keep "http://" as the default scheme which MUST only speak HTTP/1.x
     because that has always been the case. A temptative Upgrade to 2.0
     is encouraged but both the clients and the server know that this
     upgrade is optional, may fail and the traffic may remain HTTP/1.

   - have "https://" use the TLS NPN extension to announce support for
     the protocol on both sides. I should say on "all" sides, because TLS
     is a transport protocol and as such is hop-by-hop : if intercepted,
     the interceptor's capabilities are used. At least this has proved to
     work well for SPDY and I don't see why we should refrain from using
     this for HTTP/2.

   - have "http2://" as the optimal replacement scheme for the long term,
     on a dedicated well-known port. To the opponents of the new scheme,
     I would say that this has worked for http->https, and I don't see
     any reason for this not to work again, quite the opposite. In fact,
     there would be much incentive to migrate to support this scheme as
     there would possibly be some performance benefits by doing so. And
     just like many web sites still support https and http for the few
     https-impaired users, we would have https/http2 by default, and
     http as the fallback for those who can only use port 80.

Obviously the switch will take time, a few years to get a fairly common
adoption, but this way we're sure to always provide an upgradable path
from HTTP/1, and without breaking what has been assumed for decades (eg:
http://x.y.z:port/ is http and not anything else, then we'd equally
have http2://x.y.z:port/ be http2 and not http).

So in the end, we'd get the following possibilities to connect to a web
site from a user agent :

  - if scheme is "https://", use the best HTTP version advertised as NPN
    by the server ;

  - if scheme is "http2://", use raw HTTP/2 exclusively over the designated
    port and report an error if it fails (as we do right now with https).
    THIS is what will drive quick opening of the new port on the client side.

  - if scheme is "http://", attempt an 1.1->2.0 Upgrade over the designated
    port, with the possibility that it will remain 1.x only.

Regards,
Willy

Received on Wednesday, 14 November 2012 22:10:52 UTC