Name resolution not hitting the /etc/hosts file

theillien · October 10, 2014, 3:26am

I have a 13.1 VM which I use for work. My hosts file is a massive list of every server in our environment (currently more than 2500 lines). Until recently I was able to simply type “ssh <hostname>” and be connected. In one specific case, I have an entry called mt01. Now, when I attempt to access this server I get “ssh: Could not resolve hostname mt01: Name or service not known”

I’ve tried netconfig update -f and it had worked a couple times. Not so much, now.

How do I force name resolution to use my hosts file first? Why would it have changed? Does the size of the file cause a problem?

My nsswitch.conf file

passwd: compatgroup:  compat


hosts:  	files mdns_minimal [NOTFOUND=return] dns
networks:	files dns


services:	files
protocols:	files
rpc:		files
ethers:		files
netmasks:	files
netgroup:	files nis
publickey:	files


bootparams:	files
automount:	files nis
aliases:	files

nrickert · October 10, 2014, 4:10am

With 2500 lines in your hosts file, you might do better to set up a private DNS domain.

Is this only an ssh problem? What happens if you try:


telnet hostname
ping hostname

Do those commands also report bad hostname? Or do they try (and perhaps fail) to send packets?

If this only applies to ssh, then look at your ssh configuration, both “/etc/ssh/ssh_config” and “$HOME/.ssh/config”.

theillien · October 10, 2014, 4:23am

nrickert:

With 2500 lines in your hosts file, you might do better to set up a private DNS domain.

Is this only an ssh problem? What happens if you try:
telnet hostname
ping hostname
Do those commands also report bad hostname? Or do they try (and perhaps fail) to send packets?

If this only applies to ssh, then look at your ssh configuration, both “/etc/ssh/ssh_config” and “$HOME/.ssh/config”.

Results of tests:

opensuse13-1:~:3098 $ telnet mt01
telnet: mt01: Name or service not known
opensuse13-1:~:3099 $ ping mt01
ping: unknown host mt01

hosts file entry:

opensuse13-1:~:3102 $ grep mt01 /etc/hosts
10.153.156.3    mt01

hcvv · October 10, 2014, 9:10am

Do I understand you correctly that it only fails on mt01, that is on only that one of the 2500+ entries?

When yes, please try to reflect on what could be special/different about that one.

theillien · October 10, 2014, 9:46am

It’s just an example. It happens with every server I’ve tested.

jetchisel · October 10, 2014, 9:56am

theillien:

Results of tests:

opensuse13-1:~:3098 $ telnet mt01
telnet: mt01: Name or service not known
opensuse13-1:~:3099 $ ping mt01
ping: unknown host mt01

hosts file entry:

opensuse13-1:~:3102 $ grep mt01 /etc/hosts
10.153.156.3    mt01

Well are you still on the same subnet as your servers? can you access them via ip only?

theillien · October 10, 2014, 10:04am

I am not on the same subnet and I can access all servers using IP.

hcvv · October 10, 2014, 10:32am

Sorry, I misundestood, it was not completly clear to me, thus the asking.

hcvv · October 10, 2014, 10:37am

I do not thinkit has anything to to with the supnet. It is a bout resolving a hostname into an IP address. If that IP address is valid *un)reachable, etc. is of no ineterest.

What is used in resolving is defined in /etc/resolv.conf. You could check what is in there. In mine (and I never changed something there) is;

henk@boven:/etc> grep hosts /etc/nsswitch.conf
hosts:          files mdns_minimal [NOTFOUND=return] dns
henk@boven:/etc>

hcvv · October 10, 2014, 10:43am

Maybe better to add that I do have entries in /etc/hosts and that they function:

henk@boven:~> grep beneden /etc/hosts
10.0.0.155      beneden.henm.xs4all.nl beneden
henk@boven:~> ping -c1 beneden
PING beneden.henm.xs4all.nl (10.0.0.155) 56(84) bytes of data.
64 bytes from beneden.henm.xs4all.nl (10.0.0.155): icmp_seq=1 ttl=64 time=0.350 ms

--- beneden.henm.xs4all.nl ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.350/0.350/0.350/0.000 ms
henk@boven:~>

theillien · October 10, 2014, 10:54am

That’s my fault. I realized that it was unnecessary to put that in the original post. But it was too late to edit it, though.

theillien · October 10, 2014, 11:00am

hcvv:

I do not thinkit has anything to to with the supnet. It is a bout resolving a hostname into an IP address. If that IP address is valid *un)reachable, etc. is of no ineterest.

What is used in resolving is defined in /etc/resolv.conf. You could check what is in there. In mine (and I never changed something there) is;
henk@boven:/etc> grep hosts /etc/nsswitch.conf
hosts:          files mdns_minimal [NOTFOUND=return] dns
henk@boven:/etc>

The file you’ve cited is the nsswitch.conf file. I included that in my original post.

As for my resolv.conf file, I have the Google DNS IP (8.8.8.8). If I include the DNS IPs for the network I’m connecting to it works. Which is fine. Certainly a functioning solution. However, it doesn’t actually sold the problem of the hosts file being ignored as a name resolution resource.

hcvv · October 10, 2014, 11:19am

Yes, I want to talk about nsswitch.conf.

It works flawless in my situation (for years). Strange thyt it stopped at yours. I know it is something you are trying to find out already for some time: what was changed “recently”.

ab · October 10, 2014, 1:29pm

Silly other command to try:


getent ahosts mt01

Perhaps also try it with other lines from your /etc/hosts file, preferably
the ones earlier in the file.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

robin_listas · October 10, 2014, 2:33pm

On 2014-10-10 10:06, theillien wrote:
>
> jetchisel;2668704 Wrote:
>> Well are you still on the same subnet as your servers? can you access
>> them via ip only?
>
> I am not on the same subnet and I can access all servers using IP.
>
>

I added to my /etc/hosts:


192.168.1.100   mt01
10.153.156.3    mt02

then tried (both IPs do not exist here):


Telcontar:~ # host mt01
Host mt01 not found: 3(NXDOMAIN)
Telcontar:~ # ping mt01
PING mt01 (192.168.1.100) 56(84) bytes of data.
^C
--- mt01 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Telcontar:~ # ping mt02
PING mt02 (10.153.156.3) 56(84) bytes of data.
^C
--- mt02 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

Telcontar:~ #

which is as it should be.


Telcontar:~ # cat /etc/resolv.conf | egrep -v "^:space:]]*$|^#"
search valinor
nameserver 192.168.1.14
Telcontar:~ #
Telcontar:~ # cat /etc/nsswitch.conf | egrep -v "^:space:]]*$|^#"
passwd: compat
group:  compat
hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files dns
services:       files
protocols:      files
rpc:            files
ethers:         files
netmasks:       files
netgroup:       files nis
publickey:      files
bootparams:     files
automount:      files nis
aliases:        files
Telcontar:~ #

Of course, I do not have thousands of entries in the hosts file, but
that should not be a problem, either. Maybe there is a syntax error in
the file and it is not read in full.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

tsu2 · October 10, 2014, 5:59pm

An extremely large Hosts file as large as you describe is unusual.

Recommend trying the following…

Cut/Paste the existing Hosts file entry from wherever it is, re-position at or near top of the Hosts file.
Cut/Paste or re-create the Hosts file entry with the text in a command, this should hopefully avoid hidden characters which can be introduced using a graphical text editor. In fact, try to avoid using graphical text editors completely when troubleshooting faulty text files.
If this Hosts file is used on multiple machines, are y ou using the same file on every machine? Are there any machines which don’t use this Hosts file?
Test using another Hosts file. You can disable it by renaming to something else, like appending a “.original” to the file, then re-creating a new Hosts file. If your new file works, then you can copy/paste blocks of entries from your old file to your new until you find the problem re-occurs, which would narrow down the circumstances causing your Hosts file to fail.
If your Hosts file is used on multiple machines, I’d recommend you consider using DHCP to centrally manage your Hosts file, you can push the single master copy to any/all your client machines automatically and refresh the file on bootup (or DHCP renew lease).

HTH,
TSU

robin_listas · October 10, 2014, 6:33pm

On 2014-10-10 18:06, tsu2 wrote:
>
> An extremely large Hosts file as large as you describe is unusual.

An alternative is to use dnsmasq.

You can have a smallish hosts file, which is what the system reads, and
a huge, auxiliary file, which is only read and served by dnsmasq
(–addn-hosts). Entries are cached and answers are fast, and it also
caches external (to the machine) dns entries.

It is possible that dnsmasq does some syntax checking on start/reload.

Editing hosts file is easier than a real bind…

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

robin_listas · October 10, 2014, 6:38pm

On 2014-10-10 18:33, Carlos E. R. wrote:

> It is possible that dnsmasq does some syntax checking on start/reload.

Yes, found it, see “–test”.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

theillien · October 10, 2014, 9:08pm

mt01 is already the first item in the file.

Cut/Paste or re-create the Hosts file entry with the text in a command, this should hopefully avoid hidden characters which can be introduced using a graphical text editor. In fact, try to avoid using graphical text editors completely when troubleshooting faulty text files.

I only use vim

If this Hosts file is used on multiple machines, are y ou using the same file on every machine? Are there any machines which don’t use this Hosts file?

I only use it on this system.

Test using another Hosts file. You can disable it by renaming to something else, like appending a “.original” to the file, then re-creating a new Hosts file. If your new file works, then you can copy/paste blocks of entries from your old file to your new until you find the problem re-occurs, which would narrow down the circumstances causing your Hosts file to fail.

Preliminary tests work. This indicates an issue with the hosts file. I will slowly add back systems that I use regularly and rely on an intermediary (mt01) in the remote environment as my jumping off point for other systems.

If your Hosts file is used on multiple machines, I’d recommend you consider using DHCP to centrally manage your Hosts file, you can push the single master copy to any/all your client machines automatically and refresh the file on bootup (or DHCP renew lease).

Seems a bit of a PITA to deal with a problem on a single computer.

HTH,
TSU[/QUOTE]