.xn--mgbai9azgqp6j TLD DNSSEC Outage:
2020-08-18 to 2020-08-25
Updated: August 27, 2020
Overview
This page gives some details on the .xn--mgbai9azgqp6j (Pakistan IDN) TLD DNSSEC outage that began August 18, 2020, and ended August 25, 2020. It lasted a week. It wasn't this TLD's first long DNSSEC outage — the previous one lasted 49 days!
Timeline / DNSViz
- 2020-08-18 10:40:24 UTC — first personally observed DNSSEC failure
- 2020-08-19 03:33:31 UTC — No RRSIGs
- 2020-08-19 15:52:31 UTC — last personally observed DNSSEC failure
Since DNSViz regularly loses its archives, there are copies of the output at web.archive.org and archive.is.
DNSSEC Debugger
Unlike DNSViz, Verisign's DNSSEC Debugger doesn't archive results, so here's a screenshot of my web browser's output from August 19, 2020:
Thanks to archive.is, here's a copy of the output.
Zonemaster
- zonemaster.iis.se archived this DNSSEC outage.
- zonemaster.net archived this DNSSEC outage.
Google DNS: with and without DNSSEC
DNSSEC can be disabled in queries via the CD (checking disabled) bit. Let's compare DNS queries with and without DNSSEC. With DNSSEC enabled, DNS fails:
$ dig +dnssec ns xn--mgbai9azgqp6j. @8.8.8.8
; <<>> dig 9.10.8-P1 <<>> +dnssec ns xn--mgbai9azgqp6j. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46003
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;xn--mgbai9azgqp6j. IN NS
;; Query time: 1296 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 18 10:40:27 UTC 2020
;; MSG SIZE rcvd: 46
You have to disable DNSSEC to make DNS queries work:
$ dig +cd ns xn--mgbai9azgqp6j. @8.8.8.8
; <<>> dig 9.10.8-P1 <<>> +cd ns xn--mgbai9azgqp6j. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30160
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;xn--mgbai9azgqp6j. IN NS
;; ANSWER SECTION:
xn--mgbai9azgqp6j. 21599 IN NS ns1.ntc.net.pk.
xn--mgbai9azgqp6j. 21599 IN NS ns2.ntc.net.pk.
xn--mgbai9azgqp6j. 21599 IN NS ns.ntc.net.pk.
;; Query time: 3438 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 18 10:40:31 UTC 2020
;; MSG SIZE rcvd: 109
drill trace
Since DNSSEC contains so much garbage, I put the complete drill trace into its own file, with the relevant portion below (emphasis added):
xn--mgbai9azgqp6j. 86400 IN DS 21720 7 2 bb7d853dfdfd7a39574ce1b5d3009e5c813264e614430c1b29c894c090393dd1
;; Domain: xn--mgbai9azgqp6j.
;; No DNSKEY record found for xn--mgbai9azgqp6j.
[U] No data found for: xn--mgbai9azgqp6j. type A
;;[S] self sig OK; [B] bogus; [T] trusted
dns.google.com
dns.google.com is related to but separate from Google Public DNS. During this DNSSEC outage, dns.google.com showed the following for xn--mgbai9azgqp6j:
Logfile examples
- [1597747224] unbound[9393:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: No DNSKEY record from 202.83.164.166 for key xn--mgbai9azgqp6j. while building chain of trust
- [1597961879] unbound[237:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: No DNSKEY record from 202.83.164.166 for key xn--mgbai9azgqp6j. while building chain of trust
- [1597855651] unbound[237:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: No DNSKEY record from 202.83.164.166 for key xn--mgbai9azgqp6j. while building chain of trust
- [1598370751] unbound[9393:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: No DNSKEY record from 202.83.164.166 for key xn--mgbai9azgqp6j. while building chain of trust