Wednesday, May 1, 2024
 Popular · Latest · Hot · Upcoming
13
rated 0 times [  13] [ 0]  / answers: 1 / hits: 41718  / 3 Years ago, fri, september 3, 2021, 6:07:14

I'm trying to connect from a 10.04 system to a 12.04 system via SSH. Strangely enough the rules in resolv.conf seem to take effect only selectively, which leaves me puzzled. Observe:



[2] user@mach:~$ ssh pangolin
ssh: Could not resolve hostname pangolin: Name or service not known
[2] user@mach:~$ host pangolin
pangolin.subdomain.domain.tld has address 172.16.7.12


subdomain.domain.tld is on the search line in /etc/resolv.conf and using host the name is properly searched given those rules. However, with the SSH client ssh I receive the error reproduced above. How can this be? I was always of the impression that the name resolution rules in resolv.conf apply system-global.



Note: /etc/hosts doesn't declare the name pangolin at all. The package openssh-server is configured on the target machine. The question is purely about why name resolution isn't consistent between those two programs.



Another note: the command works fine when I enter the fully-qualified domain name, i.e. pangolin.subdomain.domain.tld.



Meanwhile I rebooted the client machine (10.04) and the problem still exists. A DNS caching daemon isn't installed, so I reckon that shouldn't have been a problem anyway.






The information asked for in the comment:



$ grep host /etc/nsswitch.conf
hosts: files dns


/etc/resolv.conf, I transformed the domain names consistently:



# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.1.1
nameserver 172.16.1.5
search subdomain.domain1.com domain1.com domain2 domain3.com domain2.ccTLD domain3.net dev.domain1.com sdk.dev.domain1.com


... and the full /etc/nsswitch.conf:



$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group: compat
shadow: compat

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis


... and /etc/network/interfaces, which is the source for resolv.conf in 12.04:



# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 172.16.1.234
netmask 255.255.0.0
gateway 172.16.255.254
dns-nameservers 172.16.1.1 172.16.1.5
dns-search domain1.com. domain2. domain3.com. domain2.ccTLD. domain3.net. dev.domain1.com. sdk.dev.domain1.com. subdomain.domain1.com.
dns-domain subdomain.domain1.com.


Note: the transformation of the domain names was done with sed, so it's consistent between the various reproduced files.






There is no ~/.ssh/config, but here's the global one (/etc/ssh/ssh_config), shrunk for the sake of brevity:



$ grep -v '^#' /etc/ssh/ssh_config |grep -v '^[[:space:]]*$'
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no





$ mtr pangolin
Name or service not known: Success

More From » 12.04

 Answers
7

Whereas ssh and other programs such as ping use the glibc resolver to look up the host name ('pangolin' in this case), host looks the name up in DNS directly, bypassing the glibc resolver. That's the difference.



However, given that the glibc resolver is, on your machine, configured to try dns after files, I can't explain why the resolver fails where host succeeds.



To try with the glibc resolver, one can use getent hosts ... in place of host ....



I have seen this behavior reported before when dnsmasq was used as a local forwarding nameserver (https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/998712) but you aren't using such a local nameserver; but perhaps the problem there and here wasn't in dnsmasq but in the glibc resolver.


[#37701] Friday, September 3, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
velelf

Total Points: 395
Total Questions: 115
Total Answers: 107

Location: Sudan
Member since Mon, Jun 1, 2020
4 Years ago
;