Re: A mechanism to encode HTTP version information in DNS

On 15/02/2013 9:05 p.m., Adrien W. de Croy wrote:
>
> Are you talking about DNS labels?
I was yes. Does this include the URL string label?

>
> DNS label max length is 63 (6 bits) only, due to overloading of offset 
> pointer with label length.
>
> overall domain name max length is 255, although this is I guess 
> relatively arbitrary, it's possible to code a longer name on a DNS 
> packet, but not a longer label.
>

So the big question: is the URL string field a label? or do we catenate 
it from multiple labels?

Amos


>
>
> ------ Original Message ------
> From: "Amos Jeffries" <squid3@treenet.co.nz>
> To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 15/02/2013 6:46:52 p.m.
> Subject: Re: A mechanism to encode HTTP version information in DNS
>> On 15/02/2013 9:16 a.m., Phillip Hallam-Baker wrote:
>>> Encoding HTTP version information in DNS is easy if you don't 
>>> particularly care about using DNS properly or want to do anything 
>>> more than encode HTTP version information.
>>>
>>> Doing it well gets rather more complex. A DNS query costs a round 
>>> trip so you would ideally like to make it pay. Also the process of 
>>> deploying DNS records takes some time and it is better to reuse an 
>>> existing record but only if that will not create ambiguity.
>>>
>>> Looking again at the URI record, I think that we could use it to 
>>> provide a HTTP version flag and other useful features in the DNS. In 
>>> particular we can use the URI record to effect a HTTP redirect in 
>>> DNS (a UDP round trip) rather than require a TCP round trip. It also 
>>> provides for fault tolerance and load balancing and works well with 
>>> Web Services.
>>
>> One small note on this assertion:
>>   FQDN are capable of being anything up to 256 octets long 
>> *per-label*. When the FQDN is greater than 250 octets or so this will 
>> add both a UDP round trip plus a TCP round trip, on top of the final 
>> connection setup round trip. This may not seem a critical point, but 
>> we are already encountering web sites and services with >64 octet 
>> FQDN in public traffic which is causing TLS certificate issues.
>>
>>
>> That asside, I am liking this proposal better than any of the earlier 
>> DNS proposals. I can forsee support from Squid being implemented if 
>> this is selected to go ahead.
>>
>> Amos
>>
>>
>

Received on Saturday, 16 February 2013 02:49:07 UTC