[sf-lug] curious name resolving problem

Rick Moen rick at linuxmafia.com
Mon Feb 25 20:59:21 PST 2013


Quoting Alex Kleider (a_kleider at yahoo.com):

> I've got a puzzling situation in which ping works but ssh can't resolve a url.
> Can anyone suggest how this can be? I reckon if I understood that, I might be able to fix it.

Something broken about your local DNS daemon.  And here's a guy who had
the same problem:

https://bbs.archlinux.org/viewtopic.php?id=147460

So, this is just a guess, but I think it''s a good one.  I'm betting
that it's a matter of your local DNS nameserver not fully supporting
IPv6, and your ssh just happens to throw a tantrum and refuse to work
because there's no 'AAAA' (IPv6) DNS record response from the
nameserver, just an 'A' (IPv4) one -- whereas your ping client just
doesn't care, and is perfectly content to receive just an 'A' response.

Thus, your problem went away when you repointed /etc/resolv.conf to
208.201.224.33 & 208.201.224.11 because of the coincidence of those
nameservers giving full dual-stack (IPv4 and IPv6) responses, whereas
your own nameserver didn't.  Or something like that.


If you put your nameserver back into /etc/resolv.conf as the sole
nameserver, and then re-try your ssh test using a '-4' option, I'll bet
the ssh session suddenly will work.

SSH(1)                         BSD General Commands Manual


NAME
     ssh -- OpenSSH SSH client (remote login program)
[...]
     -4      Forces ssh to use IPv4 addresses only.

     -6      Forces ssh to use IPv6 addresses only.

IPv6 vs. IPv4 issues can make you want to tear your hair out -- or do
something rash like

sudo su -
echo  'net.ipv6.conf.eth0.disable_ipv6 = 1' > /etc/sysctrl.d/disable-ipv6.conf
echo  'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctrl.d/disable-ipv6.conf
sysctl -p
exit


...and thereby disable IPv6 _entirely_ making all IPv6 problems go away.
However, that's a bit short-sighted.






More information about the sf-lug mailing list