(I'll ignore the question of the cost/benefits of running a local root copy for now and just focus on the technical topic below).
On Thu, Jul 25, 2019 at 1:45 AM Evan Hunt <e...@isc.org> wrote: > > Third, and more pertinently, this work may have spin-off benefits. I've > thought for a long time that a mechanism to use DNSSEC to validate zone > transfers would be a useful addition to BIND. While that feature, per se, > still doesn't exist, the mirror zone developemnt invovled writing a lot the > code that's needed for it, and I expect it to exist fairly soon. So I don't > think 7706 will have been a waste of time even if it turns out not to have > been particularly effective at its original use case. > Evan, Can you elaborate on how you plan to do this? One of the things that has always annoyed me about RFC7706 (and its successor I-D) is that it offers no suggestions on how to validate that you got a correct copy of the entire root zone. The example configurations given in the appendix are all insecure - they rely on unauthenticated zone transfer. The one example that is likely secure is the one given for the Knot resolver, but that's because it is decidedly not using 7706, and instead uses cache prefill from a root zone copy located at a well known HTTPS authenticated destination. If an operator using 7706 is targeted by a glue spoofing attack, then it will likely require manual intervention of the resolver operator to recover. Whereas without 7706, I assume robust resolvers may be able to recover by themselves by retrying other root servers, if they can determine that they were directed to bogus servers in the case of signed child zones. If you plan to use DNSSEC to validate the zone, I assume you might be thinking of either (1) signed ZONEMD, although that does not exist yet for the root zone, or (2) proposing to re-design child NS and glue records so that they can be signed. But perhaps there are other ways that I haven't thought of. Recall that there have been extensive discussions on this topic during the initial debate on ZONEMD, which I won't rehash here. But I want to note that there is now a draft on XFR over TLS, which may offer a new channel protection possibility to address this issue (assuming it makes progress, and there is implementation interest on the part of root zone operators). Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
