Ray Bellis <ray@isc.org> wrote: >> could i convince you to put up a web page with the recipes for the half >> dozen prominent resolvers with this hack and one or two others? > The BIND instructions are in RFC 8806, as are those for some other resolvers > that support this. > There are caveats: > - allowing AXFR of the root is something that some root operators do, > but it is not a formal service offering. Any (or all) of them could > withdraw it at any point. 1. I think we should fix this in "contracts" going forward. > - you'll want to have really good monitoring in place to make sure your > transfers are succeeding > - without NOTIFY you might miss urgent root zone updates, e.g. in the > case of an urgent TLD key roll 2. I'm skeptical about this. If I were only caching, would my risk not be similiar? > - you might also want to use ZONEMD to check that the zone is correct. 3. My understanding of bind9's "type mirror" is that it runs a DNSSEC check on it. I assume other platforms do the same. The ZONEMD(RFC8976) suggests that some NS RR can not be protected by DNSSEC. (I understand how this can be the case, but not for the NS in .) I see ZONEMD in the root zone, so maybe "type mirror" can check that automatically too? If current root infrastructure is designed to withstand DDoS attacks, then anyone (any ISP/Enterprise/...) who has RFC8806 won't need that to survive the attack. Maybe 8806 should be the better resiliency against attacks. ISPs that don't do 8806 won't survive, and will have an incentive to implement it. 4. An ISP might think it a good idea, once they have 8806, so add their own (internal) anycast responder for some A/AAAA for . zone. There are probably good reasons to discourage this, the major one being routing leaks. I imagine it will happen anyway. I'd like to see a how-to-do-it-right document instead. Maybe there is already one. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide