Firewall / Internal Lookup Configuration Question

[Kevin Darcy]

Hekimian, David wrote:

> *Resent due to errors - Sorry*
>
> I believe I have done sufficient research to come to my configuration. I
> have look at some recent discussions and read the DNS and BIND book but I
> still don't feel comfortable with the solution I'm trying to implement. I
> think there is a simpler or standard approach that I am over looking.
>
> Please excuse my ignorance in the subject, I'm new to DNS.
>
> Configuration:
>
> Inside Firewall - DNS A & DNS B
> Outside Firewall - DNS C
>
> On DNS A I run Windows NT 4.0 with NT DNS, DHCP and WINS for DNS -> WINS
> recursive queries for internal hosts. This server runs as a secondary for
> domain XYZ.COM allowing for queries that are not in the database (I.E.
> internal machines) to be resolved via WINS but forwards all other queries to
> DNS B (Microsoft's DNS implementation has problems looking up some Internet
> address... )
>
> On DNS B I'm running RedHat 6.1 upgraded with Bind 8.2.2-P3 from RedHat's
> updates. This is my Master nameserver for all my domains including XYZ.Com.
> This server has only external addresses listed.
>
> DNS C is my ISP's DNS. This server runs as Published Primary for my domains.
>
> XYZ.com is my companies main domain name. It is used for our external
> website www.xyz.com and for our internal servers exchange.xyz.com.
>
> Problem:
>
> The Firewall (Cisco PIX v5.0(3)) does not allow internal clients
> (172.16.0.0) to connect to local external addresses of which the Firewall
> translates. (My webserver sits inside the firewall DMZ. The firewall has a
> static address, mapping the external address to the internal DMZ address)
> When a user queries DNS A it returned the external address for the webserver
> and the client times out as the firewall blocks the address.

I'm not sure I entirely understand the problem you're having, but it sounds
like you want different addresses returned for the same name, depending on who
is doing the asking, i.e. and internal or external name returned to internal or
external clients, respectively. My answers below are based on this assumption.

> Questions:
>
> 1. Should I change DNS A to be a master for XYZ.com and put only local
> addresses and forward all queries to DNS B?

With the current BIND, once you make DNS A master for XYZ.com, it won't forward
anything in the XYZ.com zone, since it considers itself authoritative for
everything in the zone. This means you'd have to maintain essentially a full
copy of XYZ.com on DNS A, as well as on DNS B, with of course the different
webserver addresses distinguishing them. Also, subzones (if you have any) could
be a problem: I doubt that the nameserver you're running on DNS A has
BIND 8.2's ability to easily suppress default forwarding for a whole namespace
hierarchy; if not, then you might be stuck being a slave and/or maintaining
separate copies for all subzones of XYZ.com.

The "views" mechanism described in the _DNS_and_BIND_ book and purportedly
implemented in BIND 9 would allow conditional forwarding if a name wasn't
found. Theoretically, you could exploit this feature so that you'd only have to
maintain the full XYZ.com on 1 of the servers:  the other one would just
conditionally-forward for anything it doesn't find. I don't know if and when
BIND 9 might become available for NT 4.0.

> 2. Can I setup DNS B to use a different database / view for internal
> queries?

See above. With "views", if implemented as specified, you could have the master
zone on DNS B just contain external data; if the DNS B nameserver needed to
look up something internal, it could just conditionally-forward back to DNS A.
Or you could have the full zone on DNS B with conditional forwarding to DNS A,
but generally it's recommended to keep your internal data internal, plus
"views" are more likely to available sooner for DNS B (RedHat 6.1) than for
DNS A (NT 4.0).

> 3. Am I missing some piece of logic which makes this much simpler?

If you weren't using private addresses, I might have recommended the
"sortlist trick", where you have the names return both internal and external
addresses, and then sort the answer based on the querying client address. But
it has occurred to me recently that this is a really bad idea when private
addresses are involved, since if everyone did it, they'd all be
"leaking" private addresses onto the Internet, which is not only wasteful in
and of itself, but it would cause really suboptimal behavior when they went to
connect to each other's sites. Even with public addresses, the sortlist trick
is still somewhat unreliable because of the response-sorting effects of caching
and non-cooperating slaves, combined with the fact that a lot of client
software still doesn't know to fallback to alternate addresses...


- Kevin