On Tue, Jul 14, 2015 at 3:48 PM, Ted Lemon
<ted(_dot_)lemon(_at_)nominum(_dot_)com> 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.