On 10/24/14 9:01 AM, Warren Kumari wrote:
Hi all,
This draft has risen from the deep...
It describes a technique that a number of DNS operators use to
surgically / tactically deal with DNSSEC validation failures, for
large-scale outages.
We believe that this is needed -- simply telling customers "This
doesn't work through us, but does work through
$non-validating-competitor because we are better" simply leads to
customers changing to $non-validating-competitor, or operator turning
off DNSSEC for everybody.
Well that would be an incredibly stupid thing to tell a customer. :)
"Currently the operators of example.com have introduced an error into
their DNS information which is causing the domain to be unresolvable.
Once they have corrected that error our customers will be able to reach
their site again. You can go to the following web page to view detailed
information about the problem ..."
I'm aware of the problems that providers face when something doesn't
work and it's not their fault; been there, done that. But ...
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. 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.
But worse yet, in the operator error case you make such errors painless.
Instead, if they are painful (as in, screw up DNSSEC and you go off
line) then it leads to more people taking DNSSEC seriously, and doing it
right. 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.
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.
So can we please let the functionality of DNSSEC stand as designed, and
not give people a giant trapdoor that they can trigger at the slightest
sign of trouble? Otherwise, why bother?
... 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. IMO this further cements the
argument that adding this as a knob in software will only facilitate its
use by people who should not be using it.
Doug
* I realize that the proponents of this mechanism believe that everyone
who uses it will use it "properly," by validating a trusted source for
information about why it's failing, only leaving it enabled for a short
time, etc. Can we please be honest about the fact that in the majority
of cases that simply won't be true?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
