On Thu, Jul 25, 2019 at 11:15:22AM -0400, Shumon Huque wrote: > 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.
I wouldn't say "insecure", exactly, but you're partly right - in the examples in RFC 7706, the zone transfer itself would be insecure, but once the zone was transfered, answers would still be validated. That's why the local mirror is set up in a separate auth server or view - it prevents answers from being returned as authoritative data, without validation. So clients do still have some protection; the problem is, there's no automatic recovery if the transfer is bad. Clients would start to SERVFAIL and the local root wouldn't know it had a problem. BIND 9 mirror zones address this in two ways: first, the zone is validated when transferred; the transfer is rejected if any bogus RRsets are found or if the NSEC chain is incompete. Second, if the zone is unusable, either because it failed to transfer in the first place or because it expired without a successful refresh, named automatically fails over to normal recursion to the root. This doesn't address the problem of glue and delegation NS records, but those aren't subject to DNSSEC validation during normal recursion anyway, so clients aren't substantially worse off. The transfer does represent an attack surface that wasn't there before, but it would be an extremely difficult one to exploit. That said, ZONEMD or XoT would improve things further, and I hope the root zone will adopt one or both. In the more general case for validating zone transfers, the idea is to have a sanity check that signatures are good before a secondary starts serving a zone. This is mostly about preventing self-foot-shooting incidents; ZONEMD isn't strictly necessary for it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop