Subject: Re: [DNSOP] Extended CNAME (ENAME)

From: David C Lawrence <[email-masked]>
Date: Mon, 19 May 2014 18:12:15 -0400

Ted Lemon wrote:
> It might be worth actively pushing the CDN folks to go the SRV direction.  

Not so much pushing required, at least of Akamai.  You have a
ready-made ally in me, if only clients actually made good use of it.
The clients are the real obstacle.

Looking at a random high-traffic DNS server on our network, I see
practically no use at all of _http._tcp SRV requests.  Over 6 days of
logs on this machine, they are just over 0.00007% of all requests.
(Yes, that decimal point is right.)  Exactly 90% of them are for the
same hostname, with a name that implies to me that one application,
not a web browser, is responsible for all of them.

On another server that provides a separate set of zones, HTTP SRV
requests are a mere 0.000001% of all requests, for only 3 distinct
names among tens of thousands web server names.

I appreciate what Mark is proposing, but personally I'd sooner see us
using SRV than yet another new alias type if only it would get
traction.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 May 2014 21:20:07 -0400

> The clients are the real obstacle.

Yup.   It would be great if we could get the HTTP 1.1 clients to do it, but getting HTTP 2.0 clients to do it seems at least as do-able as any of the alternatives that have been proposed.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 19 May 2014 20:54:41 -0700

Ted Lemon wrote:
>> ready-made [SRV] ally in me, if only clients actually made good use of it.
> Yup.   It would be great if we could get the HTTP 1.1 clients to do it [SRV], but getting HTTP 2.0 clients to do it [SRV] seems at least as do-able as any of the alternatives that have been proposed.

i was there when SRV was conceived. we intended it to be used
opportunistically, like MX before it, falling back to AAAA or even A
queries if there was no SRV. it can be added to any protocol at any
time, including HTTP/0.9 clients to the extent there are still any of
those around. SRV's rules are defined for a service not by the client.
if we decide that web servers can be reached by SRV records, then any
web client can start looking for the SRV that describes that service,
falling back to whatever tin-cups-and-string it did before if it can't
find the SRV it wants.

in that sense mark andrews' HTTP SRV I-D from all those years ago should
not have been controversial. "if you want to do this, here's how
everybody else agreed to do it."

vixie

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 May 2014 06:48:00 +0200

On 20 maj 2014, at 05:54, Paul Vixie <[email-masked]> wrote:

> if we decide that web servers can be reached by SRV records, then any web client can start looking for the SRV that describes that service, falling back to whatever tin-cups-and-string it did before if it can't find the SRV it wants.
> 
> in that sense mark andrews' HTTP SRV I-D from all those years ago should not have been controversial. "if you want to do this, here's how everybody else agreed to do it."

Speaking as an Applications Area Director of the time when SRV records where proposed I completely agree.

Algorithm should be defined by the service, and when done, it should be implemented and used.

Can we not with HTTP/2 please push SRV forward?

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 20 May 2014 15:29:11 +0900

> falling back to whatever tin-cups-and-string it did before if it can't

A problem of SRV is that, purely within DNS, SRV is well defined
and fine, but within wider context, it is not.

For example, for browsers, as both SRV RRs and URLs can specify
port numbers, what if they specify different port numbers?

For another example for browsers, correspondences between
"service" of SRV and "proto" in URLs are not clear. Does
"proto" of "mailto" should use "service" name of "smtp"?
Maybe, it does, but correspondences are not straight forward.

Thus, it is not easy for browser developers, who do not have
much expertise in IETF process on DNS, to support SRV.

I have a proposal in:

	http://tools.ietf.org/html/draft-ohta-urlsrv-00

on the problems.

						Masataka Ohta

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 20 May 2014 10:28:07 +0200

> not a web browser, is responsible for all of them.

That's technically 0.00007% too many, as the SRV RFC specifically
mentions not to use it for protocols if there's isn't a document stating
how to exactly use it with that protocol (mainly, as Ohta-san already
mentioned, what to do with apparent data conflicts and a security
considerations section), so right now browsers are not supposed to use
SRV for http requests.

That certainly doesn't mean we shouldn't go forwards and try to
introduce such a document together with the http people. I never did
find out why Mark's proposal didn't take.

Regardless of whether we should go forwards with ENAME, btw. I think
having SRV for http would be nice anyway.

Jelte

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 May 2014 19:10:13 +1000

I've updated draft-andrews-http-srv-02.

http://tools.ietf.org/html/draft-andrews-http-srv-02

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

---

From: Ben Laurie <[email-masked]>
Date: Tue, 20 May 2014 10:36:44 +0100

On 20 May 2014 04:54, Paul Vixie <[email-masked]> wrote:
> Yup.   It would be great if we could get the HTTP 1.1 clients to do it
> [SRV], but getting HTTP 2.0 clients to do it [SRV] seems at least as do-able
> as any of the alternatives that have been proposed.
>
>
> opportunistically, like MX before it, falling back to AAAA or even A queries
> if there was no SRV. it can be added to any protocol at any time, including
> HTTP/0.9 clients to the extent there are still any of those around. SRV's
> rules are defined for a service not by the client. if we decide that web
> servers can be reached by SRV records, then any web client can start looking
> for the SRV that describes that service, falling back to whatever
> tin-cups-and-string it did before if it can't find the SRV it wants.

Surely the problem is that the server must continue to support clients
that don't look for SRV. So, what's the incentive for a server to
start using it?

>
> in that sense mark andrews' HTTP SRV I-D from all those years ago should not
> have been controversial. "if you want to do this, here's how everybody else
> agreed to do it."
>
> vixie
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 20 May 2014 20:39:10 +1000

> that don't look for SRV. So, what's the incentive for a server to

My that logic no one would be using MX record.  The problem is we
specifically prohibit the use for existing protocols without
documenting how to do it.  It's time we document how to do it.

---

From: Chris Thompson <[email-masked]>
Date: 20 May 2014 12:52:02 +0100

>http://tools.ietf.org/html/draft-andrews-http-srv-02

Wouldn't it be desirable to say something about https URIs as well as
http ones? It would seem that we will need an _https._tcp.[name] SRV
RRSet as well as the _http._srv.[name] one. (The idea of https overriding
the port number(s) in the _http._srv.[name] records with 443 seems
too horrible to contemplate.)

-- 
Chris Thompson               University of Cambridge Information Services,
Email: [email-masked]    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.

---

From: Petr Spacek <[email-masked]>
Date: Tue, 20 May 2014 14:17:08 +0200

> too horrible to contemplate.)

Hmm, would it be too weird to use

_http._srv.[name] CNAME _https._tcp.[name]

as 'HTTPS required' signalization?

(This is weird, I admit that. There will be troubles with DNS client libraries 
not exposing CNAMEs etc... I just can't resist.)

-- 
Petr Spacek  @  Red Hat

---

From: Tony Finch <[email-masked]>
Date: Tue, 20 May 2014 13:37:03 +0100

> that don't look for SRV. So, what's the incentive for a server to

Maybe DNS hosting providers could use the SRV records as a hint for
auto-updating the A and AAAA records at the zone apex. A bit ugly and
based on gratuitously specific assumptions about what protocols the domain
might provide on those addresses, but we do that already and pretend it
doesn't matter...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes: Northeast 5 to 7, perhaps gale 8 later. Moderate, becoming rough or
very rough. Rain or showers. Moderate or good.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 May 2014 15:48:09 +0200

On 20 maj 2014, at 14:17, Petr Spacek <[email-masked]> wrote:

> (This is weird, I admit that. There will be troubles with DNS client libraries not exposing CNAMEs etc... I just can't resist.)

_http._srv.[name] URI "https:[name]"

;-)

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 May 2014 10:00:27 -0400

> Can we not with HTTP/2 please push SRV forward?

Dare I assume that you meant "not" for emphasis, not to ask that we not do this?  :)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 May 2014 10:06:28 -0400

> 	http://tools.ietf.org/html/draft-ohta-urlsrv-00

Adding the port numbers is a surprising choice.   Why not just do something like this:

_port._proto._tcp.name.?

IOW, if a port is specified in the URL, it's used to find the SRV record.   If there is no SRV record that matches that port, give up.  That matches the current meaning of ports in URLs: http://www.netbsd.org:90/ is not in any sense equivalent to http://www.netbsd.org/ and therefore shouldn't result in the same query.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 May 2014 10:10:52 -0400

> that don't look for SRV. So, what's the incentive for a server to

That's why this is a clear win for HTTP 2.0 and not so clear for HTTP 1.1.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 May 2014 16:54:25 +0200

> Dare I assume that you meant "not" for emphasis, not to ask that we not do this?  :)

Arggh....of course.

Me and English...

I *WANT* SRV, URI or something similar.

Thanks for checking carefully!

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 May 2014 11:16:48 -0400

> Thanks for checking carefully!

np.   That is a valid idiom in English, of course, but it works better if you can use your voice to emphasize what you mean... :)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 May 2014 08:06:03 +1000

> 	http://tools.ietf.org/html/draft-ohta-urlsrv-00

We left this for being done on a case by case basis for good reasons
some of which you enumerate above.  I don't think anything has
changed in the intervening 15 years to make doing this generically
work.

What we missed out on doing was going back and doing the case by
case analysis of the existing protocols.  Doing this on a individual
basis may end up saying the same thing multiple times but that is
fine.  Browser/proxy vendors will see the commonality.

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 13:25:02 +0900

> that don't look for SRV. So, what's the incentive for a server to

Port based virtual (without port numbers in URLs) hosting.

With the following extended reverse look up:

	1.0.132.32.112.131.in-addr.arpa. PTR a.example.com
	2.0.132.32.112.131.in-addr.arpa. PTR b.example.com

it is better than name based ones.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 21 May 2014 13:53:27 +0900

> http://tools.ietf.org/html/draft-andrews-http-srv-02

First, as all the URIs related to SRV are URLs, the draft should
specifically say URLs, especially because non-URL URIs are
virtually dead replaced by DOIs.

Considering a possibility that a port based virtual host may
use multiple port numbers:

   If the URI does explicitly specify a port, other than the default
   port, to connect to then there is a potential conflict in the port
   specification between the URI and the SRV records, and the SRV record
   is ignored.  In this case the user agent MUST query for address
   records for the host name in the URI (instead of SRV records).

is not a good idea, which is why I suggested port number addition
in my draft.

						Masataka Ohta