3

I upgraded a few machines to Debian Buster and everything went well so far—although when running apt upgrade before apt full-upgrade I ran into a Temporary failure in name resolution. This was fixable and only an issue during the process and did not occur when doing a one-step apt dist-upgrade. However one machine shows this behaviour in spite of being fully upgraded. I get

~# LANG=C ping google.com
ping: google.com: Temporary failure in name resolution

When I add google.com to /etc/hosts everything is fine. My /etc/nsswitch looks like

~# cat /etc/nsswitch.conf 

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files dns
networks:       files

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

netgroup:       nis

My /etc/resolv.conf points to googles nameserver at the moment and the very server is pingable

~# cat /etc/resolv.conf 

nameserver 8.8.8.8

~# ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=22.8 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.800/22.800/22.800/0.000 ms

systemd-resolved is inactive and should not be an issue if I am interpreting the content of my /etc/nsswitch correctly.

Could there be another point I missed?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
karlsebal
  • 795
  • 8
  • 20

1 Answers1

3

Installing nslookup pointed me to the source of the problem: resolv.conf was simply not parseable. I copied the contents from the original file into a new one and everything works. Same content, same permissions. But diff shows a difference where is none. Apparently there is some invisible character breaking the file since it is 1 Byte larger

/etc# diff resolv.conf.odd resolv.conf.dem
1c1
< nameserver 8.8.8.8
---
> nameserver 8.8.8.8
/etc# cat resolv.conf.odd && cat resolv.conf.dem
nameserver 8.8.8.8
nameserver 8.8.8.8
/etc# ls -l resolv.conf.*|cut -d' ' -f5,9
19 resolv.conf.dem
20 resolv.conf.odd

Update: As cas thankfully pointed out it was a trailing \r causing the mayhem and had nothing to do with the Buster Update itself. A coworker had pushed the file with wrong line wrappings

$ hd resolv.conf.odd
00000000  6e 61 6d 65 73 65 72 76  65 72 20 38 2e 38 2e 38  |nameserver 8.8.8|
00000010  2e 38 0d 0a                                       |.8..|
karlsebal
  • 795
  • 8
  • 20
  • if you're still curious now that you've fixed it, you can find out what the problematic byte is with `cat -V` or a hexdumper like `hd` or `xxd`. My guess is it's probably a carriage-return character (0x0d or \r). – cas Aug 23 '19 at 23:48
  • thank you, cas—It was indeed the carriage return. – karlsebal Aug 27 '19 at 07:24
  • thank you, just if someone is looking for a quick fix: `a=$(printf "nameserver 8.8.8.8\r"); echo $a >/etc/resolv.conf ` – Marcin Kawka Dec 03 '21 at 10:33