Opinion wanted: DNS with firewall setup

[Jozef Skvarcek]

On Tue, 16 Jan 2001, Kevin Darcy wrote:

> maybe not. From the standpoint of propagating changes quickly, you want
> only a single hop from the master to the registered servers that the public
> will use to resolve your names. I assume that your firewall architecture
> somehow precludes zone transfers directly from an internal master to
> external slaves (???)

Yes, as far as I know. The point is that in order to allow the external
slaves to transfer the zones directly from the internal master, we would
need to allow direct connection from the external servers to the master's
port 53. We don't want any direct connection from the outside to the
inside networks (resp. we try to avoid it as hard as we can). I will 
setup TSIG to authenticate the zone transfers, still I don't want to
break the rule.

> Is there some reason why you must have a "master" server which is master
> for *all* of your zones? In your situation, I think maybe I'd master the
> dynamic zones on an internal server, and then, to eliminate the
> "double-slaving" mentioned above, put the master for all
> externally-accessible zones in the DMZ. Of course, I'm assuming here that
> the dynamic zones aren't *also* externally-visible. If they are, then

I would like to have single master for the administrative purposes, i.e.
creating a single point management. For example, it is easier to backup
and monitor the single master. The backup (we use network - EDM) is
another reason why I don't want to put the master into the DMZ.

> Another thing to consider is whether you really want the data in your zones
> to be as visible externally as it is internally. Now, maybe you have all of
> your internal names sectioned off into subdomains that are not visible
> externally. If so, congratulations! But if, as with most of us, your users
> and/or management have nixed the idea of "ghettoizing" all of your internal
> names into separate subdomains, and if you don't want all of that internal
> stuff to be visible, then you have to implement so-called "split DNS" where
> you have separate versions of at least some of your zones, versions which
> are _either_ externally or internally visible. In your case, maybe you

Most of the zones are static and should be visible to any client - not a
problem with those. However, the zone for our main domain, say,
`company.com' is "messed up" little bit. It contains both external and
the internal records. It would be very diffucult at this point to put the
internal records into some internal zone serving, say, `company.internal'
domain. Yes, I am planning to use the split zone functionality provided
by the `view' statement. (BTW, the split zone chapter in the BIND v9
manual is really bad). The dynamic part is only on the inside, I created
a subdomain for the purpose with its own zone file. The dynamic zone
is there mainly for M$ AD, the AD people here have some problems with
the AD policies. They blame the BIND server, I don't believe it but I
can't get from them any useful info which would allow to replicate the
problem in the lab and then to solve it. Anyway, if the time comes when
I have enough of this I may decide to simply delegate the dynamic zone
to their M$ DNS W2k...   

> 
> You might also want to consider completely separating recursive from
> non-recursive services.

Exactly. The external servers will not do the recursive querries. They
will serve our clients on the outside only.

> On the other hand, there's a lot to be said for leading the way, setting a
> good example, etc.. If everyone waits for "the other guys" to implement
> DNSSEC, it'll never get implemented...

True. I understood it is possible to set up the `security root' by sending
our keys to the DNS servers on the outside. They should then use the
`trusted-keys'(?) line in their config files to point to our key. Again,
the documentation about this in the BIND manual is not sufficient.

Jozef