当我使用家庭 WiFi 时，我的网络管理器经常失去与正确名称服务器的连接。看起来好像完全失去了联系，但是断开和连接手动让我至少可以访问互联网几分钟。
现在我觉得我的方法有问题解析配置文件文件。
首先，它们的数量很多。
find / -name "resolv.conf" ->
/lib/systemd/resolv.conf
/run/NetworkManager/resolv.conf
/run/resolvconf/resolv.conf
/run/systemd/resolve/resolv.conf
/etc/resolv.conf
其中大多数当然是由 systemd 或 NetworkManager 生成的，看起来像这样 (/run/NetworkManager/resolv.conf)
# Generated by NetworkManager
search speedport.ip # name of my router
nameserver 127.0.0.53 # sounds weird to me
但其中一个 /run/systemd/resolve/resolv.conf 看起来像这样：
# 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
我的问题是：
- 有谁知道这些文件中的哪个扮演哪个角色？
- 我如何确保它们都指向同一个名称服务器？
- 我可以减少它们的数量以便能够控制更少的复杂性吗？
一些条目看起来journalctl --follow像这样：
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)
其中 NetworkManager 说：dhcp4 (wlp3s0): nameserver '192.168.2.1'和dhcp4 (wlp3s0): domain name 'speedport.ip'。
我不知道这是否有意义，也不知道彼此之间有127.0.0.53多么相关。192.168.2.1是fe80::1%3指吗127.0.0.53？在这种情况下，我如何影响给定文件中名称服务器的顺序？欢迎任何想法。
答案1
标准文件是，/etc/resolv.conf但这可能是符号链接。
例如在 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
在 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
现在 127.0.0.53 是 的一个特殊条目systemd-resolved，它是由 提供的存根 DNS 侦听器systemd，并将充当您计算机的 DNS 服务器。所以是这可能是您计算机的正确 DNS 条目。
您可以使用以下命令来判断您正在使用哪个服务器，例如nslookup或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)
在这两种情况下，我们都可以看到我正在使用10.0.0.134DNS 解析。
fe80::1只是“链路本地”IPv6 地址，而不是 IPv4 地址。