Doug, On Oct 24, 2014, at 3:06 PM, Doug Barton <[email protected]> wrote: >> I know that there will be some philosophical objections / discussions on >> this... > > It's not just a philosophical objection, it's an operational one. When DNSSEC > fails for a domain there are 2 main reasons. Operator error, and an actual > MITM or similar attack.
In these early days of DNSSEC deployment, we've seen numerous occasions in which the first has applied. Can you provide URLs to the cases where the second has applied? > If the operators of validating resolvers simply turn off validation for > domains that should be validating but are not,* it kicks the door open for > the exact problem that DNSSEC was designed to solve. In the cases I'm aware of when an actual attack that DNSSEC was designed to solve has occurred, there are artifacts in logs. I would presume network operators would, when they get notified that a domain isn't validating, check those logs in their process to determine what's going on. If they notice the artifacts, I suspect they won't install an NTA. > But worse yet, in the operator error case you make such errors painless. Only if you believe there will be universal and instantaneous deployment of NTAs any time the zone operator screws up. I suspect this unlikely. > Of course I realize that the counter-argument is that if DNSSEC fails are too > painful then people will simply not do it. But to the extent that people use > that as a line of reasoning it's simply one more in a long string of excuses. No. It is an acceptance of the operational reality that, at least today, the most common failure mode (by far) is for zone operators to screw up and the remedy for that other person screwing up is to either tell the resolver operators' customers "sorry, the guys at <auth zone> made a booboo and you can't talk to them as long as you use our resolver" or turning validation off for ALL zones. If a zone is sufficiently popular that a resolver operator gets multiple calls when it doesn't validate because the zone's operated boobooed, the resolver operator _will_ turn off validation. Do that enough times and I suspect it becomes questionable whether they'll bother to turn it on again. > The other problem is that this feature is only really useful in the DNSSEC > ramp-up period. Sure, mistakes are more common now, software is immature, > etc. etc. But if DNSSEC is successful, the software will get better (it > already is a lot better than even a few years ago), and mistakes will be less > common (both on an absolute, and on a percentage basis). But once you > introduce a feature like this, you cannot remove it. You seem to believe that installing NTAs is without cost. First, it requires operator intervention in response to a notification. Second, I believe it opens the resolver operator up to liability -- by installing an NTA, they are, by direct intervention of their staff, purposefully defeating a protection that they explicitly configured that puts all of their customers at risk. The longer the NTA is left in place, the greater the risk. > ... and of course, I should point out that adding this as a knob is utterly > pointless, since any reasonably competent validating resolver operator can > engineer their own trapdoor. Since not all validating resolvers support NTAs, if you want to supply text, I'd support adding a section describing alternative approaches to implementing NTA functionality. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
