From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: The Openssh client will make a series of DNS queries when a user uses ssh to connect to an unqualified short name on a LAN. Some of the IPv6 queries are fed to the name server defined in resolv.conf as if they were a TLD query, which gets bogus traffic forwarded to the root DNS servers. For example: ssh user@hostname resolv.conf: domain sub.domain.com nameserver 192.1.1.2 Packet capture: 13:39:40.375681 192.1.1.252.34288 > 192.1.1.2.domain: 57759+ AAAA? hostname.sub.domain.com. (45) (DF) 13:39:40.376425 192.1.1.252.34288 > 192.1.1.2.domain: 57760+ AAAA? hostname. (25) (DF) 13:39:40.395541 192.1.1.252.34288 > 192.1.1.2.domain: 57761+ A? hostname.sub.domain.com. (45) (DF) The second packet is the problem, as the name server will interpert this as a TLD lookup, causing bogus root name server traffic. We use ssh extensively in our internal apps, with thousands of ssh sessions being established per day. As this bug seems widespread, I can only imagine what the global impact on root name server traffic is. In addition to the impact on root server traffic, this problem will cause a 10 second delay in any ssh connections if the local DNS server loses connectivity to the outside world for some reason. This is how this problem was discovered, our Internet connection failed, and suddenly internal SSH connections took 10 seconds longer. This happens as the DNS server waits for two 5 second timeouts for the second query listed above. Version-Release number of selected component (if applicable): All versions it seems. How reproducible: Always Steps to Reproduce: Outlined above. Additional info:
Stuff I forgot: Using ssh -4 is a workaround for this. Thanks to Skapere on #dns on irc.freenode.net for helping me disgnose this bug.
Also entered as: http://bugzilla.mindrot.org/show_bug.cgi?id=924
------- Additional Comments From djm 2004-09-04 08:28 ------- OpenSSH just uses the standard getaddrinfo() API, it doesn't do anything magical for DNS queries. Any complaints about getaddrinfo()'s behaviour on your system should be directed to your libc vendor. BTW, you can turn off IPv6 lookups by setting "AddressFamily inet" in your ssh_config.
Many fixes have gone into our newest Fedora Core 3 test2 release, please re-test with that and open a requests if you find further problems. Thanks, Florian La Roche
A tcpdump on queries from FC3t2 gave me AAAA host AAAA host.subdomain A host A host.subdomain
The output from #5 is certainly correct. I'm closing the bug.
Why is that "certainly correct"? Can you give any reference to any standard which mandates this behaviour?
From what I see, the new order is even worse. Sending AAAA host. (fail because there's no TLD named host) AAAA host.sumdomain. (fail because most people don't run IPv6) A host. (fail because there's no TLD named host) A host.subdomain (probably success) So this new scenario actually creates twice as much bogus traffic for the root name servers!
If someone queries a non-dotted (or with few dots, see the ndots option in resolv.conf) the DNS server is always queried for a short name since it might know about CNAMEs matching this. This is how it always has been. And the order of the results returned by getaddrinfo() is determined according to the rules in RFC 3494. If you don't want IPv6 addresses to be returned, make sure you use AI_ADDRCONFIG and remove all IPv6 addresses from all your interfaces. The behavior is correct, I have not seen anything to the contrary. Provide up-to-date and detailed information about what you think is wrong.
>>determined according to the rules in RFC 3494. What does the version history of LDAP have to do with anything? The default for ndots is 1. If I "ssh sysadm@host" there are exactly zero dots in my request. Yet the resolver still tries to resolve an absolute name, the TLD "host.", causing root name server traffic for absolutely no valid reason.
It's RFC 3484, typo.
Fine, if you all want to refuse to acknowdge this bug so bad, I don't care anymore. I'm not going to argue about something that is so obviously broken to everyone who doesn't have an email that ends with @redhat.com.
This bug was silently fixed. It is no longer present in FC3.