We have a linux box (called jumper) that is used to access servers in a few separate DMZs. Each DMZ has its own subdomain name (e.g. idmz.example.org, jdmz.example.org), and each subdomain has its own authoritative name server.
We're in the process of replacing the old Solaris jumper with a new Linux box. Most things have worked well, but we have a problem with connecting to servers in the subdomain idmz.example.com using SSH. Ping works fine; we can resolv the name using dig, but SSH says "Could not resolve".
Name resolution works well on the server side, and when we connect using the IP address there is no delay or timeout. But SSH on the client side claims to not be able to resolve the server.
Ping and failed SSH connection:
jenny@jumper$ ping server.idmz.example.com
PING server.idmz.example.com (192.168.1.3) 56(84) bytes of data.
jenny@jumper$ ssh -v server.idmz.example.com
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
ssh: Could not resolve hostname server.idmz.example.com: Name or service not known
Successful SSH connection using IP instead of host name:
jenny@jumper$ ssh 192.168.1.3
jenny@192.168.1.3's password:
The one difference I can see from the client side is that I can't get an authoritative answer from the name servers for idmz, but I do get it from all the other DMZ domains.
Answer
We contacted the sysadmins for the DNS servers and asked them to verify the setup for idmz. It turned out that their name server claimed to handle IPV6, but it didn't give a correct answer for IPV6 queries.
On the Solaris server, IPV4 was used by default. On the new Linux server, SSH tried IPV6 first. In this case, it meant that since it couldn't resolve the servername using IPV6 it considered it unresolvable. For the other dmz domains, the nameserver gave correct responses even when using IPV6.
We changed the config for SSH to include
AddressFamily inet
and the problem went away.
No comments:
Post a Comment