From owner-freebsd-current@FreeBSD.ORG Sun Jan 27 18:45:56 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B3E16A418 for ; Sun, 27 Jan 2008 18:45:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8295D13C459 for ; Sun, 27 Jan 2008 18:45:55 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2A359208C; Sun, 27 Jan 2008 19:45:47 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 1BFC6208A; Sun, 27 Jan 2008 19:45:47 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id E33D28449F; Sun, 27 Jan 2008 19:45:46 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Hajimu UMEMOTO References: <86d4rn1kln.fsf@ds4.des.no> <86sl0jywii.fsf@ds4.des.no> Date: Sun, 27 Jan 2008 19:45:46 +0100 In-Reply-To: (Hajimu UMEMOTO's message of "Mon\, 28 Jan 2008 03\:18\:21 +0900") Message-ID: <86abmryun9.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: current@FreeBSD.org Subject: Re: resolver change? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 18:45:56 -0000 Hajimu UMEMOTO writes: > Dag-Erling Sm=C3=B8rgrav writes: > > OK, so the resolver now uses a process-internal cache? Is there any way > > to turn it off? > No, our resolver doesn't have a process-internal cache at all. So what's going on? Looking back through my logs, it was working correctly as late as January 13, so something broke between then and January 21. My name server does *not* forward queries, it goes straight to the source. Everything looks fine if I run host(1) multiple times, it only seems to fail when successive lookups are made from the same process. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no