ssh slow on Leopard.
2008-02-04 15:06:19
I thought I was going crazy, but I'm not. ssh to a host the first time is super slow on leopard.
This thread on apple forums has a lot of false leads, but includes the true cause:
"Assuming you are referring to problems when ssh-ing from a Leopard box to other systems, then the problem is probably the new behavior of the getaddrinfo() call in Leopard. Basically, that call in Leopard now uses the RFC-recommended practice of first issuing a DNS SRV record request rather than an A record request, and then falling back to the A record request if the SRV request fails; unfortunately, apparently a lot of DNS servers don't respond to the SRV request w/ an NXDOMAIN as they should, and instead just drop the request, so getaddrinfo() retries the SRV request a few times, and only after those requests time out does it try to A request. So if ssh is using getaddrinfo() rather than gethostbyname/getservbyname, then you it would hang like you describe whenever you are pointing to a DNS server that doesn't respond well to the SRV request. (There are also reports that Leopard may generate DNS requests w/ an invalid RR type, which might explain why the servers being queried aren't responding to them correctly.) The easiest way to check if that's your problem would be to sniff traffic on port 53 while trying an ssh connection, and seeing if your box is making a SRV request or an A request. (If that is in fact your problem, you may be SOL until a patch is released, as Googling, I don't see any solutions other than hacking individual apps to use gethostbyname() instead of getaddrinfo().)" I did monitor port 53 and it is making SRV requests.
I have not yet found a good way to workaround this behavior.
Another good discussion of this is here.
This seems kinda stupid to me, since we use bind for our DNS here at work. If a vanilla bind config doesn't answer SRV requests properly, it seems bad to build them into the default behavior of a major client (like ssh).
Update: we upgraded all our DNS servers here at work, and they all repond to SRV requests properly, and now everything works great.