On Oct 25, 2014, at 8:30 PM, Paul Ebersman <list-dn...@dragon.net> wrote:
> > 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"? Just to amply Paul’s point We want humans in the loop, I would love to see a twitter feed when ever Comcast does a Negative Trust Anchor. I know of a ISP that is/will deploy DNSSEC is what they call passive mode i.e. they will never give SERVFAIL but will not set AD bit when validation fails. IMHO that is a great way to avoid service calls but ….. Right now most of the errors are caused by mistakes by the DNS operator or bugs in new tools. In not so distant future we will start seeing lots of DNSSEC Operator Change errors, i.e. a new DNS operator takes over the operation of the domain (perfectly legitimate), the errors in this case may be long lived (someone forgot a step), or short lived (someone moved to fast or emergency procedure was invoked) Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
