[dns-operations] Quad9 DNSSEC Validation?

Scott Morizot tmorizot at gmail.com
Sun Feb 28 12:37:48 UTC 2021


On Sun, Feb 28, 2021 at 1:59 AM Winfried Angele <abang at t-ipnet.net> wrote:

> >Resolution fails as expected on our recursive infrastructure.
> >Resolution
> >fails through my personal Internet ISP's recursive nameservers
> >(Suddenlink)
> >which are also validating. And 8.8.8.8 and 1.1.1.1 return the expected
> >SERVFAIL. But 9.9.9.9 does not.
>
> I guess they've turned off validation for irs.gov because of a former
> failure. Maybe this one?
> https://dnsviz.net/d/irs.gov/XqOruQ/dnssec/?no_js=1
>
>
Yes, that failure was a big deal to us when it happened last spring. There
were a number of factors that led to it, some of them pandemic related, and
it created a major disruption across our enterprise network, not just for
Internet users. It was also a relatively pretty brief interruption in the
night in the US. The history of it in DNSViz is mostly from me working on
the problem. And it was resolved in a few hours.

https://dnsviz.net/d/irs.gov/XqPUOQ/dnssec/?no_js=1

At the IRS, we have DNSSEC validation enabled throughout our recursive
infrastructure and most of our internal DNS is also signed. If anything
fails in our infrastructure and signing, it impacts 100% of our employees
as well as the roughly one third of client queries in the US that originate
exclusively from behind DNSSEC validating recursive nameservers.

https://stats.labs.apnic.net/dnssec/US

Nobody contacted us. There is no reason to rush to put in a negative trust
anchor that quickly absent some sort of public outcry, which did not occur.
And there is certainly no reason for it to still be in place almost a year
later.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210228/1c619ceb/attachment.html>


More information about the dns-operations mailing list