BIND 9.3.2-P1 failing completely on some domains

Kevin Darcy kcd at daimlerchrysler.com
Fri Sep 15 00:27:13 UTC 2006


Paul A. Hoadley wrote:
> Hello,
>
> I am running BIND 9.3.2-P1 as an authority for hosts on my LAN, but
> not visible at all to the outside world.  I set up the config and zone
> files literally a couple of years ago, and have barely touched them
> since.  I was running 9.3.0 until I upgraded to FreeBSD 5.5-STABLE
> last week, at which point BIND was upgraded.
>
> It may be a coincidence in timing, but since the upgrade I seem to be
> unable to resolve a couple of related hostnames: eve-files.com and
> podbase.com:
>
>   
>> dig www.eve-files.com
>>     
>
> ; <<>> DiG 9.3.2-P1 <<>> www.eve-files.com
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
>
>   
>> dig www.eve-files.com +trace
>>     
>
> ; <<>> DiG 9.3.2-P1 <<>> www.eve-files.com +trace
> ;; global options:  printcmd
> .                       517752  IN      NS      G.ROOT-SERVERS.NET.
> .                       517752  IN      NS      H.ROOT-SERVERS.NET.
> .                       517752  IN      NS      I.ROOT-SERVERS.NET.
> .                       517752  IN      NS      J.ROOT-SERVERS.NET.
> .                       517752  IN      NS      K.ROOT-SERVERS.NET.
> .                       517752  IN      NS      L.ROOT-SERVERS.NET.
> .                       517752  IN      NS      M.ROOT-SERVERS.NET.
> .                       517752  IN      NS      A.ROOT-SERVERS.NET.
> .                       517752  IN      NS      B.ROOT-SERVERS.NET.
> .                       517752  IN      NS      C.ROOT-SERVERS.NET.
> .                       517752  IN      NS      D.ROOT-SERVERS.NET.
> .                       517752  IN      NS      E.ROOT-SERVERS.NET.
> .                       517752  IN      NS      F.ROOT-SERVERS.NET.
> ;; Received 436 bytes from 192.168.0.1#53(192.168.0.1) in 0 ms
>
> com.                    172800  IN      NS      a.gtld-servers.net.
> com.                    172800  IN      NS      g.gtld-servers.net.
> com.                    172800  IN      NS      h.gtld-servers.net.
> com.                    172800  IN      NS      c.gtld-servers.net.
> com.                    172800  IN      NS      i.gtld-servers.net.
> com.                    172800  IN      NS      b.gtld-servers.net.
> com.                    172800  IN      NS      d.gtld-servers.net.
> com.                    172800  IN      NS      l.gtld-servers.net.
> com.                    172800  IN      NS      f.gtld-servers.net.
> com.                    172800  IN      NS      j.gtld-servers.net.
> com.                    172800  IN      NS      k.gtld-servers.net.
> com.                    172800  IN      NS      e.gtld-servers.net.
> com.                    172800  IN      NS      m.gtld-servers.net.
> ;; Received 495 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 276 ms
>
> eve-files.com.          172800  IN      NS      a.podbase.com.
> eve-files.com.          172800  IN      NS      b.podbase.com.
> eve-files.com.          172800  IN      NS      c.podbase.com.
> eve-files.com.          172800  IN      NS      d.podbase.com.
> ;; Received 171 bytes from 192.42.93.30#53(g.gtld-servers.net) in 207 ms
>
> eve-files.com.          172151  IN      NS      c.podbase.com.
> eve-files.com.          172151  IN      NS      d.podbase.com.
> eve-files.com.          172151  IN      NS      a.podbase.com.
> eve-files.com.          172151  IN      NS      b.podbase.com.
> ;; Received 107 bytes from 192.168.0.1#53(a.podbase.com) in 30040 ms
>   
Uh, this is very suspicious. 192.168.0.1 is *not* the address of 
a.podbase.com, as resolved on the Internet. Do you have some sort of 
funky configuration going on here? Or some device that likes to rewrite 
A records in DNS packets on the fly? The fact that this query took 30 
seconds to complete also raises the possibility that something in your 
local network environment is tripping you up here.

I'd recommend running sniffer traces at various points along the egress 
path(s) of your queries and/or the ingress path(s) of the responses 
(which may or may not be the same path(s) of course).

                                                                         
                        - Kevin


                                                                         
                                       - Kevin




More information about the bind-users mailing list