Date: Fri, 26 Aug 2005 18:58:43 -0700 From: Doug Barton <dougb@FreeBSD.org> To: "Matthew N. Dodd" <mdodd@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: [CFR] reflect resolv.conf update to running application Message-ID: <430FC8D3.9030701@FreeBSD.org> In-Reply-To: <20050826202713.X1915@sasami.jurai.net> References: <ygefyt4yiaz.wl%ume@mahoroba.org> <20050826202713.X1915@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew N. Dodd wrote:
> On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote:
>
>> Our resolver reads resolv.conf once, and never re-read it. Recent
>> OpenBSD changed to re-read resolv.conf when it is updated. I believe
>> it is useful specially for mobile environment.
>
>
> The more useful solution is to run a local caching nameserver that
> forwards to the DHCP or location specific nameservers.
>
> I've got modifications to dhclient-script and a Makefile in /etc/namedb/
> that implement this behavior. I'll clean it up for public consumption
> if others are interested.
I'm interested in reviewing that.
As a general case, I'm ambivalent about using a local (on the same system)
forwarder, as they can lead to unpredictable results. If the system is
non-mobile, and the network configuration (including resolving name servers)
is stable, and well designed, then a local forwarder is probably going to be
ok.
If the system is mobile, and even occasionally is moved into an unknown, or
poorly configured network (think hotel room networks and other for-pay
hotspots that do wacky DNS tricks) a local forwarder is likely to cause
additional problems and confusion that can be difficult to debug. On the
other hand, a local resolver (without forwarding) in that same situation
would lead to equally unpredictable results.
In short, I think that this is something I'd like to see us explore, but it
should definitely be optional, and come with lots of warnings.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430FC8D3.9030701>