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.
Funny you should mention that. I recently read that RFC, and came off with a feeling that "the authors do not really want you to do this". Why? 1) It is an Informational RFC, but it uses the upper-case keywords from RFC 2119 even though that notation is supposedly only appropriate for standards-track documents. 2) What's worse, the justification for the stated requirements are not spelled out in the RFC, and some of the requirements are not exactly immediately obvious at least to me, even though I would dare to call myself "experienced". So it comes across as an "edict from above". As a source for *information* I would like to give it an "F" for "fail" for this reason alone. 3) The various MUST requirements give rise to significant complication in the configurations. An example for #2 and #3 is Specifically, the root service on the local system MUST be configured to only answer queries from resolvers on the same host and MUST NOT answer queries from any other resolver. Why? The document is silent on that matter. I sense a strong unwillingness to simplify as much as possible. What would go wrong on this front if you simply dropped a root mirror zone in each view you are currently serving? This paragraph in the RFC gives rise to the monstrostity of a configuration presented for BIND 9.12 which is also incomplete because of: * No mention of where 127.12.12.12 needs to be configured. * No mention of whether listen-on needs to be modified. * No mention of whether the "MUST validate the zone DNSSEC-wise" requirement (OK, not an actual quote) is fulfilled by this configuration (it probably isn't?) Granted, the "mirror zone" feature of BIND 9.14+ makes that configuration sample much simpler, and it supposedly DNSSEC-validates the zone before serving it, but, again, the assumed (by me) conflict with the customary "hints" root zone is not mentioned, and here the use of a specially cordoned off view is also not mentioned. So it's no longer needed in this case? Why not? (...and both BIND 9.12 and 9.14 are by now both "ancient history", for those of us who follow along with the maintenance versions of BIND.)
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.
What would happen at that point with BIND 9.14+? The mirror zone would expire, and the local recursor would then revert back to the built-in root hints on startup instead? What's the actual damage to the service the local recursor provides in that case? Granted, in the 7 days from the last successful AXFR until the Expire timer triggers, the recursor would serve up the information from the root zone at the start of that period. How bad would that be? How often does a TLD fully replace all its NS records? Or urgently need to update its DS record? I would posit that changing the delegation of a TLD is typically done more slowly and over a period longer than 7 days. (Emergency KSK rollovers are another matter. Anyone have any history on how frequent such events have been? This can be used to calculate the risk of serving an inaccurate DS record for a TLD for a number of days within that expiry period.) As has been mentioned, the continuity of AXFR service seems to be something which is fixable in a contract if there is any will...
- you'll want to have really good monitoring in place to make sure your transfers are succeeding
What? One-time success is no guarantee for future success? :) And ... what to do if your zone transfers of the root zone are failing? Especially if you haven't touched the "local" or "adjacent" network config?
- without NOTIFY you might miss urgent root zone updates, e.g. in the case of an urgent TLD key roll
How is this significantly different from the propagation of that information without serving the root zone locally? It seems that all the DS records in the root zone have 86000 as TTL, so takes a full day to time out before the root zone is re-consulted for an updated copy. And with the current timers in the SOA (30m refresh 15m retry), and a good success rate for SOA queries and root zone transfers, I fail to see how this would in reality present a practical problem.
- you might also want to use ZONEMD to check that the zone is correct.
Ehm, isn't that for ISC to implement for zone-type "mirror" and for us to use that way (and similar for other DNS server software maintainers), instead of forcing us as administrators to jump through even more complication hoops? I thought the whole point of publishing RFC 8806 was to spur adoption of this configuration method. Was I wrong on this point? It certainly comes off that way. Regards, - Håvard