Re: on DNS records

On Tue, Nov 13, 2012 at 7:08 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

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


It was invented by Eric Binna, Lou Montouli, Rob McCool and the folk at
NCSA as a desperate BIND hack to save their ass when downloads of Mosaic
required a server farm to support.



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


SRV was designed to render round robin unnecessary. It has the same load
balancing capability as the MX record. In fact it is simply a
generalization of MX.



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


Round robin does not work very well and never has done. The problem is that
DNS records are cached and the caching resolver has no idea what the
relative priority of the servers is. Nor does it have any idea about
matching the request on a geographic basis.



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


A HTTP/1.1 server will not be able to understand 2.0 traffic unless
upgraded. Hence it is a backwards incompatible change with a
transition/upgrade strategy.


-- 
Website: http://hallambaker.com/