bin/62139: User cannot login through telnet or ssh because of reverse resolving delay

Yar Tikhiy yar at
Tue Sep 7 09:00:49 PDT 2004

The following reply was made to PR bin/62139; it has been noted by GNATS.

From: Yar Tikhiy <yar at>
To: Rostislav Krasny <rosti_bsd at>
Cc: freebsd-gnats-submit at
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 at 
 > i386
 > I changed the /etc/resolv.conf file, so it had only one following line:
 > nameserver
 > Then I ran a 'date ; ping ; date' one line command four
 > times. This way I measured the time between 'ping' 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
 > 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?" requests during a run of the above 'ping
 >'. With default "options" settings my box is sending 8 "A?
 >" requests to one DNS before 'ping' 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?" 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.

More information about the freebsd-bugs mailing list