.mg TLD DNSSEC Outage: 2019-08-02 - 2019-08-04

Date: August 4, 2019

Overview

This page gives some details on the .mg (Madagascar) TLD DNSSEC outage from August 2 to August 4, 2019. This is at least the 31st DNSSEC outage for Madagascar.

Timeline / DNSViz

(At the time of this writing, DNSViz historical archives have been down for months. DNSSEC makes its users think downtime doesn't matter.)

2019-08-02 19:06:49 UTC — first personally observed .mg DNSSEC failure, "No DNSKEY record"
2019-08-04 09:04:15 UTC — last personally observed .mg DNSSEC failure, "no signatures"

Here is a screenshot of the relevant portion of this DNSSEC outage:

August 3, 2019 .mg TLD DNSSEC outage in DNSViz

Here is a mirror which shows the outage in DNSViz, courtesy of archive.is.

DNSSEC Debugger

Verisign's DNSSEC Debugger doesn't archive results, so here's a screenshot of my web browser's output from August 3, 2019:

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):

mg. 86400 IN DS 64652 5 2 f55dcb5946c539f71b13fa83491864f672fc65589b313fc99dd65e4f14f8a8b3
;; Domain: mg.
;; No DNSKEY record found for mg.
[U] No data found for: mg. type A
;;[S] self sig OK; [B] bogus; [T] trusted

Zonemaster

zonemaster.iis.se archived "Inga DNSKEY-poster returnerades." Here is an archive.is copy.
zonemaster.labs.nic.cz doesn't allow checking of TLDs. I think DNSSEC promoters want to hide DNSSEC's failures as much as possible.

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.

$ dig +dnssec ns mg. @8.8.8.8

; <<>> DiG 9.4.2-P2 <<>> +dnssec ns mg. @8.8.8.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38066
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;mg. IN NS

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 2 19:06:50 2019
;; MSG SIZE rcvd: 31

You have to disable DNSSEC to make DNS queries work:

$ dig +cd ns mg. @8.8.8.8

; <<>> DiG 9.4.2-P2 <<>> +cd ns mg. @8.8.8.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55250
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mg. IN NS

;; ANSWER SECTION:
mg. 7199 IN NS ns.dts.mg.
mg. 7199 IN NS ns.nic.mg.
mg. 7199 IN NS ns-mg.malagasy.com.
mg. 7199 IN NS pch.nic.mg.
mg. 7199 IN NS censvrns0001.ird.fr.

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Aug 2 19:06:50 2019
;; MSG SIZE rcvd: 145

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 mg:

This data is also saved by archive.org.

Logfile examples

These Unbound log entries come from different Unbound instances, each on different servers in different geographical regions.

[1564772809] unbound[93227:0] info: validation failure <mg. NS IN>: No DNSKEY record from 91.203.32.147 for key mg. while building chain of trust
[1564777170] unbound[177:0] info: validation failure <mg. NS IN>: No DNSKEY record from 196.192.32.2 for key mg. while building chain of trust
[1564794814] unbound[177:0] info: validation failure <mg. NS IN>: No DNSKEY record from 196.192.42.153 for key mg. while building chain of trust
[1564908749] unbound[93227:0] info: validation failure <mg. NS IN>: No DNSKEY record from 204.61.216.121 for key mg. while building chain of trust
[1564909237] unbound[93227:0] info: validation failure <mg. NS IN>: no signatures from 87.98.132.231
[1564909455] unbound[93227:0] info: validation failure <mg. NS IN>: no signatures from 204.61.216.121