reverse zone using generate produced 500M image

[Sorkin, David (David)]

Sure we could throw 3 or 4 gigs of Ram into a name server but it seems like such a waste when before 512mb was doing the job just fine. I need to have all the reverse zones populated with data because end users inside the company are allowed to directly initiate connections to some outside services like ftp. These services which are often protected by tcp wrappers do a reverse lookup and then a forward lookup to see if it matches the IP that's connecting before allowing connection. Potentially any IP could be used and I never know which in advance. Finally I decided to dump our in house code and use walldns(Dan Bernstein) which does something similar.

I'm still curious (if you're willing to share the info) what you do to solve, or why you don't have this problem.

 

> --
> David Sorkin <dsorkin at lucent.com>



-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Monday, July 01, 2002 3:37 PM
To: 'bind-users at isc.org'
Subject: Re: reverse zone using generate produced 500M image



"Sorkin, David (David)" wrote:

> Hi,
>
> I upgraded today to 8.3.3 from 8.2.3 to addresses security issues. I also configured bind to run chrooted and as a non-privileged user. This worked out but the upgrade broke a piece of in house code which I did not write that we use for reverse zone auto generation. The program is supposed to take queries like:
>
> 109.88.118.135.in.addr.arpa ptr
>
> and produce a response like
>
> h135.118.88.109.outland.lucent.com.
>
> > It would also do the inverse process for the forward zone.
> >
> > Anyway, after the upgrade I started seeing thousands and thousands of entries like:
> >
> 30-Jun-2002 07:37:39.144 wrong ans. name (. != 142.66.118.199.in-addr.arpa)
> 30-Jun-2002 07:37:39.156 invalid RR type 'PTR' in authority section (name = '142.66.118.199.in-addr.arpa') from [192.11.223.170].53
> 30-Jun-2002 07:37:39.164 invalid RR type 'NS' in additional section (name = '66.118.199.in-addr.arpa') from [192.11.223.170].53
>
> I'd like to try to solve this problem without more coding so just to see what would happen I tried using the generate directive to create PTR records for 82 B class networks. It used up nearly 500 Mb of RAM. This is not going to be workable and wildcard PTR records aren't an option either. (also I can't get rid of split DNS).
>
> I was hoping that someone could tell me how they've dealt with this problem elsewhere.

How many organizations have 82 B-class networks? We only have about 4 (in addition to our A-class).

If you're large enough to have that many B-class'es, aren't you large enough to buy enough RAM for your nameservers?

I'm not sure why *every* node on every possible IP address in your network needs a PTR anyway. Seems like overkill to me.

                                                                                                                                    - Kevin