Red Hat Bugzilla – Bug 131610
SSH causing invalid DNS queries to root servers.
Last modified: 2007-11-30 17:10:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
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
13:39:40.375681 18.104.22.168.34288 > 22.214.171.124.domain: 57759+ AAAA?
hostname.sub.domain.com. (45) (DF)
13:39:40.376425 126.96.36.199.34288 > 188.8.131.52.domain: 57760+ AAAA?
hostname. (25) (DF)
13:39:40.395541 184.108.40.206.34288 > 220.127.116.11.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.
Steps to Reproduce:
Stuff I forgot:
Using ssh -4 is a workaround for this.
Thanks to Skapere on #dns on irc.freenode.net for helping me disgnose
Also entered as:
------- Additional Comments From firstname.lastname@example.org 2004-09-04 08:28 -------
OpenSSH just uses the standard getaddrinfo() API, it doesn't do
for DNS queries. Any complaints about getaddrinfo()'s behaviour on
should be directed to your libc vendor.
BTW, you can turn off IPv6 lookups by setting "AddressFamily inet" in your
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
Florian La Roche
A tcpdump on queries from FC3t2 gave me
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.
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
This bug was silently fixed. It is no longer present in FC3.