Re: on DNS records

On 14.11.2012 05:26, Phillip Hallam-Baker wrote:
> 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).

I was always of the impression that round-robin was a designed feature 
of DNS, not a hack created by HTTP. Maybe I'm missing something but 
don't all other name-based protocols also use DNS round-robin for load 
balancing?


> 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'd like to see an implementation of round-robin operating within the 
text of a SRV record.


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


One could as easily mandate that HTTP implementations perform 
round-robin (or not) on the set of DNS IP results as on the set of SRV 
results. So the above example of "hack" problems appears to be 
irrelevant.


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

Is it? that would be violating the charter requirement that is be 
semantically compatible with HTTP/1.x and fully capable of 2.0->1.1 
gateway translation.

Amos

Received on Wednesday, 14 November 2012 00:09:25 UTC