reverse zone using generate produced 500M image

[Mark_Andrews at isc.org]

> 
> Hi,
> 
> I upgraded today to 8.3.3 from 8.2.3 to addresses security issues. I also con
> figured bind to run chrooted and as a non-privileged user. This worked out bu
> t the upgrade broke a piece of in house code which I did not write that we us
> e for reverse zone auto generation. The program is supposed to take queries l
> ike:
> 
> 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 entri
> es 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 be looking at the code generating the answers.
> 
> 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.

	That's 5373952 records.  ~100 byte / record => 500 MB

> 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 e
> lsewhere.
> 
> 
> > Thanks in advance,
> > David Sorkin <dsorkin at lucent.com>
> > 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org