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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
