Date: Tue, 7 Sep 2004 16:00:48 GMT From: Yar Tikhiy <yar@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/62139: User cannot login through telnet or ssh because of reverse resolving delay Message-ID: <200409071600.i87G0mar026870@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/62139; it has been noted by GNATS. From: Yar Tikhiy <yar@FreeBSD.org> To: Rostislav Krasny <rosti_bsd@yahoo.com> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: bin/62139: User cannot login through telnet or ssh because of reverse resolving delay Date: Tue, 7 Sep 2004 19:52:29 +0400 On Wed, Sep 01, 2004 at 09:25:25AM -0700, Rostislav Krasny wrote: > > > To my mind, this is a host configuration issue. First, you > > may list multiple nameservers in your resolv.conf so that > > should one of them fail, the others will still respond to > > queries. Second, the resolver timeout and attempts may be > > set to a lower value (see resolver(5) for details) if your > > network can suffer from all its nameservers being unavailable. > > Please also note that some ways of ssh authentication may > > rely on a name service being available. > > I think that resolver(3) is buggy. Consider the tests described below, > that I've done. > > > uname -a > FreeBSD localhost 5.3-BETA2 FreeBSD 5.3-BETA2 #1: Sat Aug 28 21:29:15 > UTC 2004 root@mack.dcsl.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > > > I changed the /etc/resolv.conf file, so it had only one following line: > > nameserver 21.21.21.21 > > Then I ran a 'date ; ping yahoo.com ; date' one line command four > times. This way I measured the time between 'ping yahoo.com' started > and failed. The results are: > > N mm:ss > 1 2:30 > 2 2:31 > 3 2:31 > 4 2:30 > > Why it taked so long time with default "options" settings? It's because the resolver library tries hard to perform its job reliably. You may like to read RFC 1536 for the discussion of the algorithm used. Also note that resolver will try to add the local domain name as found in the hostname if it is unable to resolve a name as-is. > According to man sshd_config: > > LoginGraceTime > The server disconnects after this time if the user has not suc- > cessfully logged in. If the value is 0, there is no time > limit. > The default is 120 seconds. > > So this is not surprising why my attempts connecting to this box from > another one by ssh failed with following sshd error: > > Aug 31 00:18:06 localhost sshd[1443]: fatal: Timeout before > authentication for 192.168.1.1 > > Workaround of this problem was seting 'UseDNS no' in > /etc/ssh/sshd_config file. But I still don't know what the workaround > of the same problem with ftpd (enabled in /etc/inetd.conf). > > > Then I ran 'tcpdump -nvi ed1' in a second pseudo-terminal and counted a > number of "A? yahoo.com" requests during a run of the above 'ping > yahoo.com'. With default "options" settings my box is sending 8 "A? > yahoo.com" requests to one DNS before 'ping yahoo.com' is failed. Why > there are so many requests to one non-working DNS? Since you never know in advance how many times the program you are trying, e.g., ping, calls the resolver functions. > Finally I add a custom "options" settings line in /etc/resolv.conf > file: > > options attempts:1 > > With this option my box is sending 2 "A? yahoo.com" requests. With > 'attempts:2' it sends 4 requests, with 'attempts:3' it sends 6 > requests, with 'attempts:5' it sends 10 requests... and so on. Why the > numbers of actual requests are double of the defined numbers? It means that ping seems to call the resolver twice each time. > What is the default value of the 'attempts' option? The resolver(5) man > page states that the default value is defined by RES_DFLRETRY in > <resolv.h>. But there is no RES_DFLRETRY in /usr/include/resolv.h file. > In other systems the RES_DFLRETRY is defined as 2. RES_MAXRETRY. 5. The man page seems to give a wrong name there. I'll fix it later. > IMHO the default value of the 'attempts' option should be 2 and it must > not be doubled. With the default value of 'timeout' option (5 seconds) > it should take no more than 10 seconds to decide that one DNS is > unreachable or not. You are misinterpreting the `timeout' option. See RFC 1536 or the code. And `attempts' is not doubled, that is a consequence of the application behaviour. I feel that losing all DNS servers is just slightly better than losing the network connection at all. Therefore console access to such machine is the answer. Trying to overcome that in software is too risky, at least for the default configuration. I'd rather close this PR. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409071600.i87G0mar026870>