delveworks very much like the already know
dig. It is like
digwith special DNSSEC validation powers.
delvechecks the DNSSEC validation chain using the same code that is used by the BIND 9 DNS server itself.
But keep in mind that delve, 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, delve will not be able to lookup a non-dnssec validating RR, and will not help you debug the problem.
[stsimb@jumbo ~]$ delve 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 ~]$ delve www.spbet.eu. @18.104.22.168 +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': 22.214.171.124#53 ;; no valid DS resolving 'www.spbet.eu/A/IN': 126.96.36.199#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.
delve 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 delve, and gives you a reason to keep a non dnssec-validating resolver available somewhere.