On Tue, Jul 14, 2015 at 3:48 PM, Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote:
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.
I think this is valid way of making sure that an application doesn't have to rely on local knowledge to know whether something is or is not in the Global DNS root, but I note that another way of looking at it is as a gTLD applicant asking for a slot, specifying only NSEC records for the NXDOMAIN related to the proposed slot. Could, for example, the Catholic church ask for .pope and follow exactly the same procedure, so that strings with .pope could never be used in the root? (Yes, I am aware there are other possible ways of making that point, but this one is pretty effective).
But I think the possibility of other reasons for this highlights the point Ted Lemon was making: to make this work correctly is actually more in the bailiwick of the root operators than ours. I think that means we should tread more carefully than the trend lines appear to be.
regards,
Ted Hardie
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.