Date: Thu, 15 Sep 2005 09:59:48 -0400 (EDT) From: "Matthew N. Dodd" <mdodd@FreeBSD.ORG> To: Doug Barton <dougb@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application Message-ID: <20050915094948.K79434@sasami.jurai.net> In-Reply-To: <43293189.5000200@FreeBSD.org> References: <ygefyt4yiaz.wl%ume@mahoroba.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050915094948.K79434>