BIND9 views, shadow zones, and "hybrid" zones (based on query-source)

[Nathan Benson]

Kevin,

thanks, i was kind hoping there was a more elegant solution so i
wouldn't *have* to do that, but as it looks now that's the way it will
be.  i'll probably try and do some foo with the $INCLUDE stuff, so i
don't have to maintain two copies of the same data. /=3D

thanks,
nb

On 5/12/05, Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> Nathan Benson wrote:
>=20
> >greetings everyone,
> >
> >i've gotten myself into a fairly major DNS reorg and have run into a
> >problem i can't seem to find a reasonable solution to.  the whole
> >point of the reorg was to consolidate the zones onto a single master
> >(responsible for internal and external zones using views) which in
> >turn updated the slaves.
> >
> >anyway, to get to the issue at hand.  i have a bind9 server configured
> >with views to serve up a single zone (say domain.com) which is split
> >into two files, one for internal and one for external.  this is all
> >working beautifully and as expected.  i also have slave servers in the
> >remote offices described below.
> >
> >my problem is two remote offices that need to resolve both internal
> >and external IP's for the same zone.  as simply as possible, they need
> >to resolve mail.domain.com to the external (DMZ) IP rather than the
> >internal (VPN) IP.  but, if the host that they are trying to resolve
> >doesn't exist in the external zone, it needs to fall back to look it
> >up in the internal zone (such as an internal web server, etc).
> >
> >this is basically so all mail traffic from these offices will go over
> >the WAN and to the DMZ, rather than over the VPN tunnel.  currently,
> >if for any reason our VPN tunnel goes down, (even if both office's
> >WAN's are still up) these offices can't send/receive any mail.
> >
> >i don't know if bind9 has the sort of control granularity that i'm
> >describing or not, but i'm *really* trying to stay away from having a
> >third (hybrid) zone file to maintain along with the current two
> >(internal and external).
> >
> >i tried combining the internal/external zones and then using using
> >"sortlist" to order the result based on the query source.  this would
> >"work" because the first IP would be the "right" one for the network,
> >but it returns all the IP's for that hostname, both internal and
> >external.  not a super big deal for internal network use, but totally
> >out of the question for a public facing name server.
> >
> >i'm sure there is a feasible, elegant (read: non-kludge) way to do
> >this, but it's escaping me.  does anyone have any suggestions on how i
> >may accomplish this?  maybe configuring the remote office slave
> >servers to use forwarders to the DMZ name server for external
> >resolution, and then falling back on the local slave zone (which would
> >be the internal zone)?
> >
> >i appreciate any help/suggestions you all may have.
> >
> Duplicate all of the external information in the internal version of the
> zone.
>=20
>=20
>                         - Kevin
>=20
>