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.