Subject: Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 18:12:38 +1100

IESG / Patrik,

First of all - I think it's interesting to carry URIs in DNS. However, I have a few concerns about the document that I'd like to work through.

## The ENUM service registry

The document effectively gives a "type" for the URI by associating a value from the ENUM service registry. While that makes sense from the standpoint of ENUM, if this mechanism is truly generic to *all* URIs, it seems to me that it'd be much more sensible to use the typing system already in place for URIs -- link relations <http://tools.ietf.org/html/rfc5988>.

As it is, I think this proposal is going to surprise a lot of people very unpleasantly, when they find that URIs have effectively become subservient to ENUM, at least within the confines of DNS.

This could be addressed by either using link relations (although I realise that would require a fair amount of work), or by renaming the RR to "ENUM_URI" or similar, along with appropriate changes in the text (i.e., this is a record specific to ENUM, not generic to all URIs in DNS).

## The "home page" example

Section 6 uses a "home page" lookup as the only example application for this RR. To my knowledge, no Web browser does this or is considering doing so, and moreover, pretty much any Web stack person would be extremely surprised by both this. 

Do you have any implementations of this use case, or prospect for them? Have you talked to Web security folks about the implications of doing so?

## Alternative approaches

In Appendix A (D), the original allocation request says:

"""
There is no easy way to get from a domain name to a URI (or IRI).  
"""

That's not actually true any more; we now have Well-Known URIs <https://tools.ietf.org/html/rfc5785>, which allows an application to define how to get a URI from a bare hostname. While it's true that it's currently a little more expensive than DNS (requiring a TCP connection for the time being), we do have substantial deployment experience with it, and it seems to be operationally much simpler, as compared to adding a new DNS record. 

Are there use cases where .well-known isn't workable, as compared to this RR?

Cheers,

> On 28 Jan 2015, at 9:38 am, The IESG <[email-masked]> wrote:
> 
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'The Uniform Resource Identifier (URI) DNS Resource Record'
>  <draft-faltstrom-uri-10.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2015-02-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>   This document defines a new DNS resource record, called the Uniform
>   Resource Identifier (URI) RR, for publishing mappings from hostnames
>   to URIs.
> 
>   This document updates RFC 3404 and RFC 3958.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-faltstrom-uri/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-faltstrom-uri/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jan 2015 09:46:01 +0100

> On 28 jan 2015, at 08:12, Mark Nottingham <[email-masked]> wrote:
> 
> IESG / Patrik,
> 

Mark, thanks for these comments. Let me try to address them, but first some history.

The first version of this draft was posted as draft-ietf-enum-uri-00.txt on March 31 2007. In those days the ENUM wg did discuss a revision of the ENUM RFC and did look at using this URI RRType instead of the (to me personally much more complicated) NAPTR construction. The consensus in the wg was to NOT go down the path of URI RRType.

After this, the draft left the ENUM wg and turned into draft-faltstrom-uri series. A long discussion did take place in various DNS working groups, in parallell with the new process for registration of RRTypes (that did not need RFCs anymore). Slight confusion over what path to take, RFC or RRType registration lead to the RRType be registered, which the URI RR is, with number 256 on 2011-02-22.

This draft should because of this TODAY maybe be informational and not proposed, but that "stuck" from the early days of processing the draft.

The draft has been discussed several times on many mailing lists, and I do never think we will reach full consensus, to be honest, as I have never seen anything related to DNS reach anything better than rough consensus ;-) New issues get added every day... And old ones come back!

So, with that as a background, here are my comments.

> This could be addressed by either using link relations (although I realise that would require a fair amount of work), or by renaming the RR to "ENUM_URI" or similar, along with appropriate changes…

The RRType is registered and can not be changed.

That said, what can be referred to is a "better" registry for services. IETF do not have a registry for services for SRV. If IETF did, then I would have referenced that registry. I think it is "stupid" to create a new registry. This draft refer to the ENUM Service Registry. For SRV no real registry exists, but the DNS-SD people have this: <http://www.dns-sd.org/servicetypes.html>

> Do you have any implementations of this use case, or prospect for them? Have you talked to Web security folks about the implications of doing so?

I am working within the libcurl community to look at support for URI resource record types and others.

I have questions from various developers that want to use URI, but you are correct that they are not "web browsers". They are more "people that use HTTP for transport for data used for their service".

I agree that with that as a background a different example might make that more clear, although it might be harder to understand.

Is your suggestion to add more examples? I think that is a fair request that makes lot of sense.

> Are there use cases where .well-known isn't workable, as compared to this RR?

Yes, when the namespace of the web server is not under control by the parties running services (i.e. they are given URIs).

And on top of that you have already pointed at the issue with lookups in DNS compared to the HTTP transport, where also lots of redirects are common, specifically in CDNs, virtual hosting (www.example.com / example.com is a trivial example of course) etc.

But you also point at a for the IETF sensible issue. When the well known URI was discussed, I did present the URI RRType (and SRV, and NAPTR and...) but as too often happens "the web community" responded with "we can only look up A records". So the use of more efficient mixes of DNS and HTTP to reach the for the user best experience was never really discussed. Not there, not then, not before and not after. :-(

The problem NOW on the table though is to get an RFC that describes the already existing RRType URI.

   Patrik

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Jan 2015 16:33:08 +1100

> On 28 Jan 2015, at 7:46 pm, Patrik Fältström <[email-masked]> wrote:
> 
> 

IC, that's helpful, thanks.

> That said, what can be referred to is a "better" registry for services. IETF do not have a registry for services for SRV. If IETF did, then I would have referenced that registry. I think it is "stu…

I think most of my concern centres around things appearing in the registry without coordination with the community surrounding that service -- such as the Web / HTTP case. 

I.e., if the URI RR points to a registry, and that registry contains an entry for a service "foo", I expect that applications that implement "foo" should use the URI RR in their operation. 

When this isn't the case, it's not good for interoperability, potential security issues are introduced, and the community of the service often isn't involved in the registration.

So, I'm going to ever-so-gently push back on your characterisation of a new registry here as "stupid."

> Is your suggestion to add more examples? I think that is a fair request that makes lot of sense.

It'd help, yes. It'd also be good to have the conversation with the Web folks, to see where that goes (perhaps they'll want to support it, but if they don't, it might be good to take that 
example out).

> Yes, when the namespace of the web server is not under control by the parties running services (i.e. they are given URIs).

Hm, that's largely an administrative issue, but OK.

> And on top of that you have already pointed at the issue with lookups in DNS compared to the HTTP transport, where also lots of redirects are common, specifically in CDNs, virtual hosting (www.exam…

For now -- note that as we write, the IAB workshop on TCP evolution is considering how to move protocols like HTTP to UDP :)

> But you also point at a for the IETF sensible issue. When the well known URI was discussed, I did present the URI RRType (and SRV, and NAPTR and...) but as too often happens "the web community" res…

We've been trying to get discussion going between the HTTP and DNS communities, with limited success. Maybe it's time to try again (e.g., in Dallas as a Bar BoF)?

> The problem NOW on the table though is to get an RFC that describes the already existing RRType URI.

Understood. 

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Thu, 29 Jan 2015 07:59:14 +0100

Hi Patrik,

On this one point:

On 1/28/15 9:46 AM, Patrik Fältström wrote:

> That said, what can be referred to is a "better" registry for services. IETF do not have a registry for services for SRV. If IETF did, then I would have referenced that registry. I think it is "stupid" to create a new registry.

Stupid or not, it exists.  Go to [1] and select "Service name only". 
RFC 6335 updated RFC 2782 on this point[2].

Eliot

[1] http://www.iana.org/form/ports-services
[2] http://tools.ietf.org/html/rfc6335

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 Jan 2015 07:13:06 +0100

> I think most of my concern centres around things appearing in the registry without coordination with the community surrounding that service -- such as the Web / HTTP case.

I completely understand.

> When this isn't the case, it's not good for interoperability, potential security issues are introduced, and the community of the service often isn't involved in the registration.

The draft and registries for prefixes in DNS (specifically SRV, as I explain above) has been discussed in the apps area of IETF for years, and no resolution of that question have been reached yet. :-(

> So, I'm going to ever-so-gently push back on your characterisation of a new registry here as "stupid."

Oh, sorry, it was not my intention to express things that strongly.

What I think I think (!) is that as we do not have any clear registry for service prefixes in DNS, and SRV has been surviving quite well without, and to some degree also many parts of "the web" community, is it important to have _any_ specific registry? Can this just evolve?

> It'd help, yes. It'd also be good to have the conversation with the Web folks, to see where that goes (perhaps they'll want to support it, but if they don't, it might be good to take that

Ok.

> For now -- note that as we write, the IAB workshop on TCP evolution is considering how to move protocols like HTTP to UDP :)

...and some people want to move DNS to TCP and give up UDP :-)

> We've been trying to get discussion going between the HTTP and DNS communities, with limited success. Maybe it's time to try again (e.g., in Dallas as a Bar BoF)?

Yeah, see the discussions around what DNS features are expected in HTTP/2 and I am crying a bit.

Now when we are trying to get a GOOD protocol definition, why can not that include good things from BOTH http and DNS worlds(*)?

  paf

(*) I am thinking of including SRV/URI/whatever higher abstraction layer in DNS in the protocol spec, and "limit" "happy eyeballs" to repeated HTTP transactions over A/AAAA record types. I do not think that discussion have been held, as pushback from web to DNS community feels like "oh no, that is too hard", which is as I know you and I agree about, the wrong answer.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 29 Jan 2015 08:05:24 +0100

> On 29 jan 2015, at 07:59, Eliot Lear <[email-masked]> wrote:
> 
> Hi Patrik,
> 
> On this one point:
> 
> 

Ok, I have been sleeping by the wheel!

Mea culpa.

Let me come back on this.

   Patrik