Repository navigation
ValidatingResolver is unable to handle zones that don't provide SOA records. #402
Description
I've been using the ValidatingResolver to perform DNSSEC validation, and I've run into a few scenarios where it finds certain domains invalid even though other DNSSEC tools report them as fine. The common denominator that I've found is that they do not provide SOA records.
Some examples of this are:
-
*.devices.meraki.direct
- When the ValidatingResolver attempts to validating this domain it fails to detect that the DNSSEC chain of trust ends at meraki.direct. It appears to not even start the DNSSEC validation as it fails to even try to look up the root DNSKEY records (where it normally starts).
-
aping-ideal-uat.dbs.com
- This domain has a signed CNAME to aping-ideal-uat.wlbuat.dnssecdbs.com. The ValidatingResolver is able to successfully validate the DNSSEC chain of trust from root to the CNAME at aping-ideal-uat.dbs.com, and then fails to proceed to validate aping-ideal-uat.wlbuat.dnssecdbs.com. If you send aping-ideal-uat.wlbuat.dnssecdbs.com to the ValidatingResolver, it behaves in the same way as for the above meraki.direct subdomains.
In both cases, the ValidatingResolver should be able to verify that the chain of trust has ended appropriately with NSEC/NSEC3 records and return a successful response. I'd be happy to help code or review a change to fix this, but currently my experience with the codebase is limited to using the library and using a debugger to figure out why these cases weren't working.
Activity
ibauersachs commentedon Mar 18, 2026
Hi, I've run these queries and so far I'm not sure I understand the issue.
host.uatin zoneexample.com, where theuatlabel is not a delegation?*.devices.meraki.directwithout an actual example to substitute the wildcardaping-ideal-uat.wlbuat.dnssecdbs.comis unsigned. Thus the entire result is insecure:Both domains show the same results as dnsjava when I enter them in dnsviz.net (and additionally other warnings)
dnssecdbs.com is particularly weird: it has a DNSKEY, but apparently no corresponding DS in the .com zone, and it has an NSEC3 that proves that wlbuat.dnssecdbs.com doesn't exist. But this doesn't really matter without the missing DS. Even adding the custom DNSKEY of dnssecdbs.com doesn't help as wlbuat.dnssecdbs.com is still an insecure delegation.
Thanks for the offer to help with a PR. We first need to understand the underlying issue though and see actually different results in dnsviz.
yunruiwatts commentedon Mar 18, 2026
@ibauersachs for *.devices.meraki.direct, anything I've tried gets the error - abc.devices.meraki.direct, foobar.devices.meraki.direct, etc. In each case the ValidatingResolver is responding with a SERVFAIL that includes the following error:
I get a similar SERVFAIL when I try to do a lookup on aping-ideal-uat.dbs.com. Looks like I did forget to mention that you have to request a record type that the domain doesn't have. In these two cases a TXT record lookup will do.
As for why they don't return SOA records, I don't understand their setup myself, but someone I was talking to about this was saying that it was likely some kind of dynamic setup with the DNS server figuring things out on the fly.
[-]ValidatingResolver is unable to handle dynamic zones that don't provide SOA records.[/-][+]ValidatingResolver is unable to handle zones that don't provide SOA records.[/+]ibauersachs commentedon Apr 12, 2026
I've investigated a bit and the domains are valid, apart from the stuff that dnsviz.net highlights. It's not an easy fix, so it'll take a while to get that properly fixed.