dougb> The other problem is that this feature is only really useful in dougb> the DNSSEC ramp-up period. Sure, mistakes are more common now, dougb> software is immature, etc. etc. But if DNSSEC is successful, the dougb> software will get better (it already is a lot better than even a dougb> few years ago), and mistakes will be less common (both on an dougb> absolute, and on a percentage basis). But once you introduce a dougb> feature like this, you cannot remove it.
warren> ... but you don't have to remove it. If " DNSSEC is successful, warren> the software will get better (it already is a lot better than warren> even a few years ago), and mistakes will be less common" then warren> there will be no need to install NTAs. +1 Key management automation is definitely making progress. I'd love to see the operational stability of DNSSEC approach "standard" DNS. Expired keys and blown ZSK key rollovers are certainly common still but as folks take advantage of better DNSSEC signing software versions, this will lessen. As we get vendors and registrars to implement things like RFC 7344 (delegation trust maintenance) and RFC 5011 (automated trust anchors), KSK rollover failures will also get less common. But we're not there yet. Until then, having a way to remediate the occasional DNSSEC failure while keeping DNSSEC validation on helps, not hinders, DNSSEC adoption. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
