.xn--mgbai9azgqp6j TLD DNSSEC Outage:
2017-06-08 - 2017-07-27
Updated: July 31, 2017
Overview
This page gives some details on the .xn--mgbai9azgqp6j (Pakistan IDN) TLD DNSSEC outage that began June 8, 2017, and ended July 27, 2017. It lasted 49 days.
Timeline / DNSViz
- 2017-06-08 03:40:52 UTC — RRSIGs expire
- 2017-06-08 03:41:20 UTC — Expired RRSIGs
- 2017-06-08 06:27:01 UTC — Expired RRSIGs
- 2017-06-18 20:01:13 UTC — Expired RRSIGs
- 2017-06-28 20:01:04 UTC — Expired RRSIGs
- 2017-07-08 20:00:42 UTC — Expired RRSIGs
- 2017-07-18 20:00:40 UTC — Expired RRSIGs
- 2017-07-27 08:01:11 UTC — Expired RRSIGs
- 2017-07-27 14:01:25 UTC — DNSSEC outage over
DNSSEC Debugger
Unlike DNSViz, Verisign's DNSSEC Debugger doesn't archive results, so here's a screenshot of my web browser's output from June 8, 2017:
Zonemaster
- zonemaster.net archived "Delegation from parent to child is not properly signed (signature: DNSSEC signature has expired)."
OpenDNS vs. Google Public DNS
OpenDNS does not support DNSSEC, and instead supports DNSCurve. Google Public DNS currently supports only DNSSEC, and thus, Google's users saw SERVFAIL for queries under marines.mil during this outage.
With OpenDNS, without DNSSEC, queries succeed:
$ dig ns xn--mgbai9azgqp6j. @resolver1.opendns.com.
; <<>> DiG 9.4.2-P2 <<>> ns xn--mgbai9azgqp6j. @resolver1.opendns.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47943
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--mgbai9azgqp6j. IN NS
;; ANSWER SECTION:
xn--mgbai9azgqp6j. 172800 IN NS ns.ntc.net.pk.
xn--mgbai9azgqp6j. 172800 IN NS ns1.ntc.net.pk.
xn--mgbai9azgqp6j. 172800 IN NS ns2.ntc.net.pk.
;; Query time: 0 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Jun 8 06:25:09 2017
;; MSG SIZE rcvd: 98
With Google Public DNS, because of DNSSEC, queries fail:
$ dig +dnssec ns xn--mgbai9azgqp6j. @8.8.8.8
; <<>> DiG 9.4.2-P2 <<>> +dnssec ns xn--mgbai9azgqp6j. @8.8.8.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19389
;; 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: 608 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jun 8 06:25:09 2017
;; MSG SIZE rcvd: 46
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):
;; Domain: xn--mgbai9azgqp6j.
[B] xn--mgbai9azgqp6j. 86400 IN DNSKEY 256 3 7 ;{id = 40937 (zsk), size = 2048b}
xn--mgbai9azgqp6j. 86400 IN DNSKEY 257 3 7 ;{id = 21720 (ksk), size = 4096b}
[B] Error verifying denial of existence for xn--mgbai9azgqp6j. type A: No keys with the keytag and algorithm from the RRSIG found
;;[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
- [1496893357] unbound[74310:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: signature expired from 202.83.164.166 for key xn--mgbai9azgqp6j. while building chain of trust
- [1496927804] unbound[74310:0] info: validation failure <xn--mgbai9azgqp6j. NS IN>: signature expired from 175.107.192.11 for key xn--mgbai9azgqp6j. while building chain of trust