W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: A mechanism to encode HTTP version information in DNS

From: Adrien W. de Croy <adrien@qbik.com>
Date: Fri, 15 Feb 2013 08:05:53 +0000
To: "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em409d680a-c794-47a8-822c-3783d781dcf2@bombed>

Are you talking about DNS labels?

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.



------ 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 Friday, 15 February 2013 08:06:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 15 February 2013 08:06:21 GMT