Bug 131610 - SSH causing invalid DNS queries to root servers.
SSH causing invalid DNS queries to root servers.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
1
All Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-02 13:48 EDT by Gigs
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-28 18:59:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gigs 2004-09-02 13:48:14 EDT
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:
Comment 1 Gigs 2004-09-02 15:37:15 EDT
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.
Comment 2 Gigs 2004-09-03 09:37:34 EDT
Also entered as:
http://bugzilla.mindrot.org/show_bug.cgi?id=924
Comment 3 Gigs 2004-09-04 20:08:06 EDT
------- Additional Comments From djm@mindrot.org  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.
Comment 4 Florian La Roche 2004-09-26 04:49:48 EDT
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
Comment 5 Carlos Morgado 2004-09-27 15:05:10 EDT
A tcpdump on queries from FC3t2 gave me 

AAAA host
AAAA host.subdomain
A host
A host.subdomain
Comment 6 Ulrich Drepper 2004-09-27 23:52:16 EDT
The output from #5 is certainly correct.  I'm closing the bug.
Comment 7 Daniel Roesen 2004-09-28 05:50:09 EDT
Why is that "certainly correct"? Can you give any reference to any
standard which mandates this behaviour?
Comment 8 Gigs 2004-09-28 09:55:44 EDT
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!
Comment 9 Ulrich Drepper 2004-09-28 18:59:42 EDT
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.
Comment 10 Gigs 2004-09-29 13:29:40 EDT
>>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.
Comment 11 Ulrich Drepper 2004-09-29 13:55:16 EDT
It's RFC 3484, typo.
Comment 12 Gigs 2004-09-29 14:34:50 EDT
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.
Comment 13 Gigs 2005-04-06 16:17:14 EDT
This bug was silently fixed.  It is no longer present in FC3.

Note You need to log in before you can comment on or make changes to this bug.