>
> But, we still want the bastion host to be able to resolve both internal &
> external names. So, would the following work? ...
>
> (For simplicity, I'm assuming a single dual-homed bastion host.)
>
> - An external DNS runs on the `bastion' host, claiming to be a primary
> for the domain (as before).
>
> - The internal DNS (running on `dnsmaster') also claims to be primary for
> the domain. However, it does NOT set `forwarders' to the bastion host.
>
> - A second internal DNS server (running on `dnsfwd') is a secondary for
> the domain. This is where you set `forwarders' to the bastion.
>
> - Internal hosts resolve using `dnsmaster'. Hence they can't resolve
> external names.
>
> - The bastion host (only) resolves using `dnsfwd', which can resolve both
> internal & external names.
>
> Disclaimer: I haven't tried this (yet). I have a funny feeling it might
> not work, but can't see where my logic is wrong.
I encountered the same problems.
Problems with the ``forwarder'' stuff is that a named that uses this, can not
delegate. I came up with the following solution:
requirements: - proxies on the firewall must be able to do internal *and*
external lookups (TIS double revers lookup needs this).
- internal clients using the proxies, are only allowed to do
local lookups
- internal clients using socks must be able to do local and
external lookups
- the outside world may only do a limited lookup
first (bad, but educational) implementation:
- bastion host offers limited dns to the external world
- bastion proxy software uses another dns server, called missinglink
(via resolv,conf on the bastion host)
- for internal lookup a nameserver ns1 acts as a root server
- the nameserver ``missinglink'' is setup as follows:
- forwarder/slave to bastion host to get external lookup
- acting as secondary for most maps from ns1
socks clients and the bastion host itself are pointing to
missinglink and normal clients are using ns1.
problems with this (tested) implementation:
- We need three hosts to make this work. That's a hard selling
argument.....
- The forwarder/slave on the missinglink named prohibits delegation.
This could be solved by making missinglink secondary for *every*
internal domain, but this solution was rejected. Another solution
was to give missinglink (dns) world access itself, but than only a
router would/could block incoming dns requests from the external
world.
next (tested and satisfactory) implementation:
- We had to patch bind. I mailed the idea behind the patch to Paul
Vixie and he told me that this patch will be in the next release of
bind, since it seems to be useful.
The patch is:
- extra keyword "interface" in named.boot (with as argument
an ip address of one of the hosts interfaces).
- when named starts, it binds itself not to INADDR_ANY, but
only to the interface specified.
- A ``normal'' root server (ns) inside the domain.
- On the bastion host we run *2* named's (using the patch):
- a limited one for the external world on the outer interface
- a secondary for the internal rootserver maps (but not as a
rootserver itself) on the internal interface.
since this secondary runs on the bastionhost and is not
a rootserver, it can resolve internal *and* external
lookups *AND* doesn't need forwarder/slave: So internal
delegation can be done without affecting the bastion host
for every change that ocurs.
Normal clients are pointing to ns1 (the internal rootserver)
Socks clients are pointing to the bastion hosts internal interface
Bastion hosts proxies are pointing the host's internal interface
(or to localhost if you bother to set up a third server :-)
The external world is using the external bastion host interface.
This approach requires one nameserver less than the first solution,
and needs no extra router entries.
Problems, problems, problems on single homed hosts however.
Single homed hosts seem to have one interface (...). Ok, so buy another
ethercard and you are ready to go. Yes, but not on a Sun...... under
SunOS 4.1.3 all ethercards are using the same ethernet address. Effectively
this means that you can not address one of the two interfaces if they are
on the same cable. Buying an extra router/hub port could solve this.
But hey, mind over matter (it's cheaper too):
- we put the VIF loopbackdriver in the Sun's kernel. Now this
single homed bastion host can give us as many loopback interfaces
as we want.
- With this, if we want to, we can run all named's on *one* machine.
(we do have a ns2 secondary rootserver (to get rid of these
nasty named warnings :-)
[ A while ago, I posted a request for discussion on the bind/firewall/socks
mailinglist on the topic of DNS on firewalls. I got a few reactions,
(thanks, thanks, thanks) but besides some useful and nice thoughts
nobody seemed to have a final theorie.
(actually, two solutions were mailed to me that both included patches
to bind. As far as I can see, these patches are doing a good job for their
creators, but are rather complex. (they need modified datastructures).
At that time however, I already invented my patch.)
Thanks to:
Paul A Vixie <paul @
vix .
com>
"Wayne E. Van Pelt" <vanpelt @
crd .
GE .
COM> (patch based on targetting
data in the cache as being in the local domain or from outer space and
forwarding only if from outer space).
whna @
nexos .
com (Heinz Naef)
lazear @
dockside .
mitre .
org
Morten Hermanrud <M .
Hermanrud @
ibm .
no> (patch based on forwarding to
some other server if NXDOMAIN is returned, also changes the cache
algorithem)
sansom @
fshops .
sfsu .
edu
jon @
nytimes .
com (Jon E. Price)
<Stephen .
J .
Russo @
nola .
mcdermott .
com>
]
Follow-Ups:
|
|
