自宅でWi-Fiを使用すると、ネットワーク管理者は正しいネームサーバーへの接続を切断し続けます。完全に連絡が切れたようですが、切断するそしてつながる手動で少なくとも数分間インターネットにアクセスできるようにしました。
今私の方法に問題があるようです。構成ファイルの解析文書。
まず、それらがたくさんあります。
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の1つは次のとおりです。
# 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
systemd-resolved127.0.0.53はスタブ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::1IPv4アドレスではなく、「リンク - ローカル」IPv6アドレス。