From owner-freebsd-questions@FreeBSD.ORG Fri Jul 13 17:30:54 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12C5816A400 for ; Fri, 13 Jul 2007 17:30:54 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from cenn-smtp.mc.mpls.visi.com (cenn.mc.mpls.visi.com [208.42.156.9]) by mx1.freebsd.org (Postfix) with ESMTP id BDD8713C4BE for ; Fri, 13 Jul 2007 17:30:53 +0000 (UTC) (envelope-from josh@tcbug.org) Received: from mail.tcbug.org (mail.tcbug.org [208.42.70.163]) by cenn-smtp.mc.mpls.visi.com (Postfix) with ESMTP id 675A9824C; Fri, 13 Jul 2007 12:30:52 -0500 (CDT) Received: from [192.168.1.5] (unknown [192.168.2.1]) by mail.tcbug.org (Postfix) with ESMTP id 40143341C0C; Fri, 13 Jul 2007 12:30:52 -0500 (CDT) From: Josh Paetzel To: tundra@tundraware.com Date: Fri, 13 Jul 2007 12:30:48 -0500 User-Agent: KMail/1.9.6 References: <468972C5.9090902@tundraware.com> <200707021722.05724.josh@tcbug.org> <4697A498.5000501@tundraware.com> In-Reply-To: <4697A498.5000501@tundraware.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2470370.fERUZZ8hpD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200707131230.51214.josh@tcbug.org> Cc: freebsd-questions@freebsd.org Subject: Re: Finally Converting From Bind 8 -> Bind 9 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 17:30:54 -0000 --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--