In your letter dated Wed, 3 Jun 2026 08:33:31 +0100 you wrote: > I agree that LocalRoot is not complete DNS privacy. Queries will > still go to TLDs and authoritative servers. My point is narrower: > LocalRoot removes one unnecessary disclosure point. Root traffic > is uniquely aggregated and studied (e.g., via DITL), so preventing > queries from leaving the local environment at the root level is > still a meaningful privacy improvement. > > This is not about whether root operators are more or less trustworthy > than TLD operators. It is about minimising disclosure. If a query > does not need to go to the root, not sending it there is the better > privacy outcome. So yes, LocalRoot is only a partial solution, but > reducing upstream exposure is still significant.
I'm looking at this from the perspective of a recursive resolver and then try to answer two questions: 1) Would the complexity of implementing support for local root be worth it if there is no support at all for local zones. 2) Would it be worth shipping the resolver with local root enabled by default. For both issues the question is whether the increased complexity of a local root compared to just root hints is worth it. We can assume that a sensible resolver already does DNSSEC validation. A resolver should also do Qname-minimization for the obvious reason that you want that at the TLD level as well. Aggressive NSEC also makes sense from a DNSSEC implementation point of view. Once those mechanisms are in place and the effect of queries sent to TLDs are considered, does local root offer enough benefits to warrant the complexity? In this draft it lists Privacy with LocalRoot as 'Complete'. But from a resolver point of view that is not true because queries get sent to TLDs, SLDs, etc. Overall privacy protection is very far from complete. Does a local root offer some benefit? We safely say that the answer is yes. The big question is whether the benefits are big enough to warrant the extra complexity and/or operational risks. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
