Validate DNS Answers from the Command Line with delv

You will use BIND 9 delv to query a DNS server and see whether its answer is fully validated, unsigned or invalid. You will also perform a reverse lookup and turn on resolver and DNSSEC traces when an answer needs investigation. Allow about fifteen minutes, including time to compare a normal answer with its diagnostic output.

1. Check the installed tool

This guide uses the bind9-dnsutils package and the installed BIND 9 version is 9.18.39-0ubuntu0.24.04.7-Ubuntu. Options and output can differ between releases, so check the local binary before copying a command into a script.

$ command -v delv
/usr/bin/delv
$ delv -v
delv 9.18.39-0ubuntu0.24.04.7-Ubuntu

No command in this guide needs elevated privileges. Queries are ordinary network operations. Do not use sudo to fix a timeout or a DNSSEC failure: root access does not make an unreachable resolver reachable and does not make an invalid signature valid.

2. Query a name and read the validation marker

Give delv a server with the @server prefix, followed by the name and record type. This example asks Cloudflare's resolver for the IPv4 address records for example.com:

$ delv @1.1.1.1 example.com A
; fully validated
example.com.  138  IN  A  104.20.23.154
example.com.  138  IN  A  172.66.147.243

The addresses and TTL will change. The useful part is the status comment. ; fully validated means delv built and checked a DNSSEC chain from its trust anchor. A signed response is not automatically a valid response, so do not treat the presence of an RRSIG alone as proof.

For a compact answer, add +short:

$ delv @1.1.1.1 example.com A +short
93.184.216.34

Short output is useful for a quick value check, but it removes the surrounding explanation. Use the default verbose form when deciding whether validation succeeded.

3. Know which resolver is being queried

If you omit @server, delv tries servers listed in /etc/resolv.conf. If it finds no usable address, it falls back to local IPv4 and IPv6 addresses. Inspect the file before diagnosing a surprising result:

$ sed -n '1,40p' /etc/resolv.conf
nameserver 127.0.0.53

A local stub such as 127.0.0.53 may forward to an upstream service that you have not inspected. Supplying @1.1.1.1, @8.8.8.8 or your organisation's known resolver makes the comparison explicit. The hostname form, such as @resolver.example.net, needs a preliminary lookup that delv does not validate, so an IP address is clearer during DNSSEC troubleshooting.

The default query type is A. Add the type when you need something else:

$ delv @1.1.1.1 example.com MX +short
0 .

Do not infer that an empty or terse result is a validation failure. Check the verbose response, the exit status and the record type you actually requested.

4. Trace the resolver and validator

When the status is unexpected, use +rtrace to show the fetches made while resolving and +vtrace to show DNSSEC decisions:

$ delv @1.1.1.1 example.com A +rtrace +vtrace
;; fetch: example.com/A
;; validating example.com/A: starting
;; fetch: example.com/DNSKEY
;; fetch: example.com/DS
;; fetch: com/DNSKEY
;; fetch: ./DNSKEY
;; validating example.com/A: marking as secure (DS)
; fully validated

The exact fetch order and key identifiers vary. Look for the original query, DNSKEY and DS lookups, then the final validation state. +mtrace adds a detailed dump of received messages and can be noisy. Start with the two narrower traces so the relevant event is not buried in packet data.

5. Retrieve DNSSEC data without hiding the evidence

delv requests DNSSEC records and validates them by default. +dnssec and +nodnssec control whether RRSIG records are displayed; they do not turn DNSSEC requests or validation on and off as they do in some dig workflows. Use +noall carefully because it clears comment, per-record comment and trust display options together.

If the resolver being queried is itself validating and blocks an invalid answer, request that it disable checking for this query with +cdflag:

$ delv @1.1.1.1 name.example A +cdflag +vtrace
$ printf 'exit status: %s\n' "$?"
exit status: 0

Replace name.example with a domain you are authorised to test. This is a diagnostic path, not a way to make bad DNS safe. The upstream resolver may ignore the request, and delv can still report a validation error locally. The manpage notes that -i disables delv's internal validation, but it does not set the CD bit; avoid -i when the question is whether an answer is trustworthy.

6. Perform a reverse lookup

Use -x for an address-to-name query. delv constructs the corresponding reverse DNS name and changes the type to PTR:

$ delv @1.1.1.1 -x 1.1.1.1 +short
one.one.one.one.

IPv6 addresses are converted to the nibble form under ip6.arpa. A reverse result is an assertion made by the address owner, not proof that the named host owns the address in the forward direction. If that relationship matters, query the returned name for an A or AAAA record and compare it yourself.

7. Handle failures without changing the system

For a timeout, first try the same name against a known reachable resolver and force a transport family if needed:

$ delv -4 @1.1.1.1 example.com A
$ delv -6 @2606:4700:4700::1111 example.com A
$ printf 'last status: %s\n' "$?"
last status: 0

Use only the command that matches a working interface. -4 and -6 restrict transport; they do not change the queried record. If both fail, inspect routing, firewall policy and the resolver service rather than editing /etc/resolv.conf. That file is commonly managed by another service, and manual edits can be overwritten.

For a validation failure, preserve the full verbose output, repeat with +rtrace +vtrace, and compare a second resolver. Do not replace /etc/bind/bind.keys casually. The default trust-anchor file is used by delv, and the manpage warns that it does not use the managed-keys database maintained by named. Changing trust anchors changes what the tool trusts and should follow your distribution's BIND update process.