[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 

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 


More information about the dns-operations mailing list