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?

2 Answers 2

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..|
3
  • 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
    Commented Aug 23, 2019 at 23:48
  • thank you, cas—It was indeed the carriage return.
    – karlsebal
    Commented Aug 27, 2019 at 7: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 Commented Dec 3, 2021 at 10:33
0

Here is a solution to a version of this problem that has (almost?) identical symptoms.

In short:

In my case, I was using systemd-networkd, and name resolution wasn't working. Also, /etc/resolv.conf had different nameservers in than what is returned by our DHCP servers (although they were reachable).

Here's what I did:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/stub-resolv.conf /etc/resolv.conf
sudo systemctl start systemd-resolved.service

Note: I don't know if that systemctl command is "permanent." I suspect something needs to be done to make starting that service on boot. I'm relatively inexperienced with Linux, and the above got me to where I needed to be.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .