On Thu, Feb 9, 2017 at 3:47 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <CAH1iCiqi_xJjwXvsR-x76fcz20NiugnjYqameK1ZHWd+ > 54s...@mail.gmail.com> > , Brian Dickson writes: > > > Are you saying that leakage when the local namespace is non-existent, is > > a/the issue? > > Because when TPB go on a witch hunt for all users of xxxx.alt we > don't want the root servers operators to be able to return the > addresses. It's not a matter of if, just when. We have seen that > happen too many times. >
I'm not sure who "TPB" is, but... If you really care about privacy, IMHO, the place to instantiate the private namespace, is under one of the heavily used AS112 zones. E.g. 10.in-addr.arpa, or 168.192.in-addr.arpa. It's unsigned, by default (for BIND) local already, and even if a leak occurs, it will be hiding among the sheer volume of crap. Plus, having the AS112 decentralization applied, means any incidental leakage is going to be nearly impossible to find. Using a new TLD for local use-cases that do want to be in a privately forked piece or the global namespace, is perhaps unwise. One thing to consider: the client will not know whether the resolver has leaked or not. Maybe this should be a DPRIVE topic, rather than general dnsop? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
