dougb> It's not just a philosophical objection, it's an operational dougb> one. When DNSSEC fails for a domain there are 2 main dougb> reasons. Operator error, and an actual MITM or similar attack. If dougb> the operators of validating resolvers simply turn off validation dougb> for domains that should be validating but are not,* it kicks the dougb> door open for the exact problem that DNSSEC was designed to dougb> solve.
Have you actually read through the new draft? It specifically prohibits automatic installation of NTAs and says that you should have folks familiar with operating DNS servers making any decisions. That isn't painless. It means that this skips past all 1st tier and gets to senior engineers. Don't know about you but I hate getting on-call problems caused by someone else that I have no direct way to fix but that my customers beat me for. And that's way more expensive than standard help desk... But it is a good way to make sure that this isn't a constant and knee jerk reaction but an operationally sane one. 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. Sure. It will only be temporary/fast. Like rolling out IPv6. Or getting all the broken CPEs using old dnsmasq and being open resolvers. Or getting folks to roll out BCP38. How long have we been trying to get folks to use DNSSEC? How far are we? And why do we keep insisting that only by painful and expensive suffering will we do it "correctly"? _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
