running multiple daemonized instances of BIND9.2 on Windows 2000

[Nick]

Danny Mayer <mayer at gis.net> wrote in message news:<bo1mnq$daa$1 at sf1.isc.org>...
> At 07:01 PM 10/31/03, Nick wrote:
> >I'm trying to provide name resolution services to 4 DMZ subnets
> >attached to Cisco PIX NAT firewall.  My primary and secondary DNS
> >server are both on the same DMZ subnet.
> 
> That's a really bad idea. You need to keep them in separate locations
> if you want redundancy.

I'm aware of the redundancy issue.  We all remember how microsoft.com
got Dos'd off the net because they had all their name servers on a
single subnet.  However, of the four DMZ subnets, only one is under my
control, and I don't sufficiently trust the hosts on the other subnets
to place a name server there without being protected by a firewall. 
For corporate reasons, I'm forced to use a win32 solution, so no *NIX
related suggestions please.  While this placement is not the ideal
solution, it is the best possible compromise with the given
environment.  And before you ask, no, I can't change the environment.



> 
> >However, since the firewall
> >NAT functionality rewrites the source IP in the packet header, I
> >cannot use the "view" functionality of BIND9 to offer different
> >responses based on the source IP, because the firewall NAT
> >functionality makes it look like ALL requests are coming from the
> >local subnet.
> >
> >Fine and dandy, I thought I'd just run 4 different instances of BIND,
> >each listening on a different IP address, then point the clients on
> >each DMZ subnet to the appropriate IP address for name resolution.
> 
> How will this solve the problem? Why can't you list the appropriate
> IP addresses in the view? If the NAT is rewriting the address, surely you
> know that addresses that it rewrites them to?

Yes, I do know the address that the NAT is rewriting the source IP to.
 However, the NAT rewrites incoming name server queries from all the
DMZ subnets to the SAME IP address, which is the reason I said I
couldn't use views in the first place, because the source IP looks the
SAME, regardless of which DMZ subnet the query comes from.  FYI, using
PAT (port address translation) instead of NAT (network address
translation) does allow you to control which source IP address is used
on a subnet-by-subnet basis (or address-by-address basis). 
Unfortunately, I do not control the firewall, and I must live with the
existing configuration.

<snipped>

See the next message in this thread for details on how to set this up
within the constraints of the current environment.