DNS with firewall configuration assistance required!

[Kevin Darcy]

I don't exactly understand the firewall architecture you're describing, but
I can tell you that the nameserver never looks at resolv.conf. What the
nameserver *serves* has no necessary relationship to how anything else
running on the same box resolves names. It can, however, be very confusing
when the nameserver which is resolving your queries is *not* the same one
running on the box where you are generating those queries. I know, we used
to have that kind of configuration.

Personally, nowadays I prefer to run a "private" nameserver instance on our
firewalls, one which listens to only the loopback and internal interfaces,
and has knowledge of both the internal DNS (via slave/forward/stub
definitions) and the external DNS (via the Internet roots hints file). The
firewall resolves using this DNS, i.e. its *own* DNS, so everything is kept
relatively self-contained.

This configuration still leaves you 1 "slot", i.e. the external interface,
on which you can run an "external" nameserver instance if you want, serving
up shadow copies of your zones, and of course enforcing strict limits on
recursion for DoS reasons.

I don't know why the book doesn't recommend this. Perhaps it was written
before it was feasible to run multiple nameserver instances on one box
(using "listen-to", "pid-file" and so forth)? Do they perhaps think that
hamstringing the bastion host like this -- making it dependent on another
server and thus multiplying potential points-of-failure -- enhances
security somehow?

As for your question about 2 machines both being master for the same
zone(s), this is quite kosher as long as they serve different sets of
clients. The bastion host would never give answers in those zones to
internal clients (since an authoritative server further down the chain
would give them the answer before it got that far), and conversely there is
no way (assuming you haven't been breached) that an external client would
be able to ask anything of an internal server. So the two masters exist in
different DNS "universes" or "realms", as it were, and no conflicts or
inconsistencies arise.


- Kevin

Jon Paterson wrote:

> Hi, I have recently been reading "Linux Firewalls" (new Riders) and are
> a little confused by a statement made by the book.  I would be very
> greatful if someone could expand on the configuration / example given by
> the book.
>
> Basically, the recommendation from the book is as follows:
>
> The bastion firewall hosts external DNS for the internet, and is
> configured as the authorative host for the site.  This information is a
> subset of the "real" internal DNS, with only the information that is to
> be presented to the public.  The bastion has no information for any of
> the internal servers.
>
> The bastion does not use its local name server, but instead the
> resolv.conf on the bastion points to the "choke"(LAN) firewall.
> All internal (LAN) clients point to the chokes DNS Server.
> (so far making sense!)
>
> The choke has the "real" site data, and is also authorative for the site
> (is this allowed / OK?)
>
> now this is where the explaination gets a little vague in the book, it
> says that when the choke server does not have the requested information,
> it queries the server on the bastion, which in turn forwards the query
> to an external name server.
>
> Question are as follows!
>
> Does this mean that the bastion is configured also as a caching
> nameserver?
>
> Would the choke firewall have a forward entry in its conf file pointing
> to the bastions name server?
>
> Would the chokes resolv.conf point to itself (0.0.0.0)?
>
> my understanding of the resolution process is a little grey at the
> moment, so excuse this question if it seems a little stupid...
>
> When the bastion firewall recieves the query from the choke, would it
> not look at its resolv.conf and pass the query back to the choke ending
> in a loop, or does it not use the resolv.conf, (I would really
> appriciate someone explaining this process)
>
> Kind regards,
>
> Jon Paterson.