From owner-freebsd-stable@FreeBSD.ORG Wed Feb 22 00:44:48 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 932A616A420 for ; Wed, 22 Feb 2006 00:44:48 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id E829643D53 for ; Wed, 22 Feb 2006 00:44:46 +0000 (GMT) (envelope-from rosti.bsd@gmail.com) Received: by zproxy.gmail.com with SMTP id o37so1293983nzf for ; Tue, 21 Feb 2006 16:44:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=BYXhR0b1grIlvDF+eQRBZzI2lGO33LTqIy2OzmeX1n5CxcIySTuB7Vwrm5xvDOriOCjCfqPJxXqjHz+oKmMF23kEoyhcP6PlUAEHUp/45WHPVRs2P0lH/5jxDto7w9bcDZoQj6RcKn0ZVUsZz59L90sXMOwmBmpx1W9d9YDlfJ0= Received: by 10.65.152.9 with SMTP id e9mr805572qbo; Tue, 21 Feb 2006 16:44:45 -0800 (PST) Received: from saturn.lan ( [212.143.154.227]) by mx.gmail.com with ESMTP id e16sm4792016qba.2006.02.21.16.44.42; Tue, 21 Feb 2006 16:44:45 -0800 (PST) Date: Wed, 22 Feb 2006 02:44:30 +0200 From: Rostislav Krasny To: Yar Tikhiy Message-Id: <20060222024430.ad4b5c60.rosti.bsd@gmail.com> In-Reply-To: <20060221165959.GB77513@comp.chem.msu.su> References: <59e2ee810512250841t75157e62rec9dc389ac716534@mail.gmail.com> <20051227101621.GA16276@walton.maths.tcd.ie> <86irrfoix5.fsf@xps.des.no> <20060218012029.e146e2ff.rosti.bsd@gmail.com> <20060219104912.GB20500@comp.chem.msu.su> <20060219225701.0e3e244b.rosti.bsd@gmail.com> <20060221165959.GB77513@comp.chem.msu.su> X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-stable-local@be-well.ilk.org, dwmalone@maths.tcd.ie, des@des.no, mak@ll.mit.edu, MH@kernel32.de Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2006 00:44:48 -0000 On Tue, 21 Feb 2006 19:59:59 +0300 Yar Tikhiy wrote: > On Sun, Feb 19, 2006 at 10:57:01PM +0200, Rostislav Krasny wrote: > > On Sun, 19 Feb 2006 13:49:12 +0300 > > Yar Tikhiy wrote: > > > > > On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote: > > > > On Thu, 16 Feb 2006 08:35:18 +0100 > > > > des@des.no (Dag-Erling Sm??rgrav) wrote: > > > > > > > > > David Malone writes: > > > > > > I did once mail des@ to ask him if he'd mind me changing the default > > > > > > login timeout for sshd to be (say) 5 minutes rather than 1 minute, > > > > > > but I think he was busy at the time. Judging by the PR mentioned > > > > > > above it should be at least 2m30s by default. Des, would you mind > > > > > > this change being made? > > > > > > > > > > No objection, just let me see the patch first. > > > > > > > > In conjunction to what David had proposed, what do you think about > > > > decreasing the RES_DFLRETRY from 4 to 2, like in other systems and in > > > > BIND9's resolver? > > > > > > Could you try this change in your system and report the exact > > > results, such as output from tcpdump? That is how we could judge > > > the change in question... Or were the results reported already? > > > > Ok, I rebuilded the world and the kernel with this change and tested it > > with tcpdump and a small program from the bin/62139 PR. During the test > > I saw two "A? yahoo.com." requests, then two "A? yahoo.com.lan." > > requests and that all taked only 30 seconds for gethostbyname() to give > > up with one unreachable DNS. Now it looks better than before. > > > > But I think there is still a bug. If I change hostname from "saturn.lan" > > to just "saturn" I see 4 "A? yahoo.com." requests, like in the PR with > > "options attemts:2". Why it tries to repeat the requests when the domain > > name is empty and so is the search list by default? That is the > > doubling I had wrote about in the PR. > > The "doubling" happens only to name->IP lookups, but not to reverse > lookups, according to my observations. Therefore DNS requests by > sshd and friends shouldn't be affected. However, sshd will make 3 > (!) lookups on the client IP address by itself. I wonder if there > is a good reason for that. I forgot that a "search" resolver(5) parameter is useless for reverse resolving. But that "doubling" of name->IP requests with an empty (or root, according to resolver(5)) domain in the "search" is still a bug, IMHO. Although it shouldn't affect the sshd. This time I used following program with a couple of date(1) to measure the reverse lookup failure time with one unreachable DNS: #include #include #include #include #include #include int main(int argc, char *argv[]) { struct hostent *ps_hostent; struct in_addr b_addr; if (argc == 2 && inet_aton(argv[1], &b_addr)) { ps_hostent = gethostbyaddr((void *)&b_addr, 4, AF_INET); if (ps_hostent != NULL) { printf("%s\n", ps_hostent->h_name); } else { herror(argv[1]); } } else { fputs("No valid argument.\n", stderr); } return 0; } On my system, builded with RES_DFLRETRY defined as 2, it taked only 15 seconds for gethostbyaddr() to fail, after two DNS requests. To emulate the old behavior I added "options attempts:4" to /etc/resolv.conf. With that configuration it taked already one minute more (1:15) for gethostbyaddr() to fail. Therefore three calls of gethostbyaddr(), when RES_DFLRETRY defined as 2, are better than even one call of the same function when RES_DFLRETRY defined as 4. > I also found that the second round of the "doubling" would use the > first domain from `search' line if it is in resolv.conf. The rest > of domains specified on `search' line are ignored. Hoping this > observation will come useful, should somebody want to fix this bug. Alternatively FreeBSD could switch to a BIND9's resolver, like NetBSD did in 2004. BIND9 is already in the base system.