change in reverse dns lookup behavior

Pavel Urban urbanp at mlp.cz
Fri May 13 04:31:03 UTC 2005


Barry Margolin wrote:

> In article <d60mib$114j$1 at sf1.isc.org>,
>  Ole Michaelsen <omic+usenet4 at fys.ku.dk> wrote:
> 
> 
>>Kevin Darcy wrote:
>>
>>> cool burn wrote:
>>> 
>>>
>>>>Hello,
>>>>
>>>>We have an internal network of the form 10.x.x.x
>>>>
>>>>We have two DNS servers (bind 9.2.1) that are
>>>>multi-homed, but are used by the internal network at
>>>>10.0.0.10 and 10.0.0.11
>>>>
>>>>All of the internal servers have resolv.conf setup as:
>>>>nameserver 10.0.0.10
>>>>nameserver 10.0.0.11
>>>>
>>>>This has worked perfectly for 8 months.
>>>>
>>>>Today, we suddenly started getting timeouts in our
>>>>application server connecting to our db server.  Then,
>>>>I saw I was also getting very slow times to connect
>>>>using SSH.  I knew right away this was DNS related.
>>
>>We had the exact same problem. Also noticed with SSH first. With
>>10.17.34 which we dont have a zonefile for. Since 16:00 (CEST) we have
>>had timeouts whenever trying to lookup stuff in that range - we never
>>had this before. This also affected the ability to lookup some 192.168
>>addresses - it partly worked, partly didn't work.
>>
>>But now, since 00:15 CEST approx suddenly the timeouts have disappeared
>>and everything seem to work again!
>>
>>A global glitch in the matrix?
> 
> 
> The servers that the public delegations for 10.in-addr.arpa point to may 
> have gone down or been overloaded.  I've seen this happen a number of 
> times over the years.  When I was at an ISP, I arranged for our caching 
> servers to be authoritative for all the RFC 1918 reverse zones, so that 
> we wouldn't be dependent on these remote servers.
> 

Yes. These servers (blackhole<something>.iana.org) have gone out from 
the network. We had the same problem and had to arrange zones for 
10.in-addr.arpa, 16-31.172.in-addr.arpa and 168.192.in-addr.arpa 
pointing to zone file with just SOA record, as Mark suggested. That 
wasn't nice surprise...

-- 
***********************************************************************
Pavel Urban (pavel.urban at imaginet.cz)
IOL system disaster
Internet OnLine, owned by Cesky Telecom, a.s. (www.ct.cz)
***********************************************************************
    Vegetables should not operate electronic equipment.
           Computer Stupidities, http://rinkworks.com/stupid/
***********************************************************************



More information about the bind-users mailing list