A solo developer operating VantageDNS, a recursive DNS resolver with content filtering, discovered that DNSSEC validation had been completely disabled for six months. The issue came to light only after running the public DNS-OARC test suite, not through any internal monitoring alerts.
External Test Reveals Critical Gap
The DNS-OARC cmdns test sends dozens of queries with randomized names and checks port randomization, DNS ID entropy, TCP support, IPv6, QNAME minimization, and DNSSEC behavior. Five checks passed with green results, but one line appeared in red: "Lookup succeeded while signature was invalid." Manual verification with dig against dnssec-failed.org confirmed the resolver returned NOERROR and a valid answer instead of the required SERVFAIL status.
Why Passive Monitoring Failed
Existing health checks, latency metrics, and cache-hit-rate alerts could not detect the missing validation. When DNSSEC checking is disabled, the resolver answers faster, returns more successful responses, and appears completely healthy. The only reliable detection method is an active probe that deliberately supplies an invalid signature and verifies rejection.
Configuration History and Technical Debt
The cause was a comment left in the Unbound configuration during the MVP stage:
- DNSSEC validation — disabled in MVP, add in Sprint 5
- Requires auto-trust-anchor-file + root.key, which is absent by default
Subsequent sprints passed without addressing the item. A separate Go-based DNSSEC validator existed but was bypassed because production recursion was handled by an Unbound sidecar that forwarded traffic without validation.
Enabling Validation and Crash-Loop
Initial attempts to enable validation using auto-trust-anchor-file caused a permission-denied error inside the chroot environment because Unbound (running as _unbound) needed write access to the directory to perform RFC 5011 key-rollover updates. The container entered a crash-loop until the configuration was switched to a static trust-anchor-file pointing to a pre-generated root.key.
Verification Steps and Performance Impact
After the change, the operator established a repeatable verification checklist:
- dnssec-failed.org and sigfail.verteiltesysteme.net must consistently return SERVFAIL
- Signed domains must return the ad (authenticated data) flag
- Popular domains must resolve identically to results from 1.1.1.1 and 8.8.8.8
Latency measurements showed no measurable penalty: cold-cache queries to signed zones averaged 24 ms versus 28 ms for unsigned zones. Memory usage remained around 25 MB.
The operator now runs periodic active checks against dnssec-failed.org and recommends that anyone operating a resolver perform the same DNS-OARC test immediately.


