delv

delv asks the same resolver dig would, but with checking disabled, fetches the signatures and keys and validates the chain of trust on its own, from the root's key in /etc/bind/bind.keys. It ends each answer with a verdict: ; fully validated (secure), ; unsigned answer (provably unsigned, insecure) or resolution failed with the reason (bogus). +vtrace prints each step of the check, zone by zone.

delv command usage

delv [@SERVER] NAME [TYPE] [+vtrace] [+rtrace] [+short]

Options

+vtrace

print each validation step: which keys and signatures it checked

+rtrace

print each query it sent

@10.0.1.11

fetch the records from that server

+short

only the answer, still with the verdict

-a FILE

read trust anchors from FILE instead of /etc/bind/bind.keys

delv examples

delv www.example.lab

Looks the name up and says whether its signatures check out from the root down.

delv +vtrace www.example.lab 2>&1 | grep -E 'verify|validated'

Shows the keys it checked, zone by zone, and the verdict.

delv www.legacy.lab

Shows an unsigned zone's answer as unsigned, not as a failure.

Reading the output

$ delv www.example.lab
; fully validated
www.example.lab.	60	IN	A	10.0.2.14
www.example.lab.	60	IN	RRSIG	A 13 3 60 20261031120000 20261001120000 28161 example.lab. 3kq…

• ; fully validated: the chain from the trust anchor to this answer checks out. ; unsigned answer: the parent proved the zone is unsigned.
• The RRSIG beside the record is the signature it checked: algorithm 13, key tag 28161, signed by example.lab..
• A failure prints ;; resolution failed: … with the reason, such as RRSIG failed to verify or no valid signature found.

Pitfalls

• Its trust anchor is the file's, not the resolver's: a resolver and delv can disagree when they hold different root keys.
• It still trusts nothing about the answer's path: a forged answer fails here even when the resolver's ad says otherwise.

Run it on real machines