[dns-operations] Implementation of negative trust anchors?
Scott Morizot
tmorizot at sd.is.irs.gov
Fri Aug 23 21:43:51 UTC 2013
On 22 Aug 2013 at 15:59, WBrown at e1b.org wrote:
> Running the DNS for 100+ school districts and 400,000+ devices, I really,
> REALLY don't want to be the one saying "Sorry, you can't use the site
> called for in your lesson plan today because they messed up the DNSSEC
> records." Management's response would be "Just make it work!"
>
> Without a per domain NTA, the only option would be to turn off DNSSEC,
> returning to square one.
I'm the engineer responsible for DNS in an organization with something on
the order of a thousand sites, over 100K employees, and I'm not even
going to estimate the number of devices. We've been DNSSEC validating all
query responses from the Internet for two years now and we routinely tell
employees that if a domain is DNSSEC signed and has messed up its zone,
they won't be able to resolve it (no web access and no email to it) until
the problem is fixed on the authoritative end.
The only time I've sought and received emergency approval to disable
DNSSEC validation was during the recent snafu Verisign made with .gov.
Fortunately I saw it and was able to react before things started failing
on our own network.
I understand why it's necessary for early adopter ISPs. Their customers
won't understand why they can't resolve something, but other ISPs can. We
saw with Comcast and the nasa.gov failure a while back. Once a number of
major ISPs have enabled validation, though, it should no longer be
necessary.
It should never be necessary for an enterprise or government network. If
you've made the organizational decision to implement DNSSEC validation,
then it's rightly an all or nothing approach. A validate some things and
not others approach is largely useless.
> Our browsers give us the option to trust invalid TLS certificates, some
> even storing it indefinitely. Is an NTA much different?
Yes, and we all see how well that's worked out from a security
perspective...
Scott
More information about the dns-operations
mailing list