Re: A mechanism to encode HTTP version information in DNS

On Sat, Feb 16, 2013 at 1:34 AM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
>
> ------ Original Message ------
> From: "Amos Jeffries" <squid3@treenet.co.nz>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 16/02/2013 3:19:46 p.m.
> Subject: 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?
>>
>
> if you mean the URI RR data field (as per draft-faltstrom-uri), it can be
> quite long, being defined as a sequence of one or more <character-string>
> which are (byte) length-prefixed strings, but which can be concatenated.
>
> It would more likely run into limitations on max datagram size.  I think
> implementations are supposed to handle at least 576 bytes, but to go bigger
> is a DNS extension, and I don't know how well supported it is. Otherwise
> you fail over to DNS over TCP, which I think would be problematic in our
> case due to added RTs / latency.
>
> in DNS, a label refers to a part of a name (e.g. FQDN is a sequence of
> labels separated by dots), so "URL string label" is a bit confusing.
>
> If you're referring to the authority part of a URI, being a domain name,
> it is subject to the limitations of DNS.



The URI RR scheme allows for multiple string entries but does not fully
specify the semantics (it is a draft after all).

Given existing DNS infrastructure and its treatment of TXT records, the
interpretation least likely to cause issues is to simply catenate the
separate string entries.


While you could int theory have a really long URI here, it would be stupid
and unnecessary to do that. In the first place this is the Web Service
Endpoint which is frequently the prefix rather than the actual URI. If some
idiot has a 512 byte URI for the Web Service endpoint they are not going to
have room for Web Service parameters.

Since DNS does work over TCP, the reasonable answer to stupid
configurations like that is 'they are going to be less efficient and break
if infrastructure is not standards compliant'.

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