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

From: Delan Azabani <[email-masked]>
Date: Fri, 2 Jan 2015 16:29:16 +0800

I'm not sure if it's appropriate for a random netizen like myself to
contribute to these comments, so my apologies in advance if it isn't.

Please consider supporting SRV resource records.

HTTP is simultaneously important enough that one can't simply run a
single server for any popular application, but not so important that it
deserves to necessarily be the A/AAAA record for every hostname.

SRV makes service discovery more flexible than even MX records by:

  * Decoupling the default use of TCP port 80 for HTTP, allowing hosts
    to run multiple distinct HTTP servers without needing a reverse
    proxy or requiring users to explicitly override the port;

  * Allowing server administrators to create a tiered and weighted form
    of load balancing by using the record's Priority and Weight fields,
    again without shifting the point of failure to reverse proxies; and

  * Making it easier to transparently and scalably host services for
    multiple protocols on a single apex domain name.

Although the Target field of a SRV RR is a domain name, not an IPv6 or
IPv4 address, the resolution delay before a TCP connection is initiated
is unlikely to increase significantly because:

  * To reduce the need for multiple queries, "Implementors are urged,
    but not required, to return the address record(s) in the Additional
    Data section." [RFC 2782 page 4]

  * Like the record types PTR, MX and CNAME, "Domain names in RRs which
    point at another name should always point at the primary name and
    not the alias. This avoids extra indirections in accessing
    information." [RFC 1034 § 3.6.2]

To further avoid the complexity and inefficiency of multiple queries,
'only the service name "http" should be used' when SRV records are
used, not the synonyms "www" or "www-http". [RFC 6335 § 5]

LDAP, SIP, XMPP and Kerberos are successful examples of protocols which
rely on SRV resource records for service discovery.

For these benefits to be realised however, HTTP/2 should explicitly opt
into support for SRV records, because "Service SRV records SHOULD NOT
be used in the absence of" an indication in the protocol specification
that clients should use SRV records for discovery. [RFC 2782 page 2]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 03 Jan 2015 13:09:32 +0100

Hi Delan,

We have had a fair amount of discussions about this, and I would say
that perhaps very few people would disagree with what you wrote below. 
However, an additional level of indirection in the SRV record can come
at a cost, which is additional latency, and perhaps a lot of additional
latency on first use, and it depends on a lot of factors, like RR TTLs
on both the SRV record itself and the A record that is returned as part
of RDATA, and whether or not that record itself requires multiple
queries to satisfy.  And so we examined not one, but several new
different RRs to address those concerns, but in the end, people want to
get on with getting out the door what is in the document now.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sat, 03 Jan 2015 09:12:38 -0500

One comment in addition to Eliot's, which while I generally
agree...

--On Saturday, 03 January, 2015 13:09 +0100 Eliot Lear
<[email-masked]> wrote:

>...

>...
>> HTTP is simultaneously important enough that one can't simply
>> run a single server for any popular application, but not so
>> important that it deserves to necessarily be the A/AAAA
>> record for every hostname.

If I understand the above part of your comments correctly, "one
A/AAAA record..." hasn't been necessary since HTTP 1.1
introduced the HTTP "host" verb.  That was a lesson we learned
from SMTP, FTP, and elsewhere -- virtual hosts should not
require separate (either physical or virtual) interfaces and
addresses.

That decision was made well before SRV records were sufficiently
deployed to be meaningful, but Eliot's point stands: there were
(and are) a number of complicated tradeoffs in this situation (I
don't think his list is complete, but both of you probably know
that), and the community made a rational decision about them.
Whether that decision should be reviewed today might be another
question, but the transition and deployment issues would
themselves become another tradeoff.

   john

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 3 Jan 2015 15:32:29 +0100

Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard Date: Sat, Jan 03, 2015 at 01:09:32PM +0100 Quoting Eliot Lear ([email-masked]):
> queries to satisfy.  

Getting bad results as described above requires breaking a number
of established operations practices. 
Simply keeping SRV and target AAAA/A records in the same zone or at least
in the set of zones served by the same name server(s) will let the name
server send a SRV reply and bundle the host records as Additional Data.

Besides, caching. It is here, and given the herd behaviour pattern of the 
user population it is likely that all popular (ie. loadwise relevant)
records show up in warm caches in all major resolver farms.

And just look at the CNAME chaining going on in various steamy server
farms. That it works and with speed is as close to wonder as I'd like
to go in a scientific setting ;-)

> And so we examined not one, but several new

That things might not work right now and that current implementations have
issues with suboptimal configuration have not stopped people from using,
developing and refining more farsighted resource location systems before.
There are known issues that make the specification of a new HTTP protocol 
version important; one of which is the reliance on singular hosts in the
service location part. The urgency is felt, but the addition of a proven
record system for redundance and load balance should , while adding some
delay, pay back in terms of operational gains, and then some.

I strongly support incorporating SRV record support in the HTTPbis 
specification. 
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
You mean you don't want to watch WRESTLING from ATLANTA?

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 3 Jan 2015 16:49:53 +0100

> On 3 jan 2015, at 15:32, Måns Nilsson <[email-masked]> wrote:
> 

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:

<https://news.ycombinator.com/item?id=8404612>

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.

What I think would be good with such text is that _http._tcp would be well defined (and it should be repeated in the IANA considerations section).

And maybe even replace _http with _http2 which might even make things more efficient?

   Patrik

[1] The URI RR Type 256 has been registered for a number of years, but the I-D that describe the use (draft-faltstrom-uri) has been stuck in IESG for quite a number of years. AD has been working on unstucking it for half a year or so, and I hope it really will happen shortly.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 03 Jan 2015 17:53:46 +0100

Hi Patrik,

> 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. 

Finally, to address Måns' comments, additional data for the target
doesn't get signed (but correct me if I missed a change).  (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
_tcp.example.com, 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.

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] http://tools.ietf.org/html/draft-lear-httpbis-svcinfo-rr
[2]
http://www.cisco.com/web/about/ac50/ac207/crc_new/university/RFP/rfp13077.html

---

From: Delan Azabani <[email-masked]>
Date: Sun, 4 Jan 2015 01:06:55 +0800

Without immediately addressing what has later been discussed in this
thread, I should probably clarify what I meant in my original post.

> require separate (either physical or virtual) interfaces and

With the introduction of the Host header, virtual hosts indeed do not
require new interfaces or addresses, be they physical or virtual.

Regardless of this, if I was to request <http://foo.example/> using a
current HTTP/1.1 user agent, the AAAA and/or A records for foo.example.
would be queried, potentially using the Happy Eyeballs algorithm.

If the entity behind foo.example. wanted to run their primary HTTP
service on a host other than the one indicated by the AAAA or A
records, the closest solutions now would be to configure the host on
the bare domain to either route or reverse proxy to the real server.

This may occur for example if foo.example. uses a shared web hosting
provider, while wanting to serve HTTP as well as other protocols
directly on their bare domain.

The ability to use SRV records would eliminate the additional traffic
and computational overhead required for routing or reverse proxying.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 04 Jan 2015 08:18:46 +1100

In message <[email-masked]>, =?utf-8?B?TcOlbnM=?= Nils
son writes:
>
> Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext
> Transfer Protocol version 2) to Proposed Standard Date: Sat, Jan 03, 2015
> at 01:09:32PM +0100 Quoting Eliot Lear ([email-masked]):
> > Hi Delan,
> >

Or we could add a EDNS flag/option which tells the recursive server
to fetch the SRV targets *before* returning the response.  This
could also say follow CNAME chains of the target if they happen to
exist.  You then get the same performance as a CNAME chain with a
A/AAAA lookup.

The only difference between SRV and CNAME is which entity triggers
the additional lookups.  The client or the recursive server.

The SRV client can set the option / flag (both of which are supposed
to be ignored if not understood).  As the recursive server population
implements the option / flag performance will increase when the
record in not already in the cache.  The SRV client still falls
back to direct A/AAAA lookups if there isn't a record for the SRV
target in the additional section.

> to go in a scientific setting ;-)

It all depends on caching.

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

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 3 Jan 2015 22:22:10 +0100

> On 3 jan 2015, at 17:53, Eliot Lear <[email-masked]> wrote:
> 

If the future of the Internet is defined by the state of todays CPE's, instead of defining how the future of the CPE's should work, I think IETF is on the wrong track. Completely the wrong track.

Yes, these arguments do indeed come up now and then, and I every time stand up saying "be careful, be very careful".

On top of that I do not agree with your statement. More and more CPEs are linux based and run the same resolver code as anything else that is unix based, and if the world is to run DNS according to how DNS was defined in 1995 instead of how it is defined now, we can as well go back to HTTP 1.0 from 1.1 instead of going from 1.1 to 2.0.

I.e. I am much more concerned over the changes in the HTTP protocol than whatever requirements you put on DNS.

Regarding your other arguments, my main point was that even if there was a discussion in the wg two years ago, there is no trace what so ever in the draft about how DNS is to be used, so the questions will come back. Until there is a text. A text we can either agree or disagree on. But ultimately find consensus about.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 3 Jan 2015 22:23:34 +0100

> On 3 jan 2015, at 18:06, Delan Azabani <[email-masked]> wrote:
> 

Specifically together with SNI.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Sun, 04 Jan 2015 08:53:10 +1100

In message <[email-masked]>, Eliot Lear writes:
> > 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].
> >
> > 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...
> >
> > "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."
> >

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 

> 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
here.

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 isc.org +dnssec

; <<>> DiG 9.11.0pre-alpha <<>> mx isc.org +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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org.			IN	MX

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

;; AUTHORITY SECTION:
[Cut]

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

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; 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
returning.

> (Actually,

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

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 3 Jan 2015 23:04:20 +0100

> doesn't get signed (but correct me if I missed a change).  

My testing reveals that 

- if the Additional Data is signed, 

- if the answering name server holding the SRV record also holds authority
  over the records in the Target field of the queried SRV records,

..then the Additional data will be sent with RRSIG records. It
is, however, a common configuration of for instance NSD to use
"minimal-responses" setup wherein Additional is not sent even when it
would be possible. In that case, of course, the signatures won't get
sent, either.

Test case: 

dig @primary.se _kerberos._udp.besserwisser.org. SRV +dnssec

	(Server BIND 9, does send Additional. I did test on NSD too,
	and there no Additional is sent, on that particular server node.)

> for related work if any researchers want to take the challenge.[2]

So, what I'm reading here, paraphrased, can be rewritten, tongue-in-cheek
to "We are so certain SRV will take time compared to strange 4-hop CNAME
scenarios that we won't test it." ;-)

Back-of-envelope test: 

Since we've established, above, that Additional MAY be sent and that
some name servers do send it, we can test thusly:

	(I've got a local unbound on the node and the network latency
	is below 1 ms from my machine to the closest server so this is
	just processing delay variations)

for i in `seq 1 20` ; do
	unbound-control flush_zone kth.se > /dev/null 2>1
	dig kth.se A | awk '/Query\ time:/ { printf "A\t%d\n",$4; }'
	unbound-control flush_zone kth.se > /dev/null 2>1 
	dig _kerberos._udp.kth.se SRV |awk '/Query\ time:/ { printf "SRV\t%d\n",$4; }'
done

(now, don't go load KTH name servers too much, please.) 

I did a 50 each query run of the above and came up with data that looks
like it is no difference between A and SRV. Hardly surprising. I did
not ask with +dnssec, (kth.se is signed) but behaviour is identical and
there are no truncation issues, since the EDNS0 buffer goes up.

http://vvv.besserwisser.org/Public/Bilder/QTIME.spectrum.png

The cost of SRV vs the cost of A+CNAME thus seems to be entirely dependent
on how things are configured. Not on SRV /per se/. The guide lines for
SRV deployment are then identical to those for A/CNAME: "Do not make
yourself dependent on too many zones you do not control and/or serve and
please do pay attention to TTL".

The remaining question is then whether to ask for SRV first or not. (And
here is the real discussion on acceptable latency.  The rest is just
setting the scene.) 

I think Patrik had some pretty correct hand waving sentences :) on that,
but the main point is that I believe that we can be leaning on the
aggressive side when specifying, because the user-agent people will be
aggressive anyway. And the caching will mostly contain the eagerness. (As
a sysadmin, I'm usually more concerned over stupid caching in browsers
than lack of caching because of too short TTL. And I care for the
resolvers...) By aggressive I think we should emulate happy eyeballs,
probably starting off with SRV for what is written in the browser, falling
back to AAAA, then A queries for sought name, then www.name, etc. Timers
might be around 70% of the average query time last 100 DNS queries took..

Finally, I agree with Patrik that there needs to be text. I offer to
send text if there is agreement on trying to include such. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I want another RE-WRITE on my CEASAR SALAD!!

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 4 Jan 2015 05:46:05 +0100

> On 3 jan 2015, at 22:53, Mark Andrews <[email-masked]> wrote:
> 
> I suspect in

Yes, except in the case for the bare domain name which there can not be any CNAME records for. For that you might have a "lame" A/AAAA record pair, which references an HTTP server that only gives back 301 to whatever URL you are to use -- where the CNAME exists.

I.e. I want to replace:

1 A lookup for domain
2 AAAA lookup for domain
3 Open HTTP connection to whatever target there was for A or AAAA lookup for domain
4 Get 301 back
5 A lookup for domain in the result of the 301
6 AAAA lookup for domain in the result of the 301
7 Get back CNAME from either 5 or 6
8 A lookup for domain in the result of the CNAME lookup
9 AAAA lookup for domain in the result of the CNAME lookup
10 Open HTTP connection to whatever target there was for A or AAAA lookup for domain

With:

1 URI lookup for domain
2 A lookup for domain in target for URI
3 AAAA lookup for domain in target for URI
4 Open HTTP connection to whatever target there was for A or AAAA lookup for domain

I.e. with the URI lookup you can resolve both the issue with lack of CNAME as zone apex and the initial 301 to whatever the apex of the web site is.

Or similar shortening of the number of roundtrips in DNS or HTTP with SRV (one can argue whether you get rid of the 301 with SRV, or the CNAME or both).

Today I see both 301 redirect and CNAME chain(s) when opening HTTP connections. Lots of them.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Sun, 04 Jan 2015 09:18:35 +0100

On 1/3/15 10:53 PM, Mark Andrews wrote:

> service.  

Again, a lot of enterprises in particular cut the zone at _tcp, and so
you can't do authoritative responses in your additional data.

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 4 Jan 2015 13:23:11 +0100

> you can't do authoritative responses in your additional data.

A lot of enterprises do not run even the same operating system or
management software for their internal non-IANA fakeroot systems as the
external one, so one needs to be careful about the source of that data ;-)

However, zone cut does of course not have to mean server change, so,
if we continue at the same usual practice of cutting at _protocol and
then running a separate zone on the same server, the Additional is still
sent with signatures. Test case:

dig _phantasy._sctp.besserwisser.org SRV +dnssec +norec @primary.se

...which returns:

_phantasy._sctp.besserwisser.org. 27 IN	SRV	0 0 4711 some.sub.besserwisser.org.

Name server primary.se holds besserwisser.org, _sctp.besserwisser.org,
sub.besserwisser.org and primary.se. All are signed and the delegations
are secure[0]. Asking for a  SRV record as above returns data from the two
children, the zone for the name server, and implicitly (if this had been
a full-service resolver) DNSKEY and RRSIG materials for besserwisser.org
as well, because they of course are needed to validate the chain from
the SEP.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!!

[0] thanks to Holger Zuleggers zkt. Marvellous piece of kit.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Jan 2015 11:07:07 +1100

Or one can delegate _http._tcp.example.net back to the
servers for example.net or delegate it to the hosting
provider and they can update the SRV records.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 07 Jan 2015 13:36:32 +0100

Hi Mark,

> provider and they can update the SRV records.

No doubt, and there are all sorts of other things one CAN do.  One
common configuration is for enterprise AD servers to be delegated _tcp
for any number of reasons.  Operationally this happens, and in large
sites it is not uncommon to see TCP-based queries because of it.  How
wide scale is the issue and is any performance hit acceptable?  That is
a fair question and difficult to answer.  It would be perfectly fine
with me if the WG had said, “ok, we'll just manage that delay; records
cache anyway.”  But that is not how discussions went.  Delay is
important.  But here again, I think we could use more analysis.  That
shouldn't hold up this draft, however.

Eliot

---

From: Dave Cridland <[email-masked]>
Date: Wed, 7 Jan 2015 13:07:54 +0000

> doesn't get signed (but correct me if I missed a change).  (Actually,

I'm confused by this comment. You're saying (or you appear to be saying)
that use of SRV would place greater emphasis on DNSSEC, but additional
records don't get signed, and therefore the address record wouldn't be
signed in this case.

I'm not clear on where the requirement for DNSSEC comes into this, but
given that without SRV (and without DNSSEC that is no longer required),
there would be no signature on the address record anyway, I'm not sure it
matters.

I would in any case strongly support addition of SRV into HTTP/2 URI
resolution, and furthermore, I would strongly support additional work on
DNS (and DNSSEC) to address any performance or security issues at that
level.

As a final comment, I would note that if "IANA policy" is causing us
problems, we should just change it - these are technically speaking not
IANA's policies but ours.

Dave.

---

From: Doug Barton <[email-masked]>
Date: Wed, 07 Jan 2015 09:27:30 -0800

On 1/7/15 4:36 AM, Eliot Lear wrote:
| Hi Mark,
|
| On 1/6/15 1:07 AM, Mark Andrews wrote:
|> Or one can delegate _http._tcp.example.net back to the
|> servers for example.net or delegate it to the hosting
|> provider and they can update the SRV records.
|>
|
| No doubt, and there are all sorts of other things one CAN do.  One
| common configuration is for enterprise AD servers to be delegated _tcp
| for any number of reasons.

That is generally true on the *internal* zones, if the enterprise has
made the mistake of using their publicly facing domain for their parent
AD zone instead of following the MS best practice of using a subzone
like ad.example.com, or a private zone like example.corp.

It is almost universally true that this same damage does not extend to
the *external* DNS, which is what is under discussion here. *

| Operationally this happens, and in large
| sites it is not uncommon to see TCP-based queries because of it.

I'm not sure how to parse this sentence.

| How wide scale is the issue

... as above, this issue is virtually non-existent in the external DNS
space. I wish I could say that I've never seen a customer whose
configuration prior to our involvement leaked their AD-related zones
publicly, but the actual number is way less than 10%. *

It's also worth pointing out that we're talking _http._tcp and
_https._tcp, which could theoretically be delegated as separate zones,
so even in the most brain-damaged cases, this issue can be resolved
without the direct involvement of the AD DNS.

| and is any performance hit acceptable?  That is
| a fair question and difficult to answer.  It would be perfectly fine
| with me if the WG had said, “ok, we'll just manage that delay; records
| cache anyway.”  But that is not how discussions went.  Delay is
| important.  But here again, I think we could use more analysis.  That
| shouldn't hold up this draft, however.

Unfortunately the HTTP literati decided over a decade ago that they
would not consider SRV under any circumstances, and that position hasn't
changed in spite of it being proven repeatedly that there is no basis in
fact to their assertion that it would result in a performance penalty
(and in spite of being asked several times in the intervening period to
reconsider, including by me personally at the opening of this latest WG).

Doug

* I hate appeals to self-authority as much as anyone, but this is what I
do for a living, and I am our company's expert on taking over DNS from
MS DNS, including AD DNS.

---

From: Doug Barton <[email-masked]>
Date: Wed, 07 Jan 2015 09:33:50 -0800

On 1/7/15 5:07 AM, Dave Cridland wrote:
> On 3 January 2015 at 16:53, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> there would be no signature on the address record anyway, I'm not sure
> it matters.

Just to correct what seems to be a bit of a misunderstanding here ...

If the target of the SRV is a host name that is also served by the same 
authoritative instance, and that record is signed, the signatures can be 
returned in the ADDITIONAL section. Whether they are or not has to do 
with packet size issues, and a variety of other variables.

If the host name is not served by that same server, whether the address 
record(s) are returned for that host name or not depends on how the 
authoritative instance is configured, as is the possibility of returning 
RRSIGs for those records. It is less likely in this case though.

> DNS (and DNSSEC) to address any performance or security issues at that

As has been demonstrated already, it's overwhelmingly likely that using 
SRV would perform better than the 3-7 layers of CNAME indirection that 
are common for large enterprises (and their CDN networks) today. At 
minimum it will perform no worse.

> IANA's policies but ours.

Fortunately that argument has always been a red herring, so there is 
nothing for the IANA to do here. :)

Doug