Description

yunruiwatts

opened on Mar 17, 2026

Issue body actions

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

1. ibauersachs commented on Mar 18, 2026

   

   ibauersachs

   on Mar 18, 2026

   Member

   More actions

   Hi, I've run these queries and so far I'm not sure I understand the issue.

   • I've never heard of "dynamic SOA" or a zone that can live without a SOA. Do you possibly refer to multi-label names in a zone? E.g. host.uat in zone example.com, where the uat label is not a delegation?
   • I cannot properly test *.devices.meraki.direct without an actual example to substitute the wildcard
   • aping-ideal-uat.dbs.com is correctly signed, but the target aping-ideal-uat.wlbuat.dnssecdbs.com is unsigned. Thus the entire result is insecure:
     • aping-ideal-uat.wlbuat.dnssecdbs.com -> validate.insecure_unsigned
     • aping-ideal-uat.dbs.com -> validate.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.
2. yunruiwatts commented on Mar 18, 2026

   

   yunruiwatts

   on Mar 18, 2026

   Author

   More actions

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

   Extended_DNS_Error: NSEC_MISSING: NODATA response failed to prove NODATA status with NSEC/NSEC3
   

   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.
3. yunruiwatts

   changed the title [-]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.[/+] on Mar 25, 2026
4. ibauersachs commented on Apr 12, 2026

   

   ibauersachs

   on Apr 12, 2026

   Member

   More actions

   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.
5. ibauersachs

   self-assigned this

   on Apr 12, 2026
6. ibauersachs

   added

   bug

   on Apr 12, 2026
7. ibauersachs

   added the

   Bug

   issue type on Apr 12, 2026

Issue actions