Re: A mechanism to encode HTTP version information in DNS

"Adrien W. de Croy" <> Sun, 17 February 2013 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C15B21E803F for <>; Sun, 17 Feb 2013 13:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.278
X-Spam-Status: No, score=-10.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DrtbLnLMSAVS for <>; Sun, 17 Feb 2013 13:34:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 32AAD11E809C for <>; Sun, 17 Feb 2013 13:34:01 -0800 (PST)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1U7BqS-0003Fq-T3 for; Sun, 17 Feb 2013 21:32:24 +0000
Resent-Date: Sun, 17 Feb 2013 21:32:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U7BqJ-0003Eo-V7 for; Sun, 17 Feb 2013 21:32:15 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1U7BqH-0008Bg-T4 for; Sun, 17 Feb 2013 21:32:15 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v7.5.0 (Build 3491)) with SMTP id <>; Mon, 18 Feb 2013 10:33:53 +1300
From: "Adrien W. de Croy" <>
To: "Eliot Lear" <>, "Phillip Hallam-Baker" <>
Cc: " Group" <>
Date: Sun, 17 Feb 2013 21:31:49 +0000
Content-Type: multipart/alternative; boundary="------=_MBBBD83918-5B0C-4974-801F-0DCA4D34FB28"
In-Reply-To: <>
Message-Id: <em19001c37-6187-47f9-abbf-616f745bbdfa@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <>
User-Agent: eM_Client/5.0.17263.0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.7
X-W3C-Hub-Spam-Report: AWL=-3.172, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.556, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1U7BqH-0008Bg-T4 be2c0f517b09c57cb4639ff980d5e9bb
Subject: Re: A mechanism to encode HTTP version information in DNS
Archived-At: <>
X-Mailing-List: <> archive/latest/16630
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I've always thought one of the issues with SRV is the transport is in 
the wrong part - the name, so you can't specify that with the result.

For something new, we should look at putting the transport into the RR 
data instead of the name

then it makes it possible to deploy over multiple transports later on, 
e.g. SCTP, UDP whatever if desired.

------ Original Message ------
From: "Eliot Lear" <>
To: "Phillip Hallam-Baker" <>
Cc: " Group" <>
Sent: 17/02/2013 11:59:24 p.m.
Subject: Re: A mechanism to encode HTTP version information in DNS
>You're hitting at the heart of a key issue, and rather than focus on 
>mechanisms, I urge folk to take a look at the very beginning of 
>draft-lear-httpbis-svcinfo-rr where I state design goals.  One of those 
>goals is to not harm latency.  What you describe below introduces a 
>dependency of  QNAME on target, forcing an additional query, which is 
>one of the key issues with SRV.
>Now, I am not saying that's the wrong thing to do.  But I am saying 
>that it violates that stated design goal.  Maybe the goal is the wrong 
>one to have?
>On 2/14/13 9:16 PM, 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.
>>The format of the URI record is currently: <priority> <weight> 
>>Priority - uint16
>>Weight - uint16
>>Target - string
>>While Target is technically a list of string entries it is not a good 
>>idea to depend on the string boundaries for technical reasons and so 
>>multiple strings should probably be considered equivalent to the 
>>result of concatenating them together.
>>For example: two servers offering HTTP service for ''
>>  URI 10 10 ""
>>  URI 10 10 ""
>>OK so that is not very interesting but the existing but the URI scheme 
>>also permits services to be advertised under a different scheme such 
>>as https or coap (or ftp if you must!)
>>So to force an upgrade to TLS we might specify the following:
>>  URI 10 10 ""
>>  URI 10 10 ""
>>Or to advertise multiple protocols:
>>  URI 10 10 ""
>>  URI 10 10 "coap://"
>>Or to map a domain to a path on another server:
>>  URI 10 10 
>>All those capabilities are useful in the context of HTTP discovery. 
>>They allow a redirect to be effected through the DNS rather than 
>>require a server deployment. But it would be much nicer if we could 
>>encode both a target URI and some description of that target to allow 
>>client selection. For example:
>>* IP version
>>* HTTP protocol version
>>* HSTS data
>>We don't always need this data but when we do it is very useful. But 
>>it turns out that the existing URI record might already meet this need 
>>since a URI cannot have a space inside it and so we can use that as a 
>>delimeter between the target URI and any parameters. We are currently 
>>discussing the details of this on DNSEXT but it looks like it works 
>>  URI 10 10 " ipv4 ipv6"
>>  URI 10 10 " http2"
>>  URI 10 10 " sts"
>>The same mechanism can be used to effect pinning or to alert the 
>>client to the existence of a DANE record.
>>Knowing whether the site supports IPv4 or IPv6 or both allows us to 
>>optimize any A record lookup.
>>We could even specify the ASN number of the server IP address in the 
>>URI record. Why might you want to know that? Well it allows a client 
>>to select a server likely to be closer
>>The same mechanism can be used for a Web Service only there we would 
>>use the protocol prefix of the Web Service rather than HTTP.