Re: A mechanism to encode HTTP version information in DNS

Phillip Hallam-Baker <> Sat, 16 February 2013 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF16D21F86D2 for <>; Sat, 16 Feb 2013 08:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.446
X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S1Bhcnv9AjLq for <>; Sat, 16 Feb 2013 08:16:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 159EF21F8700 for <>; Sat, 16 Feb 2013 08:16:33 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U6kPK-0000MH-0Q for; Sat, 16 Feb 2013 16:14:34 +0000
Resent-Date: Sat, 16 Feb 2013 16:14:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U6kPB-0000LA-Pw for; Sat, 16 Feb 2013 16:14:25 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1U6kP8-0002Qi-EH for; Sat, 16 Feb 2013 16:14:25 +0000
Received: by with SMTP id ds1so1661562wgb.0 for <>; Sat, 16 Feb 2013 08:13:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FCheMVzEuJuReVbugKDQS6GhPLNtVJdUFpb7A0+6cMo=; b=XvRLwrgIREYQ80w5+zqwzLAD/k0s9Ds8vkRc2Zh8Kfhpi78Ljksn2WGARyYLVXobvo O+DXDBxDZZsfuz6xlYuHoZz11V+w0HXPUpac4kqr9OFIWSBxnl1nqCDrrlQRDqj/z959 dNy2ETAh/jz2407cFRutQ3+O9HDXgWaeQuooy+7Z0O6sii7+ApW8Ag8SfP4os0vq2HBY SK6fVZgeco4GKqai36IjerNuhz9H+2Y+2NrhT9/ocjelihIl99fxR9B5oPSxKM/nKMx6 dIWCIbfsIguCyjofEh8J4WkNC6vRJI+WLoeFZa3hAC2XbXzwrCZZkmYCMCL0CeV3NcgK iJ1w==
MIME-Version: 1.0
X-Received: by with SMTP id hg3mr9676153wib.33.1361031236222; Sat, 16 Feb 2013 08:13:56 -0800 (PST)
Received: by with HTTP; Sat, 16 Feb 2013 08:13:55 -0800 (PST)
In-Reply-To: <emf8b808aa-ca12-421d-a7e8-f60def882fd5@bombed>
References: <> <emf8b808aa-ca12-421d-a7e8-f60def882fd5@bombed>
Date: Sat, 16 Feb 2013 11:13:55 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Adrien W. de Croy" <>
Cc: Amos Jeffries <>, "" <>
Content-Type: multipart/alternative; boundary=e89a8f3ba6e35cfd3b04d5d9c7fa
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.719, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U6kP8-0002Qi-EH a610c7176069cc510b26350ed7294530
Subject: Re: A mechanism to encode HTTP version information in DNS
Archived-At: <>
X-Mailing-List: <> archive/latest/16620
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> ------ Original Message ------
> From: "Amos Jeffries" <>
> To: "Adrien W. de Croy" <>
> Cc: "" <>
> 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'.