@petercooperjr is correct. The non-existence records on subdomains of saintjoisd.net are all broken. I had a look at this yesterday, but a short skim didn't see a huge issue. While I have no idea what's (sometimes) broken with DnsViz , the error messages are clear + reproduceable for me.
With DNSSEC, nameservers have to proof that a given record does not exist. Otherwise anyone could just truncate or convert responses into NXDOMAIN, which is a problem (it could be used to disable DNSSEC entirely). DNSSEC uses either NSEC or NSEC3 for this. Both have a slight disadvantage, as they allow zone enumeration (getting all records a given zone has), but its a bit more difficult to do so with NSEC3.
The domain in question here uses NSEC (which is actually easier to debug in cases like this), but the signing on subdomains is broken. While queries to saintjoisd.net all result in correct answers, any query to a subdomain with a type that does not exist results in a broken NSEC record.
As an example (this applies to any subdomain due to wildcards, see below):
For a given query
dig CAA www.saintjoisd.net, the nameserver claims (via NSEC) that the entire subdomain does not exist (i.e. there is no
saintjoisd.net), yet the response is a
NOERROR one (with empty answer section, i.e. no matching records). If the entire subdomain was non-existing the response should have been
NXDOMAIN instead. Actually, if we do a query
dig A www.saintjoisd.net we can actually get a non-empty A response (with correct RRSIG), so the subdomain does actually exist. This is not stated by the nameserver though, resulting in a broken NSEC record and hence failing DNSSEC validation.
This issue happens with all record types that don't exist (i.e.
SSHFP...) all result in this exact same error. It is not limited to CAA records, it applies to all non-existence proofs.
A few things I discovered while testing:
- The zone appears to be live signed, i.e. DNSSEC records are generated on the fly. This is a bit unusual, but not a problem in itself.
- The zone uses a wildcard, i.e.
dig A anysubodmain.saintjoisd.net resolves to the same IP address (www." also appears to be a part of the wildcard). The existence RRsigs are correctly signed here, unlike the NSEC for the same subdomain. This wildcard is a probable cause for the nameserver trouble, as the nameserver does not properly disclose it. With NSEC, wildcards have to be disclosed in the NSEC response*, otherwise the resolver can't possibly validate it. The nameserver here does not disclose the wildcard at all, instead pretending that no subdomains exist.
My suggestion to @TeQuilYa would be to speak with their DNS provider and see if they can fix the DNSSEC issue. If they are unable to do so, you have some more options:
- Disable DNSSEC entirely (weakens security, but resolves the issue)
- Try to check if the issue also appears without the wildcard. The NSEC issue might disappear, but its not guaranteed - there might be more dragons in the shadows.
- Adding a CAA record will result in a non-empty response with RRSIG, also working around the broken NSEC response. This does not fix your other record types (AAAA for example) though, so I wouldn't recommend it.
Some more trivia: Cloudflare, which supports Extended DNSSEC errors, also complains about the NSEC records on subdomains:
# dig AAAA www.saintjoisd.net +dnssec @220.127.116.11
; <<>> DiG 9.16.33-Debian <<>> AAAA www.saintjoisd.net +dnssec @18.104.22.168
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6991
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 6 (DNSSEC Bogus): (proof of non-existence of www.saintjoisd.net. AAAA)
;; QUESTION SECTION:
;www.saintjoisd.net. IN AAAA
*As the zone uses live signing, it could also theoretically get away with not disclosing the wildcard (instead generating NSEC records on the fly), but at the very least it has to properly generate the NSEC records.