DNS Caching Issue

[Kevin Darcy]

On 7/25/2011 10:22 AM, Sathyan Arjunan (sarjunan) [CONTRACTOR] wrote:
>
> Recent days, I am facing frequent caching issues with my DNS servers 
> which are responsible for recursive lookup to external queries. As a 
> temporary solution, we used to refresh the named daemon to clear the 
> cache. To isolate this issue we upgraded the BIND to "BIND 9.7.3" but 
> even after the upgrade issue repeats.
>
> If I do a nslookup for "*mail.sin.gpi-g.com*", it fails.
>
> *nslookup mail.sin.gpi-g.com**
> *Server:         dnsserver
>
> Address:        x.x.x.x#53
>
> *** server can't find mail.sin.gpi-g.com: SERVFAIL*
>
> To fix this I have to restart the named daemon in caching DNS server. 
> Once I restart, the lookup resolves well. However the issue appears 
> again in few days. Any thoughts?
>
> nslookup mail.sin.gpi-g.com
>
> Server:         dnsserver
>
> Address:        x.x.x.x#53
>
> Non-authoritative answer:
>
> Name:   mail.sin.gpi-g.com
>
> Address: 203.175.163.180
>
>
nameserver2.gpi-g.com is persistently responding with SERVFAIL.for 
anything at sin.gpi-g.com or beneath. Looks to me like a 
misconfiguration of some sort.

nameserver1.gpi-g.com is responding reasonably, *but* only gives 
nameserver2.gpi-g.com in the Authority Section of its response. So only 
that NS gets cached, and named will keep trying the "bad" nameserver 
until you restart named, which will get it working temporarily until the 
"bad" NS is cached again.

There is nothing you can do to fix this in your instance(s) of BIND. The 
domain owner has created a Single Point of Failure, and then that node 
has failed. They need to fix the node failure, put more diversity into 
their published NS records, or (preferably)  implement both options.

                                                                         
                                                     - Kevin



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110725/2f88d60f/attachment.html>