1

When I use my home WiFi my Network Manager constantly loses connection to the right nameserver. It looks like it has lost the connection at all, but disconnect and connect manually gives me access to the internet at least for a few minutes.

Now I think I have a problem with my resolv.conf files.

Firstly, there are plenty of them.

find / -name "resolv.conf" ->

/lib/systemd/resolv.conf
/run/NetworkManager/resolv.conf
/run/resolvconf/resolv.conf
/run/systemd/resolve/resolv.conf
/etc/resolv.conf

Most of them are of course generated by systemd or NetworkManager and look like this (/run/NetworkManager/resolv.conf)

# Generated by NetworkManager
search speedport.ip # name of my router
nameserver 127.0.0.53 # sounds weird to me

But one, /run/systemd/resolve/resolv.conf, looks like this:

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver fe80::1%3
nameserver 192.168.2.1
search speedport.ip

My questions are:

  1. Does anybody know, which of these files takes which role?
  2. How can I make sure, that they all point to the same nameserver?
  3. Can I decrease their number in order to be able to control less complexity?

Some entries from journalctl --follow look like this:

Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.3092] manager: NetworkManager state is now CONNECTED_GLOBAL
Dez 30 14:49:18 name_machine: nm-dispatcher[6450]: req:3 'connectivity-change': new request (1 scripts)
Dez 30 14:49:18 name_machine: systemd[1]: Started Network Manager Script Dispatcher Service.
Dez 30 14:49:18 name_machine: systemd[1]: Starting resolvconf-pull-resolved.service...
Dez 30 14:49:18 name_machine: systemd[1]: Started resolvconf-pull-resolved.service.
Dez 30 14:49:18 name_machine: nm-dispatcher[6450]: req:3 'connectivity-change': start running ordered scripts...
Dez 30 14:49:18 name_machine: dhclient[6437]: DHCPACK of 192.168.2.100 from 192.168.2.1
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4251] dhcp4 (wlp3s0):   address 192.168.2.100
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4251] dhcp4 (wlp3s0):   plen 24 (255.255.255.0)
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4252] dhcp4 (wlp3s0):   gateway 192.168.2.1
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>    [1546177758.4252] dhcp4 (wlp3s0):   lease time 1814400
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4252] dhcp4 (wlp3s0):   nameserver '192.168.2.1'
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4252] dhcp4 (wlp3s0):   domain name 'speedport.ip'
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4252] dhcp4 (wlp3s0): state changed unknown -> bound
Dez 30 14:49:18 name_machine: avahi-daemon[1073]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.2.100.
Dez 30 14:49:18 name_machine: avahi-daemon[1073]: New relevant interface wlp3s0.IPv4 for mDNS.
Dez 30 14:49:18 name_machine: avahi-daemon[1073]: Registering new address record for 192.168.2.100 on wlp3s0.IPv4.
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.4271] policy: set 'WLAN-235212' (wlp3s0) as default for IPv4 routing and DNS
Dez 30 14:49:18 name_machine: nm-dispatcher[6450]: req:4 'dhcp4-change' [wlp3s0]: new request (1 scripts)
Dez 30 14:49:18 name_machine: nm-dispatcher[6450]: req:4 'dhcp4-change' [wlp3s0]: start running ordered scripts...
Dez 30 14:49:18 name_machine: dhclient[6437]: bound to 192.168.2.100 -- renewal in 854872 seconds.
Dez 30 14:49:18 name_machine: systemd[1]: Starting resolvconf-pull-resolved.service...
Dez 30 14:49:18 name_machine: systemd[1]: Started resolvconf-pull-resolved.service.
Dez 30 14:49:18 name_machine: NetworkManager[1157]: <info>  [1546177758.5837] audit: op="statistics" arg="refresh-rate-ms" pid=2520 uid=1000 result="success"
Dez 30 14:49:18 name_machine: avahi-daemon[1073]: Registering new address record for 2003:ec:2bd0:b0a8:110f:592c:4811:b09a on wlp3s0.*.
Dez 30 14:49:19 name_machine: packagekitd[2722]: Starting pkgProblemResolver with broken count: 0
Dez 30 14:49:19 name_machine: packagekitd[2722]: Starting 2 pkgProblemResolver with broken count: 0
Dez 30 14:49:19 name_machine: packagekitd[2722]: Done
Dez 30 14:49:19 name_machine: PackageKit[2722]: get-updates transaction /10897_cdbececd from uid 1000 finished with success after 442ms
Dez 30 14:49:19 name_machine: NetworkManager[1157]: <info>  [1546177759.9389] audit: op="statistics" arg="refresh-rate-ms" pid=2520 uid=1000 result="success"
Dez 30 14:54:17 name_machine: kernel: wlp3s0: AP bc:30:d9:8a:2e:8c changed bandwidth, new config is 2462 MHz, width 1 (2462/0 MHz)

where NetworkManager says: dhcp4 (wlp3s0): nameserver '192.168.2.1' and dhcp4 (wlp3s0): domain name 'speedport.ip'.

I have no clue, whether this makes sense or how related 127.0.0.53 and 192.168.2.1 are to each other. Does fe80::1%3 mean 127.0.0.53? In this case how can I influence the order of nameservers in the given file? Any idea is welcome.

3

The standard file is /etc/resolv.conf but this may be a symlink.

e.g. on CentOS 7:

% ls -l /etc/resolv.conf 
-rw-r--r-- 1 root root 70 Dec  9 10:57 /etc/resolv.conf

% cat /etc/resolv.conf
# Generated by NetworkManager
search spuddy.org
nameserver 10.0.0.134

On Debian 9

% ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 35 Dec 21 23:05 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf

% cat /etc/resolv.conf
# Generated by NetworkManager
search spuddy.org
nameserver 10.0.0.134

Now 127.0.0.53 is a special entry for systemd-resolved, which is a stub DNS listener provided by systemd and will act as a DNS server for your machine. So it is possible that this is the correct DNS entry for your machine.

You may be able to tell what server you are using with a command such as nslookup or dig

% nslookup www.google.com
Server:     10.0.0.134
Address:    10.0.0.134#53

Non-authoritative answer:
Name:   www.google.com
Address: 216.58.217.100

% dig www.google.com | grep SERVER
;; SERVER: 10.0.0.134#53(10.0.0.134)

In both cases we can see I'm using 10.0.0.134 to do the DNS resolution.

fe80::1 is just a "link local" IPv6 address, rather than an IPv4 address.

  • Thanks for your hints. It has turned out that 127.0.0.53 is my nameserver (due to nslookup and dig). My /etc/resolv.conf links to /run/resolvconf/resolv.conf, which looks OK. But which role plays /run/systemd/resolve/resolv.conf, which says nameserver 192.168.2.1? Do I need to fix it? – BairDev Jan 6 at 17:29
  • Or is it rather the other way round (127.0.0.53 in nslookup is based on a systemd-bug)? But this question is more than one year old now. – BairDev Jan 6 at 17:38
  • Looks like people are still being hit by that issue; the last post was a few weeks ago. Only the file /etc/resolv.conf (and where it links to) is in active use. You can switch to using the systemd/resolve entry (which points to your router) with sudo rm -f /etc/resolv.conf ; sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf - this tells your machine to ignore the local systemd-resolved stub resolver and use the value sent by the DHCP server... which is probably the right one to use, anyway! – Stephen Harris Jan 6 at 17:55
  • This made things even worse. Now I have no address resoultion over wifi anymore. I think I need to figure out, what this 192.168.2.1 actually is or does. – BairDev Jan 7 at 7:49
  • Odds are 192.168.2.1 is your router – Stephen Harris Jan 7 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.