reverse zone using generate produced 500M image

Kevin Darcy kcd at daimlerchrysler.com
Mon Jul 1 19:36:34 UTC 2002


"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




More information about the bind-users mailing list