Re: Recent problems with Reverse DNS.

Brett Simpson wrote:

> Brett Simpson <simpsonb@hillsboroughcounty.org> wrote:
> >>Three weeks ago our internal clients were able to connect to hosts by ip
> >>address quickly. Then we started noticing slow connection to various
> internal
> >>host by IP address. If I add a host entry of my workstation to the server
> I'm
> >>connecting to then things are fast again. Sounds like a Reverse DNS problem.
> >>So I updated our db.cache file (which contains the root servers) on both DNS
> >>server and things seemed to be fast again after restarting Bind. But then 10
> >>minutes later things slowed down again.
> >>Our hosts that have public IPs with FQDN are fine. Just the internal hosts
> >>have problems.
>
> >Barry Margolin <barry.margolin () level3 ! com> wrote:
> >If the internal hosts are using private addresses, then you need to have
> >local zone files for the reverse domains. The nameservers that the RFC
> >1918 reverse domains are delegated to don't always respond in a timely
> >fashion.
>
> Hmm... I have a large number of internal private subnets. Making these local
> zone file for reverse lookups would take some time considering I have about
> 100 subnets.

DNS doesn't know from subnets. You could stuff everything into a single
168.192.in-addr.arpa zone if you wanted. And if you don't care what the reverse
lookups resolve to, you could populate it with a single wildcard PTR record. Or
use $GENERATE to just populate it with generic names.

On the other hand, it shouldn't be hard (I know because I've done it in the
past) to just collect all of the data from your forward zones and just massage it
all into PTR records with which to populate your reverse zone(s). Then you
actually have *real* reverse lookups, which is convenient for things like network
troubleshooting (think ping or traceroute), logging, etc. Doing the
forward-to-reverse conversion one-time is not a big deal. Keeping forward and
reverse constantly in synch, however, is a little harder. For this reason (and/or
perhaps others), some folks actually regress back to the neolithic /etc/hosts
file as their primary source of name information and then use evolved hacks like
"h2n" to generate both forward and reverse zones files from that data. In case
you couldn't tell from my description, I don't exactly favor this approach...


- Kevin