delvworks very much like the already know
dig. It is like
digwith special DNSSEC validation powers.
delvchecks the DNSSEC validation chain using the same code that is used by the BIND 9 DNS server itself.
But keep in mind that delv, as any standard unix tool, will use the resolvers in /etc/resolv.conf to perform all lookups. If all your resolvers listed are DNSSEC validating, delv will not be able to lookup a non-dnssec validating RR, and will not help you debug the problem.
[stsimb@jumbo ~]$ delv www.spbet.eu. +multi +rtrace ;; fetch: www.spbet.eu/A ;; resolution failed: failure
You need to have access to some non-DNSSEC validating resolver, to kick start the trace..
[stsimb@jumbo ~]$ delv www.spbet.eu. @22.214.171.124 +multi +rtrace ;; fetch: www.spbet.eu/A ;; fetch: eu/DS ;; fetch: ./DNSKEY ;; fetch: spbet.eu/DS ;; fetch: eu/DNSKEY ;; fetch: eu/DS ;; fetch: ./DNSKEY ;; fetch: www.spbet.eu/DS ;; fetch: eu/DS ;; fetch: ./DNSKEY ;; fetch: spbet.eu/DS ;; fetch: eu/DNSKEY ;; fetch: eu/DS ;; fetch: ./DNSKEY ;; no valid RRSIG resolving 'www.spbet.eu/DS/IN': 126.96.36.199#53 ;; no valid DS resolving 'www.spbet.eu/A/IN': 188.8.131.52#53 ;; resolution failed: no valid DS
Personally I don’t consider this a bug. It’s expected behaviour, a unix tool to use the resolvers in /etc/resolv.conf for resolution.
delv cannot determine for sure if it’s your resolver’s fault, and then try another one (and if it did, which one should it choose?). It’s your job to have this in mind, and ask some other non-dncsec validating resolver that you have access to.
Nevertheless, this situation may come up many times. Troubleshooting broken trust chains is one of the reasons someone will use delv, and gives you a reason to keep a non dnssec-validating resolver available somewhere.