[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