Major DNSSEC Outages and Validation Failures

Updated: March 31, 2024

This page lists only DNSSEC failures that have the potential to cause downtime for a significant number of domains, users, or both. It does not list smaller outages such as dominos.com ($1.425 Billion in yearly revenue), the Government of California, or other such "small" organizations. They are too frequent to mention. Technical and media/content organizations are held to a higher standard.

Principal sources of information: DNSViz, Verisign's DNSSEC Debugger, zonemaster.se, zonemaster.nic.cz, and Unbound logs. Discussions on technical mailing lists are also used as sources.

Note: DNSViz has lost a portion of its archives multiple times, turning many citations on this page into 404s. Currently, the dnssec-deployment.org mailing list archives have been down for several years, and previously for around 5 months, producing more 404s. Constant DNSSEC outages desensitize people to downtime, making them think it's normal.

Root servers

• m.root-servers.net (March 2010) ^{PMTU issues}
• j.root-servers.net (May 2013)

TLD DNSSEC outages

• .se — Sweden (October 2009)
• .arpa — Address and Routing Parameter Area (June 2010)
• .us — USA (September 2010)
• .be — Belgium (September 2010)
• .uk — United Kingdom (September 2010)
• .fr — France (September 2010)
• .be — Belgium (October 2010)
• .th — Thailand (November 2010)
• .be — Belgium (December 2010)
• .eu — Europe (December 2010)
• .gi — Gibraltar (January 2011)
• .fr — France (February 2011)
• .fr — France (March 2011)
• .kg — Kyrgyzstan (February 2011)
• .nz — New Zealand (December 2011) ^{DNSSEC RFC non-compliance leads to failures with some BIND tools}
• .cz — Czech Republic (February 2012) ^{Affected DNSSEC software based on the Go RSA package}
• .us — United States (February 2012) ^{Affected DNSSEC software based on the Go RSA package}
• .pl — Poland (June 2012) ^partial
• .gov — US Government (June 2012)
• .mm — Myanmar (July 2012)
• .dk — Denmark (August 2012)
• .gov — US Government (September 2012) ^{Affected .gov servers near NYC}
• .dk — Denmark (September 2012) ^{partial outage limited to IPv6}
• .nl — Netherlands (October 2012)
• .dk — Denmark (November 2012) ^partial
• .xn--mgbx4cd0ab — Malaysia (December 2012)
• .mil — US Military (December 2012)
• .mm — Myanmar (January 2013)
• .mm — Myanmar (March 2013)
• .com via b.gtld-servers.net (May 2013)
• .mil — US Military (May 2013)
• .biz — dot biz (June 2013)
• .mm — Myanmar (June 2013)
• .mm — Myanmar (July 2013)
• .gov — US Government (August 2013)
• .xn--l1acc — Mongolia (August 2013)
• .mm — Myanmar (August 2013)
• .xn--l1acc — Mongolia (September 2013)
• .xn--l1acc — Mongolia (October 2013)
• .xn--80asehdb — Cyrillic IDN (October 2013) ^{bogus NXDOMAINs}
• .xn--80aswg — Cyrillic IDN (October 2013) ^{bogus NXDOMAINs}
• .xn--80asehdb — Cyrillic IDN (November 2013)
• .xn--l1acc — Mongolia (November 2013)
• .xn--80aswg — Cyrillic IDN (November 2013)
• .xn--l1acc — Mongolia (December 2013)
• .kg — Kyrgyzstan (January 2014)
• .xn--l1acc — Mongolia (January 2014)
• .red — new gTLD (January 2014) ^{Probably not operational}
• .rich — new gTLD (January 2014) ^{Probably not operational}
• .xn--l1acc — Mongolia (February 2014)
• .pink — new gTLD (February 2014)
• .xn--l1acc — Mongolia (March 2014)
• .xn--l1acc — Mongolia (April 2014)
• .gop — Republican State Leadership Committee, Inc. (April 2014) ^{Probably not operational}
• .xn--6qq986b3xl — Tycoon Treasure Limited (April 2014)
• .xn--3bst00m — Eagle Horizon Limited (April 2014)
• .xn--l1acc — Mongolia (May 2014)
• .xn--l1acc — Mongolia (June 2014)
• .xn--l1acc — Mongolia (July 2014)
• .soy — new gTLD (July 2014)
• .foo — new gTLD (July 2014)
• .mm — Myanmar (July 2014)
• .xn--l1acc — Mongolia (August 2014)
• .ke — Kenya (August 2014) ^{ke/SOA fails, affecting a small percentage of DNSSEC queries}
• .link — new gTLD (August 2014)
• .mm — Myanmar (August 2014) ^partial
• .xn--l1acc — Mongolia (September 2014)
• .capetown — new gTLD (September 2014)
• .sx — Sint Maarten (September 2014) ^partial
• .firmdale — new gTLD (December 2014)
• .fashion — new gTLD (December 2014) ^partial
• .kg — Kyrgyzstan (January 2015)
• .lb — Lebanon (March 2015)
• .firmdale — new gTLD (March 2015)
• .ke — Kenya (March 2015)
• .xn--l1acc — Mongolia's IDN TLD (April 2015)
• .lat — Latino gTLD (May 2015) ^partial
• .xn--y9a3aq — Armenia (June 2015)
• .xn--y9a3aq — Armenia (July 2015)
• .mm — Myanmar (September 2015)
• .hr — Croatia (October 2015)
• .xn--y9a3aq — Armenia (November 2015)
• .zm — Zambia (December 2015)
• .mil — US Military (December 2015)
• .mm — Myanmar (December 2015)
• .bw — Botswana (December 2015 - January 2016)
• .bridgestone (January 2016)
• .epson (January 2016)
• .honda (January 2016)
• .hyundai (January 2016)
• .kia (January 2016)
• .komatsu (January 2016)
• .lixil (January 2016)
• .nec (January 2016)
• .ricoh (January 2016)
• .toyota (January 2016)
• .az — Azerbaijan (January 2016) ^partial
• .is — Iceland (January 2016)
• .mm — Myanmar (March 2016)
• .mm — Myanmar (April 2016)
• .mm — Myanmar (June 2016)
• .id — Indonesia (July 2016)
• .xn--pgbs0dh — Tunisia (July 2016)
• .xn--pgbs0dh — Tunisia (August 2016)
• .smart — new gTLD (October 2016)
• .win — new gTLD (November 2016)
• .bw — Botswana (November 2016)
• .ad — Andorra (December 2016)
• .ke — Kenya (December 2016)
• .mg — Madagascar (February 2017) ^{Bogus NSEC records}
• .org (February 2017) ^{limited in scope}
• .mg — Madagascar (February 2017)
• .xn--mgbx4cd0ab — Malaysia IDN (April 2017)
• .mg — Madagascar (April 2017)
• .co.id — Indonesia (April 2017)
• .org (April 2017) ^{limited in scope}
• .info (April 2017) ^{limited in scope}
• .mg — Madagascar (April 2017)
• .mg — Madagascar (April 2017)
• .hotels (May 2017)
• .mg — Madagascar (May 2017)
• .mg — Madagascar (May 2017)
• .ad — Andorra (May 2017)
• .mg — Madagascar (May 2017)
• .mg — Madagascar (June 2017)
• .xn--mgbai9azgqp6j — Pakistan (June 2017)
• .mg — Madagascar (June 2017)
• .mg — Madagascar (June 2017)
• .mg — Madagascar (July 2017)
• .mg — Madagascar (July 2017)
• .mg — Madagascar (August 2017)
• .mg — Madagascar (August 2017)
• .mg — Madagascar (August 2017)
• .mg — Madagascar (September 2017)
• .sakura — Japanese gTLD (September 2017)
• .jprs — Japanese gTLD (September 2017)
• .ntt — Japanese gTLD (September 2017)
• .bw — Botswana (October 2017)
• .lidl — new gTLD (December 2017)
• .schwarz — new gTLD (December 2017)
• .pr — Puerto Rico (December 2017)
• .kg — Kyrgyzstan (January 2018)
• .vu — Vanuatu (January 2018)
• .pr — Puerto Rico (January 2018)
• .ar — Argentina (February 2018)
• .vn — Vietnam (March 2018)
• .how — new gTLD (April 2018)
• .zm — Zambia (April 2018)
• .my — Malaysia (June 2018)
• .pt — Portugal (July 2018)
• .mtr — new gTLD (September 2018)
• .zm — Zambia (October 2018)
• .xn--mgbx4cd0ab — Malaysia (November 2018)
• .mm — Myanmar (November 2018)
• .moscow (November 2018)
• .be, .vlaanderen, .brussels — Belgium (November 2018) ^{affected 1410 domains}
• .lr — Liberia (November 2018)
• .by — Belarus (November 2018)
• .xn--y9a3aq — Armenia (December 2018)
• .hiv (December 2018)
• .mg — Madagascar (December 2018)
• .kg — Kyrgyzstan (January 2019)
• .ad — Andorra (January 2019)
• .mg — Madagascar (March 2019)
• .mg — Madagascar (March 2019)
• .zm — Zambia (April 2019)
• .mg — Madagascar (April 2019)
• .mg — Madagascar (May 2019)
• .mg — Madagascar (May 2019)
• .mg — Madagascar (June 2019)
• .mg — Madagascar (June 2019)
• .pl — Poland (June 2019)
• .mg — Madagascar (July 2019)
• .na — Namibia (July 2019)
• .mg — Madagascar (July 2019)
• .mg — Madagascar (July 2019)
• .mg — Madagascar (August 2019)
• .firestone (August 2019)
• .ru — Russia (August 2019)
• .tn — Tunisia (September 2019)
• .tn — Tunisia (October 2019)
• .ss — South Sudan (October 2019)
• .unicom (October 2019)
• .xn--8y0a063a (October 2019)
• .xn--qxam — Greek IDN (November 2019)
• .rs — Serbia (November 2019)
• .xn--3hcrj9c — India IDN (January 2020)
• .xn--mgbbh1a — IDN TLD (January 2020)
• .xn--rvc1e0am3e — IDN TLD (January 2020)
• .ss — South Sudan (February 2020)
• .xn--90ae — IDN TLD (March 2020)
• .llp (April 2020)
• .xn--wgbh1c — IDN TLD (June 2020)
• .ss — South Sudan (July 2020)
• .xn--mgbai9azgqp6j (August 2020)
• .beauty (September 2020)
• .ss — South Sudan (October 2020)
• .lb — Lebanon (November 2020)
• .lr — Liberia (November 2020)
• .tn — Tunisia (May 2021)
• .xn--y9a3aq — Armenia (July 2021)
• .bn — Brunei (July 2021)
• .xn--qxam — Greek IDN (August 2021)
• .tm — Turkmenistan (December 2021)
• .se — Sweden (February 2022) ^partial
• .fj — Fiji (March 2022)
• .au — Australia (March 2022)
• .ma — Morocco (April 2022) ^partial
• .bn — Brunei (May 2022)
• .kg — Kyrgyzstan (August 2022)
• .kg — Kyrgyzstan (August 2022)
• .tm — Turkmenistan (September 2022)
• .na — Namibia (October 2022)
• .xn--qxam — Greek IDN (November 2022)
• .mx — Mexico (April 2023)
• .nz — New Zealand (May 2023)
• .ve — Venezuela (July 2023)
• *.au — Australia (September 2023)
• .ci — Côte d'Ivoire (October 2023)

Major sites

• gov.dlv.isc.org (March 2009)
• edu.dlv.isc.org (April 2009)
• dlv.isc.org (April 2009)
• RIPE (December 2009) ^{Affected Fedora Linux}
• RIPE (June 2010) ^partial
• mozilla.org (September 2010)
• AFNIC.fr (November 2010)
• medicare.gov & cms.gov (December 2010)
• e164.arpa (February 2011)
• AFNIC.fr (March 2011)
• RIPE (April 2011)
• ip6.arpa (May 2011)
• co.th (June 2011)
• NIST (July 2011)
• Verisign (July 2011)
• FBI (November 2011)
• 54.in-addr.arpa (December 2011)
• secure.registry.be (December 2011)
• CAcert (December 2011)
• NASA (January 2012)
• Internet Software Consortium (February 2012)
• e.0.1.0.0.2.ip6.arpa (APNIC) (May 2012)
• Verisign (June 2012)
• Google Public DNS (November 2012) ^partial
• CDC: Centers for Disease Control and Prevention (December 2012)
• National Weather Service (December 2012)
• APNIC (December 2012)
• US Department of the Treasury (January 2013)
• 54.in-addr.arpa — ARIN (April 2013)
• mozilla.org (May 2013)
• ic.fbi.gov (July 2013) ^{DNSSEC outage lasted until September}
• IRS (August 2013)
• 174.in-addr.arpa: ARIN (November 2013)
• Dyn (December 2013) ^{status page deleted}
• pagerduty.com (December 2013)
• USDA (December 2013)
• NBC News (January 2014)
• National Science Foundation (March 2014)
• af.mil (April 2014)
• 172.in-addr.arpa (May 2014)
• af.mil (June 2014) ^partial
• af.mil (June 2014)
• IETF (June 2014)
• NASA (July 2014)
• NASA (August 2014)
• getdnsapi.net (August 2014)
• Dyn (August 2014) ^{status page deleted}
• knot-dns.cz (August 2014) ^partial
• dnssec-name-and-shame.com (August 2014)
• libreswan.org (September 2014) ^{related to a nohats.ca DNSSEC outage}
• root-dnssec.org (November 2014) ^{DNS provided by ICANN!}
• FBI (December 2014)
• opendnssec.org (January 2015)
• libreswan.org (February 2015) ^{related to another nohats.ca DNSSEC outage}
• dnscrypt.pl (February 2015)
• HBO Now (March 2015)
• cloudflare-dnssec-auth.com (March 2015)
• af.mil (April 2015)
• xfinity.com (May 2015)
• af.mil (May 2015)
• internetsociety.org, isoc.org (June 2015)
• af.mil (June 2015)
• nasa.gov (August 2015)
• NICMX (August 2015)
• nasa.gov (August 2015)
• state.gov (September 2015)
• state.gov, usembassy.gov (September 2015)
• nasa.gov (October 2015) ^partial
• xfinity.com (October 2015)
• defcon.org (December 2015)
• af.mil (December 2015) ^partial
• libreswan.org (March 2016) ^{partial outage; related to another nohats.ca DNSSEC outage}
• 65.in-addr.arpa (March 2016)
• lacnic.net (March 2016)
• APNIC (March 2016)
  • 1.in-addr.arpa
  • 14.in-addr.arpa
  • 27.in-addr.arpa
  • 36.in-addr.arpa
  • 39.in-addr.arpa
  • 42.in-addr.arpa
  • 43.in-addr.arpa
  • 49.in-addr.arpa
  • 58.in-addr.arpa
  • 59.in-addr.arpa
  • 60.in-addr.arpa
  • 61.in-addr.arpa
  • 101.in-addr.arpa
  • 103.in-addr.arpa
  • 106.in-addr.arpa
  • 110.in-addr.arpa
  • 111.in-addr.arpa
  • 112.in-addr.arpa
  • 113.in-addr.arpa
  • 114.in-addr.arpa
  • 115.in-addr.arpa
  • 116.in-addr.arpa
  • 117.in-addr.arpa
  • 118.in-addr.arpa
  • 119.in-addr.arpa
  • 120.in-addr.arpa
  • 121.in-addr.arpa
  • 122.in-addr.arpa
  • 123.in-addr.arpa
  • 124.in-addr.arpa
  • 125.in-addr.arpa
  • 150.in-addr.arpa
  • 153.in-addr.arpa
  • 163.in-addr.arpa
  • 171.in-addr.arpa
  • 175.in-addr.arpa
  • 180.in-addr.arpa
  • 182.in-addr.arpa
  • 183.in-addr.arpa
  • 202.in-addr.arpa
  • 203.in-addr.arpa
  • 210.in-addr.arpa
  • 211.in-addr.arpa
  • 218.in-addr.arpa
  • 219.in-addr.arpa
  • 220.in-addr.arpa
  • 221.in-addr.arpa
  • 223.in-addr.arpa
• libsodium.org & dnscrypt.org (April 2016)
• libsodium.org (May 2016)
• dnscrypt.org (June 2016)
• yadifa.eu (June 2016)
• opendnssec.org (July 2016)
• www.nsf.gov/A (July 2016)
• afnic.fr (July 2016)
• secure64.com (July 2016)
• af.mil (August 2016)
• www.nist.gov and time.nist.gov (August 2016)
• nist.gov (September 2016)
• pch.net (September 2016)
• opendnssec.org (October 2016)
• dnssek.info (October 2016)
• dnssec-tools.org (October 2016)
• berkeley.edu (December 2016) ^partial
• time.nist.gov (December 2016) ^partial
• dnssek.info (December 2016)
• opendnssec.org (December 2016)
• cia.gov (January 2017)
• tinydnssec.org (January 2017) ^partial
• service-now.com (January 2017)
• Georgia State University (January 2017)
• abuse.ch (February 2017)
• internetsociety.org (February 2017)
• danyork.com (February 2017)
• Godaddy (domaincontrol.com) DNS (March 2017) ^{affected DANE users}
• libreswan.org (April 2017) ^{related to more nohats.ca DNSSEC trouble}
• nic.in (April 2017)
• iastate.edu (May 2017)
• dnscrypt.pl (May 2017)
• dnscrypt.pl (May 2017)
• marines.mil (May 2017)
• dnscrypt.pl (June 2017)
• dnscrypt.eu (June 2017)
• University of Waterloo Campus DNS (June 2017)
• dns-oarc.net (June 2017)
• defcon.org (June 2017)
• e164.arpa (June 2017)
• Namecheap customer DNSSEC (June 2017)
• California State Polytechnic University, Pomona (July 2017)
• dnscrypt.pl (August 2017)
• www.tinydnssec.org (August 2017)
• dnscrypt.pl (August 2017)
• dnssek.info (August 2017)
• dnscrypt.pl (September 2017)
• fedoraproject.org (September 2017)
• getdnsapi.net (September 2017)
• dnssec-name-and-shame.com (September 2017)
• xfinity.com (September 2017)
• comcast.net (September 2017)
• comcast.com (September 2017)
• nasa.gov (October 2017)
• dnssec-tools.org (October 2017)
• vmware.com (October 2017)
• root-dnssec.org (October 2017)
• ip6.arpa (October 2017)
• in-addr.arpa (October 2017)
• icann.org (October 2017)
• dotat.at (November 2017)
• www.nasa.gov (November 2017)
• nasa.gov (December 2017)
• gsu.edu / Georgia State University (December 2017)
• dnssec-tools.org (December 2017)
• uwm.edu (December 2017)
• gsu.edu / Georgia State University (January 2018)
• libsodium.org (January 2018)
• nau.edu (January 2018)
• dnssec-tools.org (January 2018)
• unt.edu (February 2018)
• www.openswan.com (February 2018)
• opendnssec.org (February 2018)
• libsodium.org (March 2018)
• state.gov, usembassy.gov (March 2018)
• dnssec-tools.org (March 2018)
• libsodium.org (April 2018)
• ucr.edu (April 2018)
• nist.gov (April 2018)
• army.mil (April 2018)
• temple.edu (May 2018)
• dnsops.gov (June 2018)
• dnssek.info (June 2018)
• dnsops.gov (June 2018)
• gentoo.org (June 2018)
• co.bw (July 2018)
• dhs.gov (August 2018)
• uscis.gov (August 2018)
• dnsops.gov (September 2018)
• hhs.gov (September 2018)
• temple.edu (September 2018)
• dnsops.gov (September 2018)
• dnssek.info (September/October 2018)
• denic.de (October 2018)
• dnsops.gov (October 2018)
• homelandsecurity.gov (November 2018)
• census.gov (November 2018)
• fema.gov (November 2018)
• hhs.gov (December 2018)
• arin.net (January 2019)
• comcast.net (January 2019)
• uchicago.edu (January 2019)
• Namecheap customer DNSSEC (February 2019)
• lsu.edu (February 2019)
• dnssek.info (March 2019)
• www.cloudflare.com (March 2019)
• berkeley.edu (April 2019)
• cdc.gov (May 2019)
• af.mil (May 2019)
• af.mil (May 2019)
• house.gov (May 2019)
• libreswan.org (May 2019) ^{related to another nohats.ca DNSSEC outage}
• Georgia State University (June 2019)
• time.nist.gov (June 2019)
• dnscrypt.pl (July 2019)
• time.nist.gov (July 2019)
• nohats.ca (October 2019)
• dnssek.info (November 2019)
• nsf.gov (November 2019)
• decentsecurity.com (December 2019)
• nohats.ca (January 2020)
• www.getdnsapi.net (March 2020)
• dlv.isc.org (March 2020)
• army.mil (April 2020)
• caltech.edu (April 2020)
• dnssec-validator.cz (April 2020)
• irs.gov (April 2020)
• army.mil (July 2020)
• nohats.ca (September 2020)
• libreswan.org (September 2020)
• af.mil (September 2020)
• dnssec-deployment.org (September 2020)
• army.mil (September 2020)
• army.mil (October 2020)
• abuse.ch (October 2020)
• psg.com (November 2020)
• internetsociety.org (November 2020)
• libhydrogen.org (December 2020)
• www.usembassy.gov (December 2020)
• cdc.gov (January 2021)
• dnscrypt.pl (February 2021)
• dnssek.info (March 2021)
• parler.com (April 2021)
• epa.gov (April 2021)
• nih.gov (April 2021)
• nist.gov (June 2021)
• lequipe.fr (June 2021)
• slack.com (September 2021)
• europa.eu (December 2021)
• dnsops.gov (February 2022)
• europa.eu (March 2022)
• gsu.edu (March 2022)
• temple.edu (May 2022)
• nist.gov (June 2022)
• nohats.ca (July 2022)
• dnssec-name-and-shame.com (July 2022)
• mail.mil (September 2022)
• ns{1..4}.dnsimple.com (September 2022) ^{Broken black lies implementation}
• mail.mil (November 2022)
• 41.in-addr.arpa/NS (December 2022)
• tamu.edu (January 2023)

Long DNSSEC outages

The median duration of a DNSSEC outage is 8 days. The following may or may not concern large organizations, but when duration is taken into account, a major outage is implied. Bidding starts at 1 DNSSEC-year.

Terminology note: The coveted 1000-day DNSSEC outage is known as a kiloday.

• 397 days: xn--l1acc (Mongolia's IDN TLD) — beginning (archive lost) to end.
• 457 days: moprosecutors.gov — oldest saved to final outage to end(ish).
  • Plus 85 days to maintain eye contact,
  • followed by 139 days to assert its dominance,
  • and 11 more days to cool down,
  • then 19 days posing provocatively in the mirror,
  • and finally 740 days to leave the Internet behind.
• 495 days: mojavedata.gov — beginning to last to unsigned.
• 689 days: nepa.gov — beginning to last to to end.
• 986 days: dcmsa.mil — beginning to last to end.
• 1053 days: dmg.gov — beginning (archive lost) to last(ish).
  • Also: 213 days beginning to end.
• 1266 days: learnatf.gov — oldest archived to last.
• 1483 days: eureka-mt.gov — oldest archived to last to end.
• 1653 days: validatorsearch.verisignlabs.com — beginning to end.
• 1996 days: educom.edu — oldest archived to end(ish).
• 3116 days: gatrees.gov — beginning to ongoing.

Software

• BIND: CVE-2001-0497: insecure permissions for a HMAC-MD5 shared secret key file (July 2001)
• BIND: CVE-2005-0034: Denial of Service (May 2005)
• BIND: CVE-2006-4095: BIND vulnerable to an assertion failure when querying for SIG records (September 2006)
• BIND: BIND and OpenSSL's RSA signature forging issue (September 2006)
• BIND: CVE-2007-0494: Denial of Service (January 2007)
• DNSSEC-Tools: CVE-2008-1184: Unspecified Attacks (March 2008)
• Debian: CVE-2008-0166: "Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and..." (May 2008)
• Unbound: CVE-2009-3602: DNS Cache Poisoning (October 2009)
• BIND: CVE-2009-4022: DNS Cache Poisoning (November 2009)
• BIND: CVE-2010-0097: Bogus NXDOMAIN responses (January 2010)
• BIND: CVE-2010-0290: DNS Cache Poisoning (January 2010)
• Unbound: Validation failure of DNSSEC signed domain names (May 2010)
• BIND: CVE-2010-0213: Denial of Service (July 2010)
• BIND: CVE-2010-3762: Denial of Service (October 2010)
• BIND: CVE-2010-3613: Denial of Service (December 2010)
• BIND: CVE-2010-3614: Denial of Service (December 2010)
• BIND: CVE-2010-3615: Information Leakage (December 2010)
• BIND: Denial of Service: crash with 2+ trust anchors and bad signature (February 2011)
• BIND: Denial of Service: NSEC3PARAM record placed inside a zone which is not properly signed with NSEC3 could cause named to crash, if changed via dynamic update (February 2011)
• BIND: CVE-2011-1907: Denial of Service (May 2011)
• BIND: CVE-2011-1910: Denial of Service (May 2011)
• Unbound: CVE-2009-4008: Denial of Service (June 2011)
• BIND: change #3121: Denial of Service (October 2011)
• Unbound: CVE-2011-4528: Denial of Service (December 2011)
• Unbound: CVE-2011-4869: Denial of Service (December 2011)
• BIND: CVE-2012-1033: "ghost domain names" attack (February 2012)
• BIND: CVE-2012-3817: Denial of Service (July 2012)
• BIND: "persistence in cache of invalid RRSIGs" (March 2013)
• BIND: named hang "may occur in some situations when generating new NSEC / NSEC3 chains." (April 2013)
• PowerDNS: bug breaks DNSSEC — interoperability bug with BIND (April 2013)
• BIND: CVE-2013-4854: Denial of Service in RFC 5011 implementation (July 2013)
• BIND: Tony Finch - A weird BIND DNSSEC resolution bug, with a fix (December 2013)
• BIND: [dns-operations] bind-9.9.4-P1 crash — Solution is "[t]urning off dnssec and validation." (December 2013)
• BIND: CVE-2014-0591: A Crafted Query Against an NSEC3-signed Zone Can Crash BIND (January 2014)
• BIND: "Fixed a crash-on-shutdown race condition with DNSSEC validation." (January 2014)
• Knot DNS: "several problems in DNSSEC... deadlock of the main server thread... [extremely insufficient signature refresh]..." (January 2014)
• Knot DNS: assertion failures (February 2014)
• dnsmasq: Segfault with DNSSEC (March 2014)
• Windows Server DNS: Issue 1: SERVFAILs (April 2014)
• Windows Server DNS: Issue 2: NSEC validation failures (April 2014)
• dnsmasq: Segfault in DNSSEC code (April 2014)
• dnsmasq: Had to disable dnssec today (April 2014)
• Knot DNS: Problem with expiring zones - new stable version (July 2014)
• Tony Finch - widespread bugs in nameserver EDNS truncation which cause problems for DNSSEC (July 2014)
• Knot DNS: NSEC proof crash (September 2014)
• BIND: When resigning, dnssec-signzone was removing all signatures from delegation nodes (September 2014)
• BIND: RRSIG sets that were not loaded in a single transaction at start up were not being correctly added to re-signing heaps (September 2014)
• Windows Server 2012 R2: DNS server that has DNSSEC enabled does not validate signed zones (December 2014)
• dnsmasq: "RSA/SHA1-NSEC3-SHA1 signature bug?" (January 2015)
• dnsmasq: DNSSEC crashes and other DNSSEC problems (April 2014 through January 2015)
• Windows Server 2012 R2: Validation fails for some DNSSEC-signed zones (January 2015)
• BIND: "RRSIGs omitted from Authority section leads to DNSSEC failures" (February 2015)
• BIND: CVE-2015-1349: Denial of Service (February 2015)
• dnsmasq: Denial of Service: "Fix crash in DNSSEC code with long RRs." (March 2015)
• dnsmasq and TCP: "It essentially makes DNSSEC unusable at the moment." (April 2015)
• Announce: dnsmasq-2.73: "Fix crash in DNSSEC code with long RRs." (June 2015)
• BIND: CVE-2015-4620: Denial of Service (July 2015)
• ldns-signzone: "ldns-signzone ECDSA random failure" (August 2015)
• Knot DNS: Denial of Service: DNSKEY RRSIGs overlooked in zone resign (August 2015)
• BIND: CVE-2015-5722: Denial of Service: remote attacker may cause BIND to exit (September 2015)
• BIND: CVE-2015-3193: key disclosure (December 2015)
• Windows Server 2012 R2: Incorrect response when DNS server uses wildcard CNAME and DNSSEC validation failures (January 2016)
• Windows Server 2012: DNSSEC validation fails when incorrect response to DNSKEY query is sent (February 2016)
• PowerDNS Recursor: Denial of Service: Some Chrome clients fail "exclusively for DNSSEC signed domains" (August 2016)
• BIND: CVE-2016-9147: An error handling a query response containing inconsistent DNSSEC information could cause an assertion failure bind (January 2017)
• BIND: CVE-2016-9444: An unusually-formed DS record response could cause an assertion failure (January 2017)
• [Dnsmasq-discuss] dnsmasq treats Islands of Security as bogus (March 2017)
• Ubuntu / systemd: DNSSEC prevents network access in certain cases (April 2017)
• Knot Resolver: Fix a critical DNSSEC flaw (August 2017)
• Knot Resolver: Signatures might be accepted as valid even if signed data not in bailiwick (August 2017)
• Unbound: qname-minimisation breaks TLSA lookups with CNAMEs (August 2017)
• PowerDNS Recursor: CVE-2017-15090: Insufficient validation of DNSSEC signatures (November 2017)
• PowerDNS Recursor: CVE-2017-15094: Memory leak in DNSSEC parsing (November 2017)
• Unbound: CVE-2017-15105: a vulnerability in the processing of wildcard synthesized NSEC records (January 2018)
• dnsmasq: CVE-2017-15107: "Wildcard synthesized NSEC records could be improperly interpreted to prove the non-existence of hostnames that actually exist" (January 2018)
• PowerDNS Recursor: CVE-2018-1000003: MITM may deny existence of some data in DNS via packet replay (January 2018)
• BIND: CVE-2017-3139: Denial of Service (April 2019)
• dnsmasq: CVE-2020-25681: buffer overflow (February 2021)

Miscellaneous

• DNSSEC defeated by the Great Firewall of China
  "If a site was blocked by authorities, I couldn't resolve it at all, but that was also the case even if I wasn't doing validation on my laptop resolver, but instead using the resolver provided by DHCP."
• A Longitudinal, End-to-End View of the DNSSEC Ecosystem:
  "Our investigation reveals pervasive mismanagement of the DNSSEC infrastructure. For example, we found that 31% of domains that support DNSSEC fail to publish all relevant records required for validation; 39% of the domains use insufficiently strong key-signing keys; and although 82% of resolvers in our study request DNSSEC records, only 12% of them actually attempt to validate them."
• Thomas H. Ptacek:
  "Reminder: you could publish the DNSSEC root RSA secret keys on Pastebin and nothing on the Internet that matters would break."
• Matt Brown: Calling time on DNSSEC: The costs exceed the benefits
  "I'm calling time on DNSSEC. Last week, prompted by a change in my DNS hosting setup, I began removing it from the few personal zones I had signed. Then this Monday the .nz ccTLD experienced a multi-day availability incident triggered by the annual DNSSEC key rotation process. This incident broke several of my unsigned zones, which led me to say very unkind things about DNSSEC on Mastodon and now I feel compelled to more completely explain my thinking: For almost all domains and use-cases, the costs and risks of deploying DNSSEC outweigh the benefits it provides. Don't bother signing your zones."
• Dan Bernstein: Amplification via servers
  "...triggers a 3995-byte UDP packet. If the original 36-byte UDP packet has a forged sender address of 198.41.0.4 then the ISC server will send its 3995-byte UDP packet to 198.41.0.4."
• Cloudflare: Deep Inside a DNS Amplification DDoS Attack
  "Note, ironically, how the effectiveness of the attack based on the size of the response is made worse by the inclusion of the huge DNSSEC keys -- a protocol designed to make the DNS system more secure."
• Adam Langley: Very Large RSA Public Exponents
  "On my 2.66GHz, Core 2 laptop, 15 requests per second causes unbound to take 95% of a core. A couple hundred queries per second would probably put most DNSSEC resolvers in serious trouble."
• [dns-operations] Surprisingly large cluster of domains sharing the same pair of 512-bit ZSKs and some more RSA key oddities
  "Looking closely at the data gathered by the DANE survey I've run into more than 54 thousand (!!!) domains that have the same pair of 512-bit RSA keys for their ZSKs."
• Scott Arciszewski:
  "I don't see any value in DNSSEC"
• Geoff Huston: Peak DNSSEC?
  "From the validation perspective, the use of DNSSEC appeared to have peaked in early 2016 and has been declining since then."
• Jacob Hoffman-Andrews: Issues with DNSSEC, use-caps-for-id, and empty responses
  "At Let's Encrypt, we recently started refusing to issue if there is a failure during CAA lookup, in particular a SERVFAIL. We've received a handful of reports from users who are hitting these SERVFAILs. The authoritative resolver software and the root causes seem to be somewhat different (PowerDNS is one; DNSimple's in-house resolver is another), but it seems like these only happen for people with DNSSEC enabled."
• APNIC: Why DNSSEC deployment remains so low
  "Unfortunately, our recent study showed that DNSSEC deployment is still very low (only ~1% of .com, .net and .org domains deploy DNSSEC), and that over 30% of these domains are, in fact, misconfigured due to missing DS records."
• Bert Hubert: Difficulty of implementing DNSSEC
  "As an implementor, after two years, we keep finding DNSSEC corner cases that make the authors of the very RFCs swoon. The effort of implementing everything correctly is just staggering, our number of regression tests is exploding just to try to keep everything in check. It might have been easier all round to just start from scratch and not pretend that this is 'an enhancement of DNS'. The length of the DNSSEC RFCs exceeds the length of the standardizing RFCs of DNS. By the way, I know some people will immediately chime in DNSSEC isn't that hard, but you won't hear an implementor among them..."
• Paul Vixie: Re: DNSSEC - Signature Only vs the MX/A issue.
  "dnssec is the worst design-by-committee effort i've ever seen, both in terms of how late it is, how fuzzy the goals have been, how often the goals have changed, and how complicated and heavy it is now that it is trying to be all-things-to-all-people."
• Paul Vixie: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
  "so we'll keep pushing the crap system we have, uphill all the way, noone loving it, and almost everyone in fact hating it. we've now spent more calendar- and person-years on DNSSEC than was spent on the entire IPv4 protocol suite (including DNS itself) as of 1996 when the DNSSEC effort began. ugly, ugly, ugly."
• Simon Kelley: RFC5011?
  "My experience is the _nothing_ to do with DNSSEC is 'not too difficult' and, to be honest, any system deploying the releases of dnsmasq with DNSSEC to-date which can't be updated is in a bad way anyway."
• Peter Bowen:
  "Only today did I get a full understanding about how bad DNSSEC is. Major implementations can't even agree on what is bogus vs insecure."
• Simon Kelley: "DNSSEC on lookups of *.paypal.com no longer work"
  "The problem, is that there are many paths that cause DNSSEC validation to fail, and for most of the them, it's not obvious which query to retry and if that would help. In this case retrying the query would be possible, but in most cases, not. If a DNSSEC validation fails, there are many pieces of data that go into that validation, it's not possible to retry all of them and difficult to determine which answers are good and which bad."
• Paul Vixie: [dns-operations] Is DNSSEC causing more problems than it solves.
  "if the ultimate benefit of dnssec is JUST and ONLY to allow caching recursives to detect and reject end to end tampering, then that good is not as large as the risk and cost of deploying dnssec."
• Colm MacCárthaigh:
  "The biggest problems with DNSSEC are that DNSSEC doesn't actually protect DNS queries at their most vulnerable points, that you have to trust your TLD provider, and the root operators completely, with no effective means to fire them, and finally that they almost certainly are using embarrassingly stupid crypto that even most ICOs could avoid. This very deck has several 1024-bit RSA keys, right there on a slide with a February 2018 timestamp, as if it's not an incredibly obviously stupid thing to do since the LogJam paper was published, or you know, when everyone stopped using them for TLS years ago."
• brians on HN:
  "An important thing about layers, about defense in depth, is that you can't even begin to attack one mechanism until you've defeated its predecessors. DANE + TLS doesn't give you layers. If I can subvert your DNSSEC, I can endorse a fresh TLS key, and win. If I can subvert your TLS, I win. This is defense in breadth, a strategy known mostly for its close association with defeat."
• Moxie Marlinspike: SSL And The Future Of Authenticity
  "So unfortunately the DNSSEC trust relationships depend on sketchy organizations and governments, just like the current CA system. Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility."
• Moxie Marlinspike: BlackHat USA 2011: SSL And The Future Of Authenticity
  "We had this map of the EFF's SSL Observatory data on what countries are currently capable of intercepting secure communication under the CA system. Under [DNSSEC/DANE], it would look like this."
• Sonic.net implements DNSSEC, performs MITM against customers...
  "Sonic implemented and deployed DNSSEC - and put it on their shiny new servers along with an [RPZ service] that censors supposed malware and phishing sites. And while they told their customers about DNSSEC, they didn't mention the [RPZ service]... And they diverted traffic to a page that does not mention who is doing the diversion, how, or why, or how to opt out."
• Miek Gieben:
  "Not having to deal with DNSSEC would sure simplify a lot of things :/"
• Measuring the Practical Impact of DNSSEC Deployment
  "DNSSEC-signed domains — even validly signed domains— have a higher failure rate than non-DNSSEC-signed domains: just DNSSEC-signing a domain increases the failure rate from around 0.7846% to 1.006%..."
• Frederic Jacobs: Providing better confidentiality and authentication on the Internet using Namecoin and MinimaLT
  "The fact that even today, DNSSEC is having issues being deployed at a larger scale has a lot to do with its complicated design. Getting DNSSEC right is hard..."
• Simon Kelley: Re: DNSSEC on lookups of *.paypal.com no longer work
  "I run dnsmasq with DNSSEC enabled in production and keep logs. Every so often I check the logs and look at the domains which failed DNSSEC. 95% of the time, by the time I get to do the check, the queries complete successfully. Transient errors seem to be a fact of life with DNSSEC."
• Casey Deccio: Maintenance, mishaps and mending in deployments of the domain name system security extensions (DNSSEC)
  "Our survey indicated that more than one-half of the zones analyzed were affected by misconfigurations. Also, the survey revealed a significant number of repeat occurrences and average correction times of up to two weeks."
• Cloudflare:
  "DNSSEC is complicated and it's easy to get wrong. Unfortunately, getting your DNSSEC configuration wrong creates a real potential harm to the rest of the Internet by making your domain's zone file into a potential weapon to be abused by attackers."
• Akamai: DNSSEC Targeted in DNS Reflection, Amplification DDoS Attacks
  "During the past few quarters, Akamai has observed and successfully mitigated a large number of DNS reflection and amplification DDoS attacks abusing Domain Name System Security Extension (DNSSEC) configured domains...."
• Alex Cowperthwaite and Anil Somayaji: The Futility of DNSSEC
  "More significant, however, is that DNSSEC solves the wrong problem: it secures hostname to IP address mappings when what is really needed is better end-to-end security guarantees. Thus we believe that the deployment of DNSSEC is a futile gesture, one that will lead to minimal long-term security benefits while resulting in significant security and economic costs."
• Thomas H. Ptacek: We are in fact better off without DNSSEC
  "DNSSEC leaks internal hostnames to the Internet because the designers of the protocols prioritized authenticated denials (availability) over confidentiality. NSEC3 is a great illustration of how slapdash the protocol design is: in an attempt to plug that leak, the IETF standardized what is in effect a password hash (and a bad one) to help obscure internal hostnames. When challenged on why the Internet should adopt a 1990s password hash as an Internet core protocol security mechanism, DNSSEC proponents say, ``well, well-managed domains make domain cuts carefully to solve this problem'', as if any commercial network in the world actually does that."
• Dan York: DNS hijack - AVG, Avira and WhatsApp sites affected - seems to be a registrar compromise
  "If this is the case for all of these, there's nothing that DNSSEC or anything else could have done here as the attackers are gaining full access to the domain registrants DNS records and can modify them as they wish."
• Dan York: No, DNSSEC Would NOT Help Prevent Microsoft's Seizure Of Domains
  "Believe me, as a DNSSEC advocate I have jumped every time I see ``domain hijacking'' in media / social media to see if the new incident might show a solid example of where DNSSEC can help. Almost always... it is not."
• Thomas Ptacek: Against DNSSEC
  "The Internet loses nothing if it declares a TKO on DNSSEC and starts fresh. There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers."
• dsl on HN
  "I hate to add ``me too'' replies, but it is important to get the message out there that lots of really smart folks consider DNSSEC an absolute failure of such epic proportions that you shouldn't even joke about building something real on top of it. The only thing DNSSEC has given us is widespread DDoS amplification."
• Nicholas Weaver
  "Overall, unless you are validating on the end host rather than the recursive resolver, DNSSEC does a lot of harm from misconfiguration-DOS, but almost no good."
• Nicholas Weaver
  "If I was Comcast, after the HBO DNSSEC mess-up, on top of previous mess-ups where Comcast inevitably gets the blame, I'd be really really tempted to turn OFF DNSSEC validation. It has failed."
• Chris Palmer at TrustyCon 2014
  "DNSSEC doesn't seem to be coming. I'm not a believer in it. I don't think that that's where security belongs."
• Alex Stamos: AppSec California 2015 (Opening Keynote)
  "DNSSEC is dead. It's over. I'm just telling you now it's over. Don't put any of your future stock on DANE or any security solutions that are based on DNSSEC. It's done."
• What Happened During Slack's DNSSEC Rollout
  "The incident on September 30th 2021 was the third unsuccessful attempt to enable DNSSEC on slack.com."
• Thomas H. Ptacek: One of the downsides of deploying DNSSEC
  "[DNSSEC] sucks up all the oxygen from the effort to actually mitigate flaws in the DNS. The most important DNS security flaw is the last-mile problem between browsers and nameservers, and DNSSEC has practically nothing to say about that. DNSCurve, as a counterexample, does solve this problem, and it solves it regardless of whether 1 person deploys it or 300 million do. But all the oxygen has been stolen by DNSSEC."

DNSSEC Failure Modes

• [1455504478] unbound[10562:0] info: validation failure <geekpac.com. A IN> no keys have a DS with algorithm DSA from 216.218.132.2 for key geekpac.com. while building chain of trust
• [1461807469] unbound[9788:0] info: validation failure <slim-shirt.com. A IN>: no keys have a DS with algorithm DSA-NSEC3-SHA1 from 149.210.161.148 for key slim-shirt.com. while building chain of trust
• [1416399790] unbound[6665:0] info: validation failure <www.root-dnssec.org. A IN>: no keys have a DS with algorithm RSASHA1 from 199.43.133.53 for key root-dnssec.org. while building chain of trust
• [1542917246] unbound[86384:0] info: validation failure <texas.gov. A IN>: no keys have a DS with algorithm RSASHA1-NSEC3-SHA1 from 168.39.1.19 for key texas.gov. while building chain of trust
• [1453856818] unbound[24687:0] info: validation failure <doosan. A IN>: no signatures with algorithm RSASHA1-NSEC3-SHA1 for <doosan. SOA IN> from 43.230.51.10
• [1449706352] unbound[14699:0] info: validation failure <mil. NS IN>: no keys have a DS with algorithm RSASHA256 from 199.252.180.234 for key mil. while building chain of trust
• [1438497104] unbound[13570:0] info: validation failure <psa.gov. A IN>: no signatures with algorithm RSASHA512 from 152.180.7.14
• [1455505802] unbound[10562:0] info: validation failure <istilllovecalligraphy.com. A IN>: no keys have a DS with algorithm ECDSAP256SHA256 from 173.245.59.126 for key istilllovecalligraphy.com. while building chain of trust
• [1455501075] unbound[10562:0] info: validation failure <cavatech.com. A IN>: no keys have a DS with algorithm ECDSAP384SHA384 from 178.62.34.37 for key cavatech.com. while building chain of trust
• [1532015786] unbound[52909:0] info: validation failure <www.bsws.de. A IN>: signer name mismatches key name from 80.86.183.57 for DS www.bsws.de. while building chain of trust
• [1384202561] unbound[15653:0] info: validation failure <treasuryscams.gov. SOA IN>: signature crypto failed from 164.95.95.155
• [1453749094] unbound[11879:0] info: validation failure <dnscrypt.is. A IN>: signature crypto failed from 93.95.226.52 for key dnscrypt.is. while building chain of trust
• [1386464793] unbound[28462:0] info: validation failure <truman.edu. CNAME IN>: signature crypto failed for <truman.edu. SOA IN> from 150.243.160.14
• [1472402498] unbound[4888:0] info: validation failure <3vyblmyltdpest2g.minecraftstation.com. A IN>: signature crypto failed for CNAME from 209.112.114.33 and 216.87.155.33
• [1454604276] unbound[27993:0] info: validation failure <dnscrypt.org. A IN>: use of signature for ECDSA crypto failed from 78.194.219.1
• [1437688590] unbound[2186:0] info: validation failure <empowhr.gov. A IN>: no signatures from 199.141.107.68
• [1472397145] unbound[4888:0] info: validation failure <cyj3z6ipngdgyfmk.devblades.com. A IN>: no signatures from 176.31.164.60 for DS cyj3z6ipngdgyfmk.devblades.com. while building chain of trust
• [1444137310] unbound[7562:0] info: validation failure <hr. NS IN>: no signatures from 204.61.216.90 for key hr. while building chain of trust
• [1542974241] unbound[86384:0] info: validation failure <by. NS IN>: No DNSKEY record from 195.209.35.70 for key by. while building chain of trust
• [1397619663] unbound[17827:0] info: validation failure <northencolarodouniversity.edu. NS IN>: No DNSKEY record for key edu. while building chain of trust
• [1397619667] unbound[17827:0] info: validation failure <columbia.edu. NS IN>: key for validation edu. is marked as invalid because of a previous validation failure <northencolarodouniversity.edu. NS IN>: No DNSKEY record for key edu. while building chain of trust
• [1472427969] unbound[26969:0] info: validation failure <wruluroamgvl66uk.dns007.net. SOA IN>: no NSEC3 records from 208.43.71.243 for DS wruluroamgvl66uk.dns007.net. while building chain of trust
• [1384529866] unbound[8790:0] info: validation failure <249.10.196.in-addr.arpa. SOA IN>: no DNSSEC records from 196.216.168.10 for DS 249.10.196.in-addr.arpa. while building chain of trust
• [1385234162] unbound[16342:0] info: validation failure <nonprofit.gov. SOA IN>: signature missing from 159.142.90.245 for key nonprofit.gov. while building chain of trust
• [1483281345] unbound[60595:0] info: validation failure <www.opendnssec.org. A IN>: no signatures over NSECs from 91.123.201.115 for DS www.opendnssec.org. while building chain of trust
• [1385360828] unbound[1786:0] info: validation failure <qsdmflkjazermlzkaerj.ready.gov. A IN>: no signatures over NSEC3s from 95.100.173.64 for DS qsdmflkjazermlzkaerj.ready.gov. while building chain of trust
• [1450185083] unbound[8849:0] info: validation failure <com.vu. NS IN>: no NSEC3 closest encloser from 202.80.32.5 for DS com.vu. while building chain of trust
• [1455528699] unbound[8090:0] info: validation failure <dnssec.ancientartofwar.com. A IN>: wildcard proof failed from 77.95.248.106
• [1634261616] unbound[85985:0] info: validation failure <com.lv. NS IN>: nameerror proof failed from 194.0.1.24 and 194.0.8.1 and 194.146.106.150 and 77.72.229.249 and 192.36.125.2 and 192.36.125.2 and 194.0.8.1 and 192.36.125.2 and 194.0.48.1 and 194.0.48.1 and 194.0.48.1 and 194.0.48.1
• [1387237001] unbound[10213:0] info: validation failure <12.56.100.62.in-addr.arpa. PTR IN>: cnamenoanswer proof failed from 83.219.82.2 and 212.67.179.100
• [1400736520] unbound[4009:0] info: validation failure <eia.gov. RRSIG IN>: nodata proof failed from 199.36.140.199
• [1390966241] unbound[6793:0] info: validation failure <uofk.edu. NS IN>: DS hash mismatches key from 41.67.20.4 for key uofk.edu. while building chain of trust
• [1511220820] unbound[52556:0] info: validation failure <www.nasa.gov. A IN>: DS got unsigned CNAME answer from 69.28.143.13 and 205.251.193.107 and 198.116.4.181 for DS www.nasa.gov. while building chain of trust
• [1397841324] unbound[6604:0] info: validation failure <miwizbrgfcrw.xn--kprw13d. CNAME IN>: DS got DNAME answer from 163.28.1.10 and 202.12.31.141 for DS miwizbrgfcrw.xn--kprw13d. while building chain of trust
• [1399701822] unbound[23307:0] info: validation failure <ucdavis.edu. TXT IN>: signature labelcount out of range from 128.120.252.10
• [1405129714] unbound[32474:0] info: validation failure <viagrakopen.net. NS IN>: DNSKEY RRset did not match DS RRset by name from 93.180.70.53 and 46.18.33.23 for key viagrakopen.net. while building chain of trust
• [1455448756] unbound[23444:0] info: validation failure <distns.com. A IN>: signer name off-tree from 67.228.254.4 for key distns.com. while building chain of trust
• [1406058604] unbound[19938:0] info: validation failure <dnssec.tz. A IN>: no NSEC3 records from 204.61.216.15 for DS dnssec.tz. while building chain of trust
• [1406134936] unbound[6020:0] info: validation failure <dnssec.sx. NS IN>: covering NSEC3 was not opt-out in an opt-out DS NOERROR/NODATA case from 192.95.19.109 for DS dnssec.sx. while building chain of trust
• [1449691919] unbound[25266:0] info: validation failure <www.army.mil. A IN>: SERVFAIL no DS for DS army.mil. while building chain of trust
• [1472228398] unbound[12736:0] info: validation failure <frictionmediastudio.com. A IN>: signature before inception date from 208.109.255.53
• [1408991746] unbound[18905:0] info: validation failure <dnssec-or-not.com. A IN>: signature before inception date from 72.13.58.76 for key dnssec-or-not.com. while building chain of trust
• [1452235796] unbound[24652:0] info: validation failure <rio. A IN>: signature before inception date for <rio. SOA IN> from 200.160.0.10
• [1463491856] unbound[27503:0] info: validation failure <libsodium.org. A IN>: signature inception after expiration from 78.194.219.1 for key libsodium.org. while building chain of trust
• [1453789909] unbound[8745:0] info: validation failure <mm. A IN>: signature expired for <mm. SOA IN> from 193.0.9.96
• [1449381830] unbound[12731:0] info: validation failure <gov.zm. NS IN>: signature expired from 196.216.168.44 for DS gov.zm. while building chain of trust
• [1451030757] unbound[13897:0] info: validation failure <bw. NS IN>: signature expired from 168.167.168.37 for key bw. while building chain of trust
• [1409072486] unbound[11089:0] info: validation failure <dnssec-name-and-shame.com. A IN>: signature expired from 192.16.197.229
• [1409095284] unbound[22110:0] info: validation failure <www.dnssec-name-and-shame.com. A IN>: signature expired for CNAME from 192.16.197.229 and 192.16.197.229
• [1472367633] unbound[4888:0] info: validation failure <7gpdgz5nlfg7t62b.kruijeradvies.com. A IN>: CNAME in DS response was not secure. signatures from unknown keys from 94.247.75.5 and 94.247.75.5 for DS 7gpdgz5nlfg7t62b.kruijeradvies.com. while building chain of trust
• [1449698941] unbound[25266:0] info: validation failure <marines.mil. A IN>: signatures from unknown keys from 199.252.155.234 for DS marines.mil. while building chain of trust
• [1462284322] unbound[19535:0] info: validation failure <www.xfinity.com. A IN>: signatures from unknown keys for CNAME from 23.7.245.92 and 23.61.199.64 and 68.87.76.228
• [1711807616] unbound[70463:0] info: validation failure <google.com.sg. A IN>: not all NSEC3 records secure from 185.159.198.170 for DS google.com.sg. while building chain of trust
• [1443535423] unbound[26688:0] info: validation failure <comcast.com. A IN>: signatures from unknown keys from 69.252.250.103
• [1512057305] unbound[6823:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset . DNSKEY IN
• [1512057305] unbound[6823:0] info: validation failure <wssp.nic.cl. A IN>: no DNSKEY rrset for trust anchor . while building chain of trust
• [1512057309] unbound[6823:0] info: validation failure <64.in-addr.arpa. NS IN>: key for validation . is marked as invalid because of a previous validation failure <wssp.nic.cl. A IN>: no DNSKEY rrset for trust anchor . while building chain of trust

What a mess

DNSSEC is not encrypted, which is responsible for many of its failures. Rather than doing per-message/packet encryption like other secure protocols, DNSSEC was made compatable with censorship and surveillance. To enable censorship and surveillance, an extremely complex and thus fragile protocol was required, thereby resulting in outages, semi-outages, and sometimes just plain bizarre situations. Here are some examples:

• 19KB DNS responses: On April 11, 2014 (when I ran a little test), doc.gov was serving 19KB answers to ANY queries. Is this as good as it gets or as bad as it gets?
• 3642-day old expired RRSIGs: How does this even happen? Runner-up: 3578 days. Apparently this is a thing.
• 13 months to fix a problem. Proceed with caution when reading DNSSEC in Windows Server 2012 signature refresh on secondary.
• DNSSEC or DDoS? Sometimes the answer isn't obvious.
• Conscious participation in DDoS: Read this whole thread, as it captures several failures of DNSSEC in one go.
• 2.5 years to diagnose and fix a DNSSEC problem: Nobody knows what's going on.
• All queries forced over TCP due to large NSEC response sizes and RRL. RRL is only necessary for DNSSEC users.
• DNSSEC advocates want to change TCP to accommodate deficiencies in DNSSEC.
• 20% memory lost to NSEC3: a result of a poorly designed protocol. Imagine if HTTPS consumed 20% more memory for 404s — and DNSSEC isn't even encrypted!
• Overlapping DNSSEC outages: It warms my heart to see a parent domain create an unrelated 35-hour+ DNSSEC outage to join the child domain's ongoing 31-day DNSSEC outage... just so it doesn't feel alone. It gets me right here!! *sniff* — And again only 2 weeks later!
• Overlooking some DNSSEC outages because they're so frequent: By default, Unbound ignores for up to 24 hours any DNSSEC failure resulting from expired RRSIGs.
• Reduced TTLs to limit expected DNSSEC downtime. Why use a technology that is so prone to failure at all?

Hall of Fame DNSSEC Outages

• ~8.5 million .uk domains went down with .uk in September 2010.
• 7381 autonomous systems: The massive APNIC outage in March 2016 broke DNSSEC service for a breathtaking 48 in-addr.arpa domains.
• 28 separate DNSSEC outages per year: usfj.mil put up an almost unbeatable number of outages in 2015 2016. This figure will be tough really tough to beat.
• 4.5 years: what an incredible run for validatorsearch.verisignlabs.com! This is the cream of the crop.