SSH login takes very long time...sometimes

[Rostislav Krasny]

On Tue, 21 Feb 2006 19:59:59 +0300
Yar Tikhiy <yar at comp.chem.msu.su> 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 <yar at comp.chem.msu.su> wrote:
> > 
> > > On Sat, Feb 18, 2006 at 01:20:29AM +0200, Rostislav Krasny wrote:
> > > > On Thu, 16 Feb 2006 08:35:18 +0100
> > > > des at des.no (Dag-Erling Sm??rgrav) wrote:
> > > > 
> > > > > David Malone <dwmalone at maths.tcd.ie> 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 <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>

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.