From owner-freebsd-arch@FreeBSD.ORG Thu Sep 15 13:59:55 2005 Return-Path: X-Original-To: arch@FreeBSD.ORG Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A13E816A41F; Thu, 15 Sep 2005 13:59:55 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (sasami.jurai.net [70.88.158.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28EC043D46; Thu, 15 Sep 2005 13:59:54 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [70.88.158.93]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j8FDxmEE053210; Thu, 15 Sep 2005 09:59:53 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Thu, 15 Sep 2005 09:59:48 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Doug Barton In-Reply-To: <43293189.5000200@FreeBSD.org> Message-ID: <20050915094948.K79434@sasami.jurai.net> References: <20050826202713.X1915@sasami.jurai.net> <20050827014153.GA14720@odin.ac.hmc.edu> <20050826221016.B1915@sasami.jurai.net> <20050827170600.GB14720@odin.ac.hmc.edu> <20050828022351.F63789@sasami.jurai.net> <20050908181052.GH31354@odin.ac.hmc.edu> <20050914091957.P56212@sasami.jurai.net> <43293189.5000200@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [70.88.158.93]); Thu, 15 Sep 2005 09:59:54 -0400 (EDT) Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2005 13:59:55 -0000 On Thu, 15 Sep 2005, Doug Barton wrote: > Yes, include works, but it runs a similar risk to modifying the > named.conf file, namely if the syntax of the the statements in the > include file are not right, loading named.conf will fail. So, we should > build some caution into the process of updating the file, but that's > easily done with the named-checkconf program that comes with the > distribution. I'm not sure such paranoia is needed; dhclient has always exposed the system to the risk of having an invalid resolv.conf and regenerating the named.conf file is no different. Since we're regenerating the included file completely I don't see that this is risky at all. >> + rm -f ${dhclient_script_forwarders_file}.$$ >> + echo " forward only;" > ${dhclient_script_forwarders_file}.$$ > > This should really be 'forward first'. That configuration is less likely to > fail in weird, and hard to diagnose ways. I don't agree. I've run into networks that block recursive queries for everything but the published nameserver. There wouldn't be a need for this frobbing if we could just make recursive queries directly. > if named-checkconf /etc/namedb/named.conf; then > rndc reconfig > fi This check seems reasonable. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00