From owner-freebsd-current@FreeBSD.ORG Tue Apr 20 13:14:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2BD416A4D4 for ; Tue, 20 Apr 2004 13:14:34 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id AF2B043D54 for ; Tue, 20 Apr 2004 13:14:34 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 30944 invoked by uid 1000); 20 Apr 2004 20:14:35 -0000 Date: Tue, 20 Apr 2004 13:14:35 -0700 (PDT) From: Nate Lawson To: current@freebsd.org Message-ID: <20040420131408.B30850@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: resolver fix from DF X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 20 Apr 2004 20:14:35 -0000 dillon 2004/04/13 14:53:43 PDT DragonFly src repository Modified files: lib/libc/net res_query.c Log: res_search only incremented got_servfail for h_errno == TRY_AGAIN *AND* hp->rcode == SERVFAIL. However, there are cases such as timeouts where rcode is not always set to SERVFAIL. This leads to inconsistent nameserver operation during multi-domain and truncated dot searches, especially during booting when portions of the network are being brought up simultanious with dns lookups. This patch attempts to correct the problem by unconditionally terminating the search if TRY_AGAIN is returned (after res_query has gone through all retries and name servers) instead of trying other domain elements in the domain seach path. This patch should fix reported problems (which I can reproduce) with some NFS mounts failing during boot. This occured because mount_nfs thought the host name lookup returned a definitive failure using a non-dotted host name when, in fact, it timed out on the first part (host.search.domain.name) and got a definitive host-not-found response on the second part (host.). Generally speaking, search path name server timeouts can exceed 60 seconds per element and most machines which consistently timeout on earlier portions of a search path are effectively non-operational due to the imposed delays. It is more important for DNS lookups to return the proper error code then to be able to recover a valid lookup in later portions of the search path in these situations. Revision Changes Path 1.3 +19 -6 src/lib/libc/net/res_query.c http://www.dragonflybsd.org/cvsweb/src/lib/libc/net/res_query.c.diff?r1=1.2&r2=1.3&f=h