[Bug 1860] UseDNS option ignored

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Fri Nov 13 14:59:39 AEDT 2015


https://bugzilla.mindrot.org/show_bug.cgi?id=1860

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WORKSFORME
             Status|NEW                         |RESOLVED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
The bit leading up to this is:

20538:  xgetsockaddr(UW71|XPG4, REMOTENAME, 3, 0x08047ADC, 0x08047B60)
= 0
20538:  gettimeofday(0x08047070, 0xBFF5A870)            = 0
20538:  getpid()                                        = 20538  [
20271 ]
20538:  open("/etc/resolv.conf", O_RDONLY, 0666)        = 4
20538:  ioctl(4, TCGETS, 0x08046F64)                    Err#25 ENOTTY

Which makes me think this is canohost.c:get_remote_hostname(). It does
a getpeername() call that is probably the xgetscoaddr call above. It
then does a:

if (getnameinfo((struct sockaddr *)&from, fromlen, ntop, sizeof(ntop),
    NULL, 0, NI_NUMERICHOST) != 0)

call. This should not result in any DNS traffic though - it's
requesting a numeric hostname.

IMO the only way for it to end up in the DNS here is if the OS
getnameinfo() is buggy. This is further supported by what it does next:

20538:  open("/etc/services", O_RDONLY, 0666)           = 4
20538:  ioctl(4, TCGETS, 0x08047894)                    Err#25 ENOTTY
20538:  fxstat(2, 4, 0x080478D4)                        = 0
20538:  read(4, " # i d e n t\t " @ ( # )".., 8192)     = 4260
20538:  read(4, 0x0814A090, 8192)       

It's not looking at /etc/hosts - it's looking for a port number to
service name lookup and it's doing so in spite of the getnameinfo()
call above not requesting a service name lookup.

So, I think your system has been configured to do service lookups by
DNS *and* your libc/resolver getnameinfo() is broken. There isn't much
we can do in sshd to mitigate this. If it is still failing for you then
I suggest disabling service lookups via DNS and/or contacting your OS
vendor.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list