From owner-freebsd-stable@FreeBSD.ORG Tue Jul 17 07:40:22 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D65E16A401; Tue, 17 Jul 2007 07:40:22 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 04FCE13C4B4; Tue, 17 Jul 2007 07:40:21 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7d8a.q.ppp-pool.de [89.53.125.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 3014312884A; Tue, 17 Jul 2007 09:40:12 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id AED093F43A; Tue, 17 Jul 2007 09:40:01 +0200 (CEST) Message-ID: <469C724F.1030400@vwsoft.com> Date: Tue, 17 Jul 2007 09:39:59 +0200 From: Volker User-Agent: Thunderbird 2.0.0.4 (X11/20070615) MIME-Version: 1.0 To: Michael Nottebrock References: <200707162319.41724.lofi@freebsd.org> <20070717052823.GA1277@darklight.org.ru> <200707170920.24692.lofi@freebsd.org> In-Reply-To: <200707170920.24692.lofi@freebsd.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-stable@freebsd.org, Yuri Pankov Subject: Re: Problems with named default configuration in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2007 07:40:22 -0000 On 07/17/07 09:20, Michael Nottebrock wrote: > On Tuesday, 17. July 2007, Yuri Pankov wrote: >> On Mon, Jul 16, 2007 at 11:19:41PM +0200, Michael Nottebrock wrote: >>> I finally updated my desktop from 5.5-RELEASE to 6-STABLE. This got me a >>> new named.conf, which I modified to run named as a local resolver, like I >>> had before: >>> >>> listen-on { 127.0.0.1; }; >>> listen-on-v6 { ::1; }; >>> forward only; >>> forwarders { >>> 192.168.8.1; >>> }; >>> >>> Everything else is default. However, with this default configuration, >>> named will not resolve any hosts of my local domain (my.domain), which >>> uses addresses in the 192.168.8 subnet. My dns server on 192.168.8.1, >>> running 6.2-RELEASE, has a very simple dynamic dns setup: a zone >>> "my.domain" and a reverse zone 8.168.192.in-addr.arpa which are both >>> dynamically updated by dhcpd. >>> >>> To make this work again, I had to delete everything in the default >>> named.conf from "/* Slaving the following zones from the root [...]" >>> to "zone "ip6.int" { type master; >>> file "master/empty.db"; };". >>> >>> I'm a DNS n00b, but I suspect that such drastic measures shouldn't be >>> required and somehow my setup is flawed. What can I do to make this work >>> right? >>> >>> >>> Cheers, >>> -- >>> ,_, | Michael Nottebrock | lofi@freebsd.org >>> (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org >>> \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org >> Hi Michael, >> >> If I understood you correctly, you can't resolve 8.168.192.in-addr.arpa >> anymore, and the line below (from default named.conf) is the cause: >> >> zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; > > Yes - and this: > > zone "." { > type slave; The root zone MUST be of type hint. You do not want to be a slave of the root... don't you? ;) > file "slave/root.slave"; > masters { > 192.5.5.241; // F.ROOT-SERVERS.NET. > 192.228.79.201; // B.ROOT-SERVERS.NET. > 192.33.4.12; // C.ROOT-SERVERS.NET. > 192.112.36.4; // G.ROOT-SERVERS.NET. > 193.0.14.129; // K.ROOT-SERVERS.NET. > }; > notify no; > }; > > prevents me from resolving hostnames in "my.domain". What I'm still wondering > though, is this an oversight or by design? I can't imagine setups like mine > are very rare. Doug? > Yes, if the servers of the root zone can't be resolved, all queries will fail. If you've got a file /etc/namedb/named.root set it like file "/etc/namedb/named.root"; and change the zone type to "hint" and all should be well again. Volker