Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Mark Andrews <> Sat, 03 January 2015 21:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A5DD1A1EF3 for <>; Sat, 3 Jan 2015 13:53:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pYVPIltTJ3NA for <>; Sat, 3 Jan 2015 13:53:24 -0800 (PST)
Received: from ( [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600411A1EEF for <>; Sat, 3 Jan 2015 13:53:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 094391FCAC1; Sat, 3 Jan 2015 21:53:20 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id DEE28160066; Sat, 3 Jan 2015 21:59:31 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTPSA id ED3F716005B; Sat, 3 Jan 2015 21:59:30 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id D533D26FFFCD; Sun, 4 Jan 2015 08:53:10 +1100 (EST)
To: Eliot Lear <>
From: Mark Andrews <>
References: <> <> <> <> <>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
In-reply-to: Your message of "Sat, 03 Jan 2015 17:53:46 +0100." <>
Date: Sun, 04 Jan 2015 08:53:10 +1100
Message-Id: <>
Cc: Delan Azabani <>, =?UTF-8?B?TcOl?= =?UTF-8?B?bnMgTmlsc3Nvbg==?= <>,, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jan 2015 21:53:28 -0000

In message <>om>, Eliot Lear writes:
> Hi Patrik,
> On 1/3/15 4:49 PM, Patrik Fältström wrote:
> >> On 3 jan 2015, at 15:32, MÃ¥ns Nilsson <>
> wrote:
> >>
> >> I strongly support incorporating SRV record support in the HTTPbis
> >> specification.
> > FWIW, I am also in favor or SRV, although I (being biased) think "how
> > to use URI with HTTP2" would not be a bad addition either[1].
> >
> > We do though have multiple discussions like these, that I do not think
> > really conclude:
> >
> > <>
> >
> > Because of this, what I think IS (at least) needed in the http2 spec
> > are a few words about DNS. Else the discussions will just continue and
> > continue...
> >
> > One could for example say something like:
> >
> > "If the URI does not include a path (only consists of scheme and
> > authority, which in turn include domain), a client MIGHT look up either
> > SRV record _http._tcp.domain or URI for the same owner_http._tcp.domain
> > and act on the result of those lookups according to the SRV and URI spec
> > respectively."
> >
> > And then reference some "happy eyeballs" specification on how to do it
> > in detail.
> There there was a fuller discussion about this in the WG about two years
> ago, and then again last year.  As John pointed out there are a few more
> issues, one of which is that the release philosophy taken by the WG is
> that there is some expectation that HTTP2 will not be the last version
> released, and some additions may come sooner than later.  This presents
> several problems for SRV.  First, as a matter of IANA policy we don't
> normally allocate more than one name for the same service, no matter the
> version.  This is something of a sore point, and a general one at that.
> One would really like to be able to pass some initial protocol parameter
> information back as part of a DNS query such that the information could
> be reasonably cached (oh, say versioning?).  I am not convinced that the
> WG has a full handle on this with the various header games being
> considered, but there was a fair bit of discussion about this as well a
> while back, and there are some tradeoffs to be made, like binding the
> information tightly to the connection and all of its attendant
> properties.  Also, tying versioning of any form into the DNS where the
> different versions have different security properties makes the solution
> dependent on DNSSEC.  I'm ALL for DNSSEC, but as there are alternatives
> that don't require it, it's not the draw we would like in this case.
> And no, you needn't preach to the choir on this point: it really SHOULD
> be a draw because it provides huge possibilities for doing all sorts of
> fun application initialization, but I digress.
> Second, even if we did handle versioning in SRV, there are known to be
> residential gateways out there that can't handle very many parallel DNS
> queries, and so we run into a loss problem.

SRV doesn't require lots of parallel DNS queries.  I suspect in
most cases there would be a single SRV record pointing to the hosting
service.  There is only a single CNAME record pointing to the hosting
service today.

If one needs versioned HTTP / HTTPS records 

> Finally, to address MÃ¥ns' comments, additional data for the target
> doesn't get signed (but correct me if I missed a change). 

Additional data is returned with RRSIGs and always has been.  Glue
records are not signed but that is not what we are talking about

An example with a MX record and with a MX target's address records
in the cache.  I cut out the NS RRset and the additional record
related to it and their RRSIGs.

% dig mx +dnssec

; <<>> DiG 9.11.0pre-alpha <<>> mx +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11360
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 17

; EDNS: version: 0, flags: do; udp: 4096
;			IN	MX

;; ANSWER SECTION:		7165	IN	MX	10		7165	IN	MX	10		7165	IN	RRSIG	MX 5 2 7200 20150201123610 20150102123610 4521 AV82lsdjjsKFOIjlw74l6Q/MSxnApZkbtsHFtYrPBybm/argxDVuWE76 SlCsZv6oL9a8wVBQ5+K6snhwfy7YUbvDVe6RUbEwt+/o85F442Vk/6zc XEu/A23sYyK/uX4X1yCU3wSldtGn65InBjXAyuLgngGogUCdSKMenyoa 2wk=


[cut]	3586	IN	AAAA	2001:4f8:0:2::2b
[cut]	3581	IN	RRSIG	A 5 4 3600 20150128233258 20141229233258 2781 yjA8uFr2Et7ciHsTs7JZzelqfPgaP7NAYJZpc5BJ3S4cB/jV7oqU5IJu jOuEuvjxNCMMTDGe0OFTXWZkWxxd3EHkRH9K32U7OaGell9ztUokiV4W Ny5wIa5RtLGDVVKEEfIG+EqU9AhrTDK8xR1Gygd4IYb6xUKFo9Nb+KHY YSg=	3586	IN	RRSIG	AAAA 5 4 3600 20150128233258 20141229233258 2781 Ar1Y++KzlS+ub7AsQRKymQe1cCs2vqVkLr57MSEg/KvVq93iD9J12nj/ ARo/occj9rCC3NFTI0vJSYokeuz02PovUKB4y53dH0CemaOvTKMxVvNi sCq+E66H7F+R9y6yWFxnjpQIGRv1c822pF7XDtEyXwwesZLNxAPFI9ns AEI=

;; Query time: 0 msec
;; WHEN: Sun Jan 04 08:28:30 EST 2015
;; MSG SIZE  rcvd: 2071

Now if one actually wants to signal which version of HTTP are
supported in the DNS then actual HTTP records would be the way to
go containing flags, version, preference, weight, port and target.

	HTTP flags version preference weight port target

	flags: 16 bits
	       SECURE (https available)
	version: txt field
	preference: 16 bits
	weigth: 16 bits
	port: 16 bits
	target: domain

and say that if the target is a CNAME that the CNAME will be added
to the additional section and that it will be followed.  One could
even have HTTP indicate that targets SHOULD be fetched before

> (Actually,
> one of things I wanted from DPRIVE was the ability to handle multiple
> questions in the same transaction, but alas, probably not.)  In
> addition, with caching times down to small numbers of minutes for many
> sites (or less), we probably can't say that this is a simple 1st
> transaction cost.  What's more many enterprises do a zone cut at
>, and it is not uncommon to see TCP connections for
> those transactions (I know at least one network administrator who
> thought it was unheard of *not* to do a zone cut and delegation at
> _tcp).  To address a bunch of these issues I had posited a record [1]
> that actually made use of the same QNAME, but it really is quite (dare
> the author say overly?) complex.

So what if they do a zone cut?  That doesn't stop the recursive server
caching the results and combining them.

> And this leads us back to performance.  I personally do not have an
> answer for what acceptable performance is in these circumstances.  And
> so some experimentation would really REALLY be good.  Is 100 ms for this
> feature acceptable? 30? 80? 200?  I really can't say, and there was no
> desire in the WG to go this far.  I will say that Cisco has an open RFP
> for related work if any researchers want to take the challenge.[2]
> Eliot
> [1]
> [2]
> html

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: