dig returns SERVFAIL but +trace works

Hamed Tabatabaei picture Hamed Tabatabaei · Aug 19, 2012 · Viewed 43.6k times · Source

Here is the main problem:

dig maktabkhooneh.info +trace

works perfectly fine and returns the right answer.

dig maktabkhooneh.info

(without +trace) returns:

; <<>> DiG 9.8.1-P1 <<>> maktabkhooneh.info

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58716

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

What could be the reason? I was reading this. Is it the only possible reason that I changed domain data 12hrs ago? Isn't there any other possible reason for SERVFAIL?

extra info:

I have two BIND servers working on 168.144.251.73 (master) and 168.144.92.50 (slave).

and on the master I have:

$TTL 300

maktabkhooneh.info.        IN    SOA     ns1.maktabkhooneh.info.   
admin.maktabkhooneh.info. (

2012060201    ; Serial

86400    ; Refresh

7200     ; Retry

3600000    ; Expire

300 )  ; Minimum


maktabkhooneh.info.        IN    A       168.144.97.83

maktabkhooneh.info.        IN    NS      ns1.maktabkhooneh.info.

maktabkhooneh.info.        IN        NS      ns2.maktabkhooneh.info.

ns1     IN    A   168.144.251.73

ns2     IN    A   168.144.92.50

www     IN    CNAME   maktabkhooneh.info.

Answer

Sandman4 picture Sandman4 · Aug 20, 2012

dig +trace follows the whole chain from the beginning - it queries root servers, then .info servers then your namservers. Thus it avoids any caching resolvers, and also avoids propagation issues.

dig +notrace (the default) queries your default DNS resolver (on Linux, whatever specified in /etc/resolv.conf).

There's some problem with that resolver - maybe it misconfigured, maybe it have old data in caches, maybe it can not reach your authoritative nameservers etc.