Subject: Re: [DNSOP] Accounting for Special Use Names in Application Protocols

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2019 11:30:50 +1100

I've modified that slightly to come up with this proposal:

"""
HTTP and HTTPS URIs rely on some name resolution mechanism(s) to interpret the authority field and ultimately convert it into an identifier (typically, IPv4 or IPv6 addresses). Often, this is DNS [ref].

When DNS is consulted for resolution of the authority field, this specification requires adherence to the requirements that all registered special use names [RFC6761] place upon applications; if they are not honoured, security, privacy and interoperability issues may be encountered.
"""

Make sense?

Thanks,

> On 9 Jan 2019, at 1:23 pm, Brian Dickson <[email-masked]> wrote:
> 
> 
> On Tue, Jan 8, 2019 at 4:21 AM Tony Finch <[email-masked]> wrote:
> Brian Dickson <[email-masked]> wrote:
> 
> > I think it might be good to scope the 6761 issue, with something like the
> > following:
> 
> [SNIP]
> 
> > > I.e. it is necessary to recognize all special use names, and necessary to
> > > not resolve such names via DNS.
> 
> That's going too far: special-use domain names must have specific
> instructions to application authors, which might say not to use the
> DNS or might say to use the DNS as usual.
> 
> Hi, Tony,
> You are, of course, right. I think what I meant was, for the specific case of .onion, (what I said),
> and for the general case, (what you said). I.e. wherever an RFC for specific special use name exists,
> as linked by the IANA registry, those particular instructions MUST be followed, especially if not following
> those rules might/would break things (like the case of .onion vs DNS).
> 
> Brian
> 
>  
> David Schinazi's comment on the GitHub issue about referring to the IANA
> registry is good, and perhaps more useful than referring to RFCs directly.
> 
> Tony.
> -- 
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> Trafalgar: Northeast 3 or 4, increasing 5 at times. Moderate. Fair. Good.

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Feb 2019 19:50:19 -0500

Hi Mark,

> When DNS is consulted for resolution of the authority field, this specification requires adherence to the requirements that all registered special use names [RFC6761] place upon applications; if th…

I confess I have not being following this thread as closely as perhaps I should, but the text above strikes me as odd.

RFC 6761 describes a registry of special *domain names* -- it's talking about the namespace, not the resolution protocol. In some cases the registry directs applications to use different resolution protocols (protocols other than the DNS) to look things up. The LOCAL and ONION domains are examples. It's the contents of the registry that are important, not that subset of initial registry contents that are specified in RFC 6761, as I think Tony pointed out.

The text you suggested could suggest that an application should consult the DNS for a name that ends in LOCAL and simultaneously satisfy the requirements implied by LOCAL's presence in the Special-Use Domain Name registry, which include not using the DNS. This doesn't seem particularly clear.

Since I've been staring out of the window for the rest of the thread thinking vaguely about lunch it seems a bit presumptuous to suggest alternative text, but perhaps something like this would be better:

---
Resolution of the authority field MUST adhere to any special requirements documented in the Special-Use Domain Names registry [ref] which might specify that some protocol other than DNS be used for resolution for names within a particular domain. If those special requirements are not honoured diligently, security, privacy and interoperability problems might well result.

For example, consider the authority field EXAMPLE.LOCAL, intended to resolve to an address on a local, private network using the Multicast DNS resolution protocol [RFC6762]. If the DNS was used as a resolution protocol, the existence of the local-scope name EXAMPLE.LOCAL and this particular instance of its use might be revealed to third-party DNS servers; there is also a risk that attacks on the DNS system outside the local network could cause the EXAMPLE.LOCAL name to be resolved to an external, third-party address with attendant risks to privacy and security for higher-layer protocols and the application itself. Such risks are avoided by ensuring that resolution of names in the LOCAL domain are only attempted by the application using the Multicast DNS protocol.
---

Joe

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Feb 2019 12:46:26 +1100

I like it; will append to the issue. Thanks.

> On 5 Feb 2019, at 11:50 am, Joe Abley <[email-masked]> wrote:
> 
> Hi Mark,
>