From owner-freebsd-questions@FreeBSD.ORG Fri Jul 13 16:13:20 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 1974E16A407 for ; Fri, 13 Jul 2007 16:13:20 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from eskimo.tundraware.com (eskimo.tundraware.com [66.92.130.161]) by mx1.freebsd.org (Postfix) with ESMTP id AF03813C491 for ; Fri, 13 Jul 2007 16:13:19 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from [192.168.0.2] (ozzie.tundraware.com [66.92.130.199]) (authenticated bits=0) by eskimo.tundraware.com (8.14.1/8.14.1) with ESMTP id l6DGDATc090274 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2007 11:13:11 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <4697A498.5000501@tundraware.com> Date: Fri, 13 Jul 2007 11:13:12 -0500 From: Tim Daneliuk Organization: TundraWare Inc. User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Josh Paetzel References: <468972C5.9090902@tundraware.com> <200707021722.05724.josh@tcbug.org> In-Reply-To: <200707021722.05724.josh@tcbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-tundraware.com-MailScanner-Information: Please contact the ISP for more information X-tundraware.com-MailScanner: Found to be clean X-tundraware.com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.399, required 1, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-tundraware.com-MailScanner-From: tundra@tundraware.com X-Spam-Status: No 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 Reply-To: tundra@tundraware.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 16:13:20 -0000 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, -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/