On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon > writes: > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews <ma...@isc.org> wrote: > > > At the moment we have Ted saying that if you want privacy you MUST > > > also turn on DNSSEC validation and implement QNAME minimisation and > > > implement agressive negative caching (still a I-D). > > > > No, I am _not_ saying that. I am saying that an unsigned delegation > > doesn't help with privacy unless you also specially configure your local > > resolver, and if you are going to specially configure your local > > resolver, then there are several options for how to do that. The only > > reason you need DNSSEC is that if you specially configure your local > > resolver to lie, then DNSSEC validation will break that. If you aren't > > doing DNSSEC validation, you can say any old thing in your local resolver > > and the stub will believe it. > > Suppose a signed delegation for alt, to some widely operated, centrally managed servers (say, the arpa servers). Now suppose an unsigned delegation for some other name under alt, such as "foo.alt", to an empty zone on the same set of servers.
The only difference here is where the unsigned delegation is, and what the scope of that delegation is. In this scenario, any local "foo.alt" can lie about the contents of "foo.alt", because it is outside of the secure delegation chain from the root. The only difference is that the delegation is not directly from the root. Any other name under "alt" would have its existence securely denied, unless and until a request for an insecure delegation was made and approved. Is there a problem with this scenario? > And a signed answer doesn't help unless the recursive server is > validating (so it can trust the NXDOMAIN) and has QNAME minimimistion > (to prevent *.alt leaking in the first place) and has agressive > negative caching (so the answer from the minimised QNAME query get > turned into a answer for *.alt). > > Now we can put QNAME minimisation into a server. > Now we can put the code to support agressive negative caching into a > server. > We can't force validation to be enabled. > > We need all three things for the privacy leakage to stop. Any two > alone doesn't stop it. > There's something I don't understand. In the case where the local namespace (in your email, that would be "alt", in my example above, that would be "foo.alt") is not configured, why does leaking matter? Obviously the real local use case is "won't work - broken config", and leaking is mostly moot. In the case where the local namespace is instantiated, the queries won't leak to the root, so privacy is assured. Are you saying that leakage when the local namespace is non-existent, is a/the issue? I don't agree, if that is what you are asserting. Queries for "rumplestiltskin.foo.alt" can't expect privacy, unless they are using a resolver specifically configured for "foo.alt". Note that defaulting to providing "empty.as112.arpa", and having the DNAME to "alt.empty.as112.arpa", would further actually accomplish privacy, without affecting the local instantiation of "foo.alt" via "foo.alt.empty.as112.arpa". Brian > > The alternative is to do a insecure delegation and build in a default > empty zone for alt. You then have to take steps to break the privacy > leak by disabling the empty zone. Additionally it works with all > existing servers if they just add a empty .alt zone. It doesn't > require validation to be enabled. > > It's the difference between defaulting private or not. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
