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

[Ted Lemon <[e-mail]>]

So having just said that we should avoid re-visiting the long layer 9 
discussion that occurred on dnsop, I do actually have a technical 
concern about the document that was just pointed out to me by a 
co-worker, and that was not actually discussed by the working group 
(although David Conrad did make a related suggestion).   There is text 
in the document that says this:

    4.  Caching DNS Servers: Caching servers SHOULD NOT attempt to look
        up records for .onion names.  They MUST generate NXDOMAIN for all
        such queries.

    5.  Authoritative DNS Servers: Authoritative servers MUST respond to
        queries for .onion with NXDOMAIN.

    6.  DNS Server Operators: Operators MUST NOT configure an
        authoritative DNS server to answer queries for .onion.  If they
        do so, client software is likely to ignore any results (see
        above).

    7.  DNS Registries/Registrars: Registrars MUST NOT register .onion
        names; all such requests MUST be denied.

The problem with this text is that it doesn't quite do what I think we 
want. What we want is for a device that (incorrectly!) does a query on a 
.onion name to get an NXDOMAIN.   If it does a DNSSEC query, we want it 
to be able to validate the NXDOMAIN.   I think that this is what we 
intended, but this text doesn't actually accomplish that.   What this 
text _does_ accomplish, which is also really important, is that it 
prevents queries from being sent, complete, all the way up to the root.

I think that we want to ask for the following:

1. The root is set up to return NXDOMAIN with authenticated denial of 
existence.
2. Authoritative DNS servers should refuse to respond to these queries 
if they aren't authoritative.  I don't think this needs to be said; if 
the server is authoritative for the root, it will respond with NXDOMAIN 
because the domain doesn't exist; if it's not authoritative for root, on 
what basis could it answer?
3. DNS caching servers should pre-load their cache with the NSEC records 
required to securely deny existence of .onion.
4. Operators should make sure their caching servers are set up this way.

I think all the SHOULDs and MUSTs are inappropriate.   We don't have the 
authority to tell the root operator what to put in the root zone, so 
this should say what we want, not say what the operator should do.   And 
these are things that DNS servers ought to do, but I don't think there 
is a protocol issue here, and I don't think we can do more than 
encourage people to do the right thing here.   In practice, what most 
protects end users is correct implementation on the host; once the query 
leaves the host the user's privacy has been violated; all that is left 
is to try to mitigate the thoroughness with which it has been violated.