Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Ted Lemon <ted.lemon@xxxxxxxxxxx>]

On Jul 21, 2015, at 7:52 AM, John C Klensin <john-ietf@xxxxxxx> wrote:

Ted, independent of SOCKS or other possibilities, I suggest one
of the things that can be said about apparent domain names that
are not expected to resolve in the DNS but are lexically
indistinguishable, overuse of TXT RRs, etc., is precisely "used
to solve that problem because it's the easiest hack to make it
work, not because it's the right thing to do.".   One difficulty
is that such hacks don't scale particularly well.  One or two of
them (I note that "localhost." is just about as old as the NDS)
is not a problem (although perhaps still a hack). Beginning to
add them in large numbers makes them harder to track, increases
the chance of leakage, and probably implies that we will
eventually need new hacks to categorize and organize the other
hacks.

I think there’s some truth to this, but I think it’s unfair to lay the whole problem at the feet of RFC 6761: it wasn’t our intention that TLDs be allocated will-he, nill-he, by ICANN, but we delegated change control to them and they did it.   If I were to architect a solution to this in the abstract, the way I would do it is as follows:

-2: Have a configuration mechanism for registering new special-use domains, so that (1) isn’t unnecessarily restrictive

-1: If we get a registration for a special-use domain, validate its non-existence as a domain name using DNSSEC, or else using the software signing practices of the OS.

1. If I get a query for name under a TLD that I recognize as special-use, do the special-use thing.

2. if I don’t recognize the TLD as special-use and I don’t have a cached record for it, do a query _just for the TLD_ to get the SOA for that TLD.

3. if I get NXDOMAIN, or if I can’t validate the TLD delegation using DNSSEC, stop.

4. Otherwise do a query on the whole name.

This accomplishes three things.   First, it deals with special-use names that are popular enough to be implemented broadly, and also with special-use names that the end user needs, but that are not needed generally.   Secondly, it securely prevents malware from installing interceptors for legitimate TLDs.   Third, it prevents leakage of queries that should be private: the network can see that I am interested in a .onion URL, but not _which_ URL.

So I think that this is a very tractable problem, despite the handicaps that we come in with.