[CFR] reflect resolv.conf update to running application

[Matthew N. Dodd]

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