On Jul 9, 2014, at 2:45 PM, Paul Vixie <[email protected]> wrote: > rather than teach the system how to monitor and report this sort of thing, > and back out the local root zone if it went stale, there was a brief and > overdue cost:benefit analysis after which this config was backed out of > freebsd itself.
My takeaway from this was that (a) if you're going to slave the root, it is you who should configure it, not have it magically appear one day without your knowledge and (b) if the zone transfer cannot succeed (for whatever reason), you need to fall back to the legacy roots (screaming as you do so). In the draft, (b) is already explicitly addressed (section 2) while (a) is sort of implied, but not explicitly stated (that should probably be fixed). > i did not keep notes as to who did or said what and on which dates. perhaps > doug barton could be persuaded to say more. I just waded through the discussion on the dns-operations and freebsd-current mailing lists during "the freebsd experiment" timeframe (see https://lists.dns-oarc.net/pipermail/dns-operations/2007-July/001803.html and http://lists.freebsd.org/pipermail/freebsd-current/2007-August/075813.html). My reading was that the vast majority of complaints were inline with (a) above (and the variation that it was rude for FreeBSD to insert a dependency for zone transfer from root servers without asking them first). I did not see any evidence that the rejection of "the FreeBSD experiment" was driven by a lack of skill "to both configure and operate and audit and debug a stealth root slave." In fact, a number of folks appeared to indicate it was an interesting idea worth exploring. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
