Unbound DNSSEC Validation: Setup and Debug

A validating resolver is the only place where DNSSEC actually improves user security: it checks signatures and returns SERVFAIL instead of a forged answer. Unbound makes this a configuration exercise rather than a protocol project, but the details matter – a missing trust anchor file, a stale anchor, or a hardening option fighting a badly signed domain all produce the same symptom. This guide covers a working configuration and a sane debugging path.

Minimum configuration for validation

server:
    verbosity: 1
    interface: 127.0.0.1
    interface: 10.10.10.53
    access-control: 10.10.10.0/24 allow
    do-ip6: yes
    qname-minimisation: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-below-nxdomain: yes
    harden-referral-path: yes
    use-caps-for-id: yes
    val-clean-additional: yes
    val-permissive-mode: no
    module-config: "validator iterator"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    # logging for troubleshooting
    log-queries: no
    log-replies: no
    remote-control:
        control-enable: yes

module-config: "validator iterator" is what enables validation, and it is only useful with a trust anchor present. For the root zone that means either auto-trust-anchor-file (RFC 5011 tracking, which updates the anchor automatically, and requires the unbound user to have write access to the file and its directory) or a static trust-anchor-file. Generate the initial anchor with unbound-anchor on installation and verify it exists before restarting.

What the hardening options do

• harden-dnssec-stripped – if a signed zone's chain is stripped of DNSSEC data, treat the answer as bogus instead of silently falling back to insecure. Turning it off effectively removes validation for those zones.
• harden-glue – only trust glue records that fall inside the zone being delegated.
• harden-below-nxdomain – remember NXDOMAINs and answer below them consistently, which also reduces load.
• harden-referral-path – validate infrastructure data encountered along the referral path, closing a class of delegation attacks.
• val-clean-additional – strip unsigned records from the additional section of validated replies.

Verifying that validation is really on

unbound-control status
unbound-control stats_noreset | grep -E "num.answer.secure|num.answer.bogus|num.rrset.bogus"

dig +dnssec dnssec-failed.org @127.0.0.1        # expect SERVFAIL
dig +dnssec cloudflare.com @127.0.0.1           # expect NOERROR with ad flag
delv @127.0.0.1 dnssec-failed.org               # detailed validation trace

A resolver that returns NOERROR with the ad flag for known-good signed names and SERVFAIL for dnssec-failed.org is validating. If everything returns SERVFAIL, validation is broken rather than the domains.

Debugging SERVFAIL

unbound-control -c /etc/unbound/unbound.conf set_option verbosity: 4
# reproduce the query, then read the log
journalctl -u unbound -n 200 --no-pager | grep -Ei "bogus|validation|signature|anchor"
unbound-control flush_zone example.com
unbound-control flush_bogus

• Everything fails – missing or unreadable root.key; check permissions on /var/lib/unbound/ and the chroot path.
• Anchor expired – RFC 5011 tracking requires the resolver to be online regularly; an offline resolver can miss a key roll. Run unbound-anchor -a /var/lib/unbound/root.key to refresh.
• One zone fails – verify whether the zone is genuinely mis-signed (use an external validator) or whether a local policy such as local-zone or a stub entry is interfering.
• Internal zones – a private zone with no DNSSEC data will be considered bogus unless you mark it insecure with domain-insecure.

Operational notes

• Keep val-permissive-mode: no; permissive mode logs bogus answers but serves them, which defeats the purpose.
• Watch the ratio of num.answer.bogus to num.answer.secure over time – a sudden rise is usually one upstream zone breaking, not your resolver.
• If you forward to an upstream resolver, validation state depends on that resolver; to truly validate, resolve iteratively.
• Remember that DNSSEC increases response sizes; confirm EDNS/MTU handling if clients see retries.

Related: BIND9 authoritative zones, systemd-resolved troubleshooting, and ISC DHCP server configuration.

原文链接：https://manpages.debian.org/unstable/unbound/unbound.conf.5.en.html