.kg TLD DNSSEC Outage: 2022-08-23 to 2022-08-24
Date: August 24, 2022
Overview
This page gives some details on the kg (Kyrgyzstan) TLD DNSSEC outage from August 23 to August 24, 2022.
Timeline / DNSViz
- 2022-08-23 17:47:55 UTC — Bogus DNSSEC delegation
- 2022-08-23 19:02:03 UTC — Bogus DNSSEC delegation
- 2022-08-23 20:02:22 UTC — Bogus DNSSEC delegation
- 2022-08-24 01:02:29 UTC — Bogus DNSSEC delegation
- 2022-08-24 03:47:56 UTC — last personally observed kg DNSSEC failure
Verisign's DNSSEC Debugger
Here's a screenshot I took on August 23, 2022, of the DNSSEC Debugger output:
And here's a snapshot courtesy of archive.ph.
Google Public 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, DNS queries result in SERVFAIL:
$ dig +dnssec ns kg. @8.8.8.8
; <<>> dig 9.10.8-P1 <<>> +dnssec ns kg. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33793
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;kg. IN NS
;; Query time: 148 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 23 18:34:01 UTC 2022
;; MSG SIZE rcvd: 31
You have to disable DNSSEC to make DNS queries work:
$ dig +nodnssec ns kg. @8.8.8.8
; <<>> dig 9.10.8-P1 <<>> +nodnssec ns kg. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45519
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kg. IN NS
;; ANSWER SECTION:
kg. 21600 IN NS NS2.kg.
kg. 21600 IN NS KG.CCTLD.AUTHDNS.RIPE.NET.
kg. 21600 IN NS NS.kg.
;; Query time: 141 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Aug 23 18:34:05 UTC 2022
;; MSG SIZE rcvd: 105
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):
[T] kg. 86400 IN DS 45982 8 2 d642af8c9bb761e035ce77a48750bbaa64b41cfa0799d8d94498cfa335fa1380
;; Domain: kg.
;; Signature ok but no chain to a trusted key or ds record
[S] kg. 1800 IN DNSKEY 257 3 5 ;{id = 49954 (ksk), size = 1024b}
kg. 1800 IN DNSKEY 256 3 5 ;{id = 49950 (zsk), size = 1024b}
[S] Existence denied: kg. A
;;[S] self sig OK; [B] bogus; [T] trusted; [U] unsigned
dns.google.com
Here's a screenshot from dns.google.com during this DNSSEC outage:
And here's an archive.ph snapshot showing the same.
Logfile examples
The below log entries come from 2 different Unbound instances running on different servers running different operating systems in different geographic locations.
- [1661275353] unbound[469:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 193.0.9.84 for key kg. while building chain of trust
- [1661275450] unbound[469:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 195.38.160.38 for key kg. while building chain of trust
- [1661276060] unbound[469:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 193.0.9.84 for key kg. while building chain of trust
- [1661277171] unbound[99237:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 195.38.160.38 for key kg. while building chain of trust
- [1661277463] unbound[99237:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 193.0.9.84 for key kg. while building chain of trust
- [1661312604] unbound[99237:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 193.0.9.84 for key kg. while building chain of trust
- [1661312876] unbound[99237:0] info: validation failure <kg. NS IN>: no keys have a DS with algorithm RSASHA256 from 195.38.160.36 for key kg. while building chain of trust