reverse zone using generate produced 500M image

[dbotham at edeltacom.com]

On the same line as Pete's response, you may want to consider hiding your
internal network(s) from the Internet via NAT.  Then, your external
in-addr.arpa zones get really small and upkeep takes a lot less time.


Dave...


|---------+---------------------------->
|         |           Pete Ehlke       |
|         |           <pde at ehlke.net>  |
|         |           Sent by:         |
|         |           bind-users-bounce|
|         |           @isc.org         |
|         |                            |
|         |                            |
|         |           07/02/2002 01:41 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       bind-users at isc.org                                                                                           |
  |       cc:                                                                                                                    |
  |       Subject:  Re: reverse zone using generate produced 500M image                                                          |
  >------------------------------------------------------------------------------------------------------------------------------|





On Tue, Jul 02, 2002 at 09:27:30AM -0400, Sorkin, David (David) wrote:
>
> 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.
>
Well, I don't know about Kevin, but I've obviated this by using
application proxies, instead of indiscriminately allowing every client
on the network to initiate direct connections to the outside world. You
end up with far fewer things to worry about, you increase the opacity
and security of your internal network, and you score huge karma points
when you give all that address space back to ARIN ;)

Yes, I appreciate the difficulty this presents; I've managed this
architecture
in an environment as large as lucent's or larger.

But Mark Andrews was right the first time: your in-house code was
broken, and if you want to create five and a half million records using
$GENERATE, you're going to have to suck up some RAM to do it. Your
options are: eliminate the need, power your machines sufficiently to do
the task with the tool you know (BIND), fix your in house code so that
it generates correct data sets, or use something else.

-Pete