Date: Fri, 13 Jul 2007 12:30:48 -0500 From: Josh Paetzel <josh@tcbug.org> To: tundra@tundraware.com Cc: freebsd-questions@freebsd.org Subject: Re: Finally Converting From Bind 8 -> Bind 9 Message-ID: <200707131230.51214.josh@tcbug.org> In-Reply-To: <4697A498.5000501@tundraware.com> References: <468972C5.9090902@tundraware.com> <200707021722.05724.josh@tcbug.org> <4697A498.5000501@tundraware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2470370.fERUZZ8hpD
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Friday 13 July 2007, Tim Daneliuk wrote:
> Josh Paetzel wrote:
> > On Monday 02 July 2007 16:48, Tim Daneliuk wrote:
> >> I am (ever so) slowly moving my domain from FBSD 4.x to 6.2. I
> >> am now at the point where I need to convert my Bind 8
> >> configuration to Bind 9. In so doing, I like to finally separate
> >> my internal (non-routable) hosts so that their names never
> >> resolve outside the private network, and expose only the public
> >> facing hosts to the world via DNS. I'd also like to (finally)
> >> associate names with dhcpd-provided addresses so both forwards &
> >> reverses work inside the private network.
> >>
> >> Could some kind soul please point me to a good HOWTO on this
> >> migration and reconfiguration? I am DAGSing as I write this,
> >> but so far have not found what I want.
> >>
> >> TIA,
> >
> > The first part of what you want is easy.
> > In named.conf you'll have something like...
> >
> > acl private-hosts { 192.168.1.0/24; 192.168.2.0/24; };
> >
> > view "internal" {
> > match-clients { "private-hosts"; };
> > zone "example.org" {
> > type master;
> > file "master/db.internal.example.org";
> > };
> > };
> >
> > view "external" {
> > match-clients { any; };
> > zone "example.org" {
> > type master;
> > file "master/db.example.org";
> > };
> > };
> >
> > Now you have two separate zonefiles, one which is consulted when
> > someone from 192.168.1.0/24 or 192.168.2.0/24 makes a query and
> > one that is consulted when anyone else makes a query.
> >
> > HTH
>
> OK - that works great ... but there is one efficiency I'd like to
> achieve that I'm not quite sure how implement. At the moment,
> both db.internal and db.external contain common public host
> information because I want those hosts visible to both communities.
> This means I have to make changes in two places when an public
> host entry is modified.
>
> I tried removing the public information from the db.internal file
> with the hope that an internal client requesting public host info
> would have the request satisfied automatically from db.external -
> this didn't work, the public hosts just disappeared from the
> internal view altogether. This raises two questions:
>
> 1) Is there a way to configure BIND9 so that internal client
> requests are first serviced out of db.internal, but if the lookup
> fails the server will then go look at db.external?
>
> 2) Better still is there some sort of "include" mechanism where I
> could keep a flat file of public host information for use by
> db.external, but include it into db.internal.
>
> Either of these would satisfy my desire to only have to edit a
> single file of public host information.
>
> TIA,
Sure, you can $INCLUDE a file in to a zonefile. :)
=2D-=20
Thanks,
Josh Paetzel
--nextPart2470370.fERUZZ8hpD
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQBGl7bLJvkB8SevrssRAg0rAJ9amFI/aT9tAO0y7at7KZbww0ZT3ACfUrsw
zlSXjaLvJaMCc0UEGughSMI=
=Ik5E
-----END PGP SIGNATURE-----
--nextPart2470370.fERUZZ8hpD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707131230.51214.josh>