BIND error: opcode: QUERY, status: SERVFAIL

Laurent Bauer l.bauer at mailclub.fr
Wed Apr 27 14:36:19 UTC 2011


On 27/04/2011 15:03, Karl Auer wrote:
> On Wed, 2011-04-27 at 17:45 +0530, kshitij mali wrote:
>> we are unable to lookup the domain "goelexports.com"
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63082
> 
> A trace shows the likely problem:
> 
> dns2-rz-ap:[log]$ dig +trace goelexports.com
> [...]
> ;; Received 505 bytes from 192.58.128.30#53(j.root-servers.net) in 32 ms
> 
> goelexports.com.        172800  IN      NS      ns.hostsearchindia.com.
> goelexports.com.        172800  IN      NS      ns2.hostsearchindia.com.
> ;; Received 116 bytes from 192.52.178.30#53(k.gtld-servers.net) in 29 ms
> 
> dig: Couldn't find server 'ns.hostsearchindia.com': node name or service
> name not known
> 
> Neither of those allegedly authoritative nameservers appears to exist.
> 
> Has there been a very recent change to the nameservers for this domain?
> My servers seem to have it cached and are responding with what looks
> like good data:
> 
> dns2-rz-ap:[log]$ dig goelexports.com
> [...]
> ;; ANSWER SECTION:
> goelexports.com.        14057   IN      A       69.16.253.121
> 
> ;; AUTHORITY SECTION:
> goelexports.com.        84408   IN      NS      ns5.webcomindia.net.
> goelexports.com.        84408   IN      NS      ns4.webcomindia.net.
> 
> ;; ADDITIONAL SECTION:
> ns4.webcomindia.net.    12408   IN      A       69.16.253.121
> ns5.webcomindia.net.    12408   IN      A       69.16.253.122

	Hello,

It looks like the delegation has not changed, but the zonefile itself has :

$ dig -t ns goelexports.com @l.gtld-servers.net.
;; AUTHORITY SECTION:
goelexports.com.	172800	IN	NS	ns.hostsearchindia.com.
goelexports.com.	172800	IN	NS	ns2.hostsearchindia.com.

;; ADDITIONAL SECTION:
ns.hostsearchindia.com.	172800	IN	A	69.16.253.121
ns2.hostsearchindia.com. 172800	IN	A	69.16.253.122

*.gtld-servers.net still hold the correct glues for
ns[2].hostsearchindia.com, but the parent's answer is not authoritative.
If you request the IP addresses for those records, you will see the new
NS records, and also you will no longer see an answer for the glues
themselves :

$ dig -t ns goelexports.com @69.16.253.121
;; ANSWER SECTION:
goelexports.com.	86400	IN	NS	ns5.webcomindia.net.
goelexports.com.	86400	IN	NS	ns4.webcomindia.net.

$ dig -t ns ns.hostsearchindia.com @69.16.253.121
;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 47931
;; AUTHORITY SECTION:
hostsearchindia.com.	86400	IN	SOA	ns4.webcomindia.net.
amit.sood.webcomindia.net. 2009090712 86400 7200 3600000 86400

Maybe the zone administrator intended to change the NS names, but did
that the wrong way.

I guess some DNS clients won't use the glue records if they are not part
of an authoritative answer, and some clients will try anyway, using the
IP they have from the parent (additional section).
In my case (dig version 9.6) 'dig' does the former, and 'dig +trace' the
latter.

I have already had a similar issue, see :
https://lists.isc.org/pipermail/bind-users/2010-December/082051.html
for example.

Regards,

	Laurent



More information about the bind-users mailing list