After you have figured out the query path, the next thing to do is to determine whether or not the problem is actually related to DNSSEC validation. You can use the +cd flag in dig to disable validation, as described in the section called “How Do I know I Have a Validation Problem?”.

When there is indeed a DNSSEC validation problem, the visible symptoms, unfortunately, are very limited. With DNSSEC validation enabled, if a DNS response is not fully validated, it will result in a generic SERVFAIL message, as shown below when querying against a recursive name server 192.168.1.7:

$ dig @192.168.1.7 www.isc.org. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8101
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; Query time: 973 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Thu Oct 16 20:28:20 CST 2014
;; MSG SIZE  rcvd: 40

With delv, a "resolution failed" message is output instead:

$ delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; resolution failed: failure