From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 01:58:46 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 B09C916A41F for ; Sat, 27 Aug 2005 01:58:46 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id E81EF43D45 for ; Sat, 27 Aug 2005 01:58:45 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 41078 invoked by uid 399); 27 Aug 2005 01:58:44 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 27 Aug 2005 01:58:44 -0000 Message-ID: <430FC8D3.9030701@FreeBSD.org> Date: Fri, 26 Aug 2005 18:58:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew N. Dodd" References: <20050826202713.X1915@sasami.jurai.net> In-Reply-To: <20050826202713.X1915@sasami.jurai.net> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 27 Aug 2005 01:58:46 -0000 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