You are not logged in.
Hello,
As the title says, I'm having an issue with my DNS configuration.
Every time I suspend or reboot the computer, I find that old DNS entries have been reset in my /etc/resolv.conf file. It also occasionnaly happen without sending the computer to sleep but it's rare and I haven't been able to identify the trigger in those cases.
I'm pretty sure I didn't change anything in dhcpcd's configuration back when I installed Arch or ever since then. So the network configuration is pretty much stock Arch on a single ethernet interface.
No configuration means my IP, DNS servers, etc ... are probably dictated by DHCP server aka my router. But those DNS entries were removed from my router months ago.
I've read about a few workarounds, including for instance making my resolv.conf immutable. But I'm actually more interested in understanding why this is happening and actually fixing it.
I've tried to delete the lease file and the duid file, in order to force a new lease, but it didn't help.
This sums up all that I know of this problem. I'm not very knowledgeable on network, I have a basic understanding of how it works, but so far, everything has always worked right out of the box so I've never had to fiddle too much with it.
I'll be glad if anyone can share ideas as to where I could look, or what I could try to understand this problem and fix it. Let me know if I've forgotten any information that might be useful to diagnose the problem.
Regards.
Last edited by kRYOoX (2016-03-12 00:08:39)
Offline
So the network configuration is pretty much stock Arch on a single ethernet interface.
There is no such thing. "Stock" Arch has no networking enabled, so exactly how did you configure your network? If you don't remember exactly everything you did then we are left trying to discover the current state. Some commands that may help with discovery:
grep hosts /etc/nsswitch.conf
ls -l /etc/resolv.conf
cat /etc/resolv.conf
cat /etc/resolvconf.conf
cat /run/resolvconf/interfaces/*
systemctl -t service --state=active
Offline
Hey branch, thank you for your input.
As far as I can remember, I installed Arch using the Beginner's Guide and never strayed from it. And I have no recollection of encountering any special cases or anything weird.
In my case, when I booted from my USB key with Arch's iso on it, I already had the eno1 interface up and configured. I could ping servers on the internet.
The only thing I ever had to do, following the same guide, was to make it persistent with : systemctl enable dhcpcd@eno1.service
As for the commands you suggested, here's their output :
$ grep hosts /etc/nsswitch.conf
hosts: files dns myhostname
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 178 Mar 10 17:34 /etc/resolv.conf
(In the next command, the first for IPs are the ones that I'd like to get rid of but keep coming back. The last two are the correct ones that are set in my router.)
$ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.71.249.83
nameserver 87.98.175.85
nameserver 212.117.180.146
nameserver 92.222.80.28
nameserver 208.67.222.222
nameserver 208.67.220.220
$ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1%
$ cat /run/resolvconf/interfaces/*
# Generated by dhcpcd from eno1.dhcp
nameserver 208.67.222.222
nameserver 208.67.220.220
# systemctl -t service --state=active
UNIT LOAD ACTIVE SUB DESCRIPTION
accounts-daemon.service loaded active running Accounts Service
alsa-restore.service loaded active exited Save/Restore Sound Card State
colord.service loaded active running Manage, Install and Generate Color Profiles
dbus.service loaded active running D-Bus System Message Bus
dhcpcd@eno1.service loaded active running dhcpcd on eno1
gdm.service loaded active running GNOME Display Manager
kmod-static-nodes.service loaded active exited Create list of required static device nodes for
lm_sensors.service loaded active exited Initialize hardware monitoring sensors
openvpn@client.service loaded active running OpenVPN connection to client
polkit.service loaded active running Authorization Manager
rtkit-daemon.service loaded active running RealtimeKit Scheduling Policy Service
systemd-binfmt.service loaded active exited Set Up Additional Binary Formats
systemd-fsck@dev-disk-by\x2duuid-0f4db3de\x2d723f\x2d4103\x2d91ca\x2d0b847b079e63.service loaded active exited File
systemd-fsck@dev-disk-by\x2duuid-7A84\x2dD374.service loaded active exited File System Check on /dev/disk/by-uuid/7A
systemd-journal-flush.service loaded active exited Flush Journal to Persistent Storage
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-random-seed.service loaded active exited Load/Save Random Seed
systemd-remount-fs.service loaded active exited Remount Root and Kernel File Systems
systemd-sysctl.service loaded active exited Apply Kernel Variables
systemd-tmpfiles-setup-dev.service loaded active exited Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service loaded active exited Create Volatile Files and Directories
systemd-udev-trigger.service loaded active exited udev Coldplug all Devices
systemd-udevd.service loaded active running udev Kernel Device Manager
systemd-update-utmp.service loaded active exited Update UTMP about System Boot/Shutdown
systemd-user-sessions.service loaded active exited Permit User Sessions
systemd-vconsole-setup.service loaded active exited Setup Virtual Console
udisks2.service loaded active running Disk Manager
upower.service loaded active running Daemon for power management
user@1000.service loaded active running User Manager for UID 1000
user@120.service loaded active running User Manager for UID 120
wpa_supplicant.service loaded active running WPA supplicant
Let me know what you think.
Offline
This all looks good, except the extra entries. What is the output of
grep domain_name_servers /etc/dhcpcd.conf
Also try running radvdump (from the radvd package) for a while to see if those name servers are being advertised by an IPv6 Router Advertisement.
Offline
Here you go :
$ grep domain_name_servers /etc/dhcpcd.conf
option domain_name_servers, domain_name, domain_search, host_name
As for the second command, I'm not sure how long I should let it run but i've left it for an hour or so, and through a suspend / wake cycle and I got no output whatsoever.
Last edited by kRYOoX (2016-03-10 22:58:49)
Offline
Ok, time to get serious. Create /usr/lib/resolvconf/trace with the following contents:
#!/bin/bash
log=/tmp/resolvconf.trace
echo '========' >> "${log}"
/usr/bin/pstree -s "$$" >> "${log}"
resolvconf -v >> "${log}"
Then in a terminal, run:
watch cat /tmp/resolvconf.trace
Hopefully this will give some insight.
Offline
Done.
Waiting for a while yielded nothing, but after a suspend/wake cycle, here's the output:
========
systemd---dhcpcd---dhcpcd-run-hook---resolvconf---resolvconf---pstree
DOMAIN=''
SEARCH=''
NAMESERVERS=''
LOCALNAMESERVERS=''
DOMAINS=''
========
systemd---dhcpcd---dhcpcd-run-hook---resolvconf---resolvconf---pstree
DOMAIN=''
SEARCH=''
NAMESERVERS='208.67.222.222 208.67.220.220'
LOCALNAMESERVERS=''
DOMAINS=''
It seems disappointing though, as the only nameservers mentionned are the correct one. The bad ones came back in my resolv.conf as usual.
Offline
Yes, that is a bit disappointing. But it tells us that the rogue entries are not being set by a dhcp client; both dhcpcd and dhclient will use resolvconf. Which means they must be stored on the filesystem somewhere. I would start looking in /etc and /var:
for d in /etc /var; do
find "${d}" -type f -exec grep -Hn "192\.71\.249\.83" {} + 2>/dev/null
done
The search will be more comprehensive if run as root, as some files may not be readable by regular users. Expand to other directories as necessary, but obviously avoid things like /sys, /proc, /dev.
Oops, I said avoid /proc, but even though it's a long shot you may as well check the contents of /proc/net/pnp if it exists.
ps. While wpa_supplicant should not modify resolv.conf, I can't help but wonder why it is active.
Offline
This is the dirty way to do it. I point my DNS servers at OpenDNS, so I edit /etc/resolv.conf, and once it is my liking I make it immutable:
sudo chattr +i /etc/resolv.conf
From there nothing can change it. Changes to resolv.conf take place immediately and to make the file mutable again do:
sudo chattr -i /etc/resolv.conf
And then it's back to normal.
Like I said, that's the dirty way to do it.
Offline
While the OP said he did not want to go that route, it may be useful as a diagnostic measure. If it is immutable then something may complain in the system log about not being able to write to it.
Offline
The search found a file that contains the rogue DNS servers :
$ cat /etc/resolv.conf.head
nameserver 192.71.249.83
nameserver 87.98.175.85
nameserver 212.117.180.146
nameserver 92.222.80.28
I assume that deleting that file would solve my problem ?
Offline
That would do it.
For some reason I had thought that file was only used by dhcpcd when resolvconf is not found, but it appears that resolvconf its using it itself.
Offline
Well it's done. Hopefully this should solve the problem, but I'll make sure to drop by if not.
At any rate, thank you very much for your time.
Offline
/etc/resolv.conf.head
And the relevant script is 20-resolv.conf
Offline