Hi Mark, On 4 Feb 2019, at 19:30, Mark Nottingham <[email protected]> wrote:
> 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? 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
