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

Re: on DNS records

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Tue, 13 Nov 2012 11:26:55 -0500
Message-ID: <CAMm+Lwh9mjw98C-CmU_TqYJDHEaE_7fLLpeU=q89ky34YKaOww@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I would say that the requirement for the DNS option for signalling upgrade
be that

1) It be an instance of a general mechanism that can be used to signal more
than just protocol version and more than just information to HTTP.

2) It be possible to secure the protocol version information to prevent
downgrade attacks, and upgrade attacks.

In band upgrade hacks are a one-off solution. Complexity is frequently the
result of too many one-off solutions. We do occasionally have complexity
from systems that are too general (ISAKMP, EAP, GSSAPI). But that comes
from schemes that are designed to allow people to achieve the same basic
function in an infinite variety of ways. I can't think of a case where we
have introduced too much complexity by specifying one 'right' way to
implement a function plus one or two fallback mechanisms to work-around
legacy issues.

There are also advantages to defining a DNS mechanism that are not quite
requirements. One of them being that HTTP/1.1 use of DNS is rather a mess
and this provides an opportunity to clean it up.

In particular, HTTP relies on DNS server hacks to implement load balancing
(the round robin hack). SRV is a better solution for Web, URI is a better
solution for Web Services. But neither SRV nor URI are complete in that
respect as neither addresses geographic load balancing.

I do not want to get into the issue of how to implement those features
right here and now. But I would like us to take an approach to getting out
of the HTTP version swamp that provides us with the necessary hooks to get
out of the load balancing, geography etc. swamps in the future.

HTTP/2.0 is an incompatible upgrade. When you break backwards compatibility
you should always have (1) a very good reason to do so and (2) an
explanation for why you do not expect to do so again.

On Tue, Nov 13, 2012 at 11:07 AM, Eliot Lear <lear@cisco.com> wrote:

> James,
> The question I asked isn't whether or not to use DNS, but what the
> requirements for a record would be.  From Phil I gather that limited
> complexity is a goal (we will of course argue what that means).  What
> are your goals for a DNS record?
> Eliot

Website: http://hallambaker.com/
Received on Tuesday, 13 November 2012 16:27:36 UTC

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