Earlier, i scanned the full TLD list to see if any more of them didn’t support
CAA, similar to the situation with
.sr. (Doing roughly
"dig cOm caa" and so forth.) There were no other broken TLDs.
Now i’ve done the same thing with the entire Public Suffix List.
For the Public Suffix List, i removed
!example.com entries and treated
Limitations: I checked from one location, repeatedly, over a short period of time. I didn’t check for issues with subdomains.
With that excessive introduction, i found two public suffixes with
mil.no is, yes, the Norwegian military. They have less than 20 non-expired certificates in CT, from several CAs, none of which are Let’s Encrypt. (crt.sh)
I found 37 other public suffixes that were broken for
NS, suggesting wider and irrelevant problems. (DNSSEC, 0x20, routing issues, etc.) I’ll paste that list at the bottom. I didn’t check if any of them are in use.
So… except for
.sr, which we already knew about, probably not bad.
$ dig +short mil.no ns
$ dig +norecurse mil.no caa @ns5.eonisp.net.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse mil.no caa @ns5.eonisp.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54228
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mil.no. IN CAA
;; Query time: 111 msec
;; SERVER: 188.8.131.52#53(184.108.40.206)
;; WHEN: Wed Aug 09 08:59:04 UTC 2017
;; MSG SIZE rcvd: 24
Yep, authoritative nameservers return
version.bind returns an invalid (class
IN) but informative response of “
Served by POWERDNS 2.9.22 $Id: packethandler.cc 1321 2008-12-06 19:44:36Z ahu $” and i hope i don’t get arrested by NATO…