今日、インターネットルーターをアップグレードしましたが、Fedora 36を実行しているLinuxシステムがDNS名解決を実行できなくなったことがわかりました。また、ネットワークにAndroidデバイス、Windows 10、Windows 11、およびCentOS 7.9システムがあり、このアップグレードに問題はありませんでした。
私のCentOSコンピュータには以下が/etc/resolv.conf含まれています。
# Generated by NetworkManager
nameserver 10.0.1.1
私のFedora 36システムには以下が含まれています。
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically 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 127.0.0.53
options edns0 trust-ad
search .
Fedora 36 は systemd 検証サービスを使用して DNS ネームサーバーを管理します。8.8.8.8ファイルに追加のエントリを追加してサービスを再起動すると、ファイルが再生成され、すべての変更が失われます。
何が起こっているのか理解できません。これで、Fedora 36システムだけがドメイン名を解決できず、問題を解決する方法が見つかりません。さまざまな Google 検索を試しましたが、ディストリビューションと以前のバージョンの Fedora の間には矛盾する情報がたくさんあります。
ローカルネットワークを介してシステムにアクセスすることに問題はなく、IPアドレスを正しくpingできます。しかし、どのドメインにもpingを送信できません。
私が得るエラーは次のとおりです。
$ ping google.com
ping: google.com: Temporary failure in name resolution
解決されたサービスとdnsmaqサービスを再起動してみました。
systemctl restart systemd-resolved.service
systemctl restart dnsmasq
DNSポートが開いていることを確認してください。
firewall-cmd --permanent --add-port=43/tcp
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --reload
イーサネットアダプタの電源を切り、もう一度バックアップしてみました。
nmcli con down id Ethernet
nmcli con up id Ethernet
8.8.8.8私のイーサネットカードのインターフェイスにDNSを追加してみました。
systemd-resolve --interface enp9s0 --set-dns 8.8.8.8
また、DNSキャッシュをフラッシュしてみました。
resolvectl flush-caches
sudo resolvectl flush-caches
サーバーはヘッドレスなので、SSH経由でのみアクセスできます。これは、デスクトップまたはGUIでどの設定も変更できないことを意味します。
問題は何であり、どのように発生し、どのように解決しますか？問題が何であるか、どのように進むべきか理解できません。
以下は、いくつかの追加情報です。
$ resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp9s0)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp8s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
$ systemd-resolve --statistics
DNSSEC supported by current servers: no
Transactions
Current Transactions: 0
Total Transactions: 0
Cache
Current Cache Size: 0
Cache Hits: 0
Cache Misses: 0
DNSSEC Verdicts
Secure: 0
Insecure: 0
Bogus: 0
Indeterminate: 0
$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2022-07-27 16:34:57 EDT; 16min ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1992495 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 76912)
Memory: 4.0M
CPU: 61ms
CGroup: /system.slice/systemd-resolved.service
└─ 1992495 /usr/lib/systemd/systemd-resolved
Jul 27 16:34:57 lserver systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Positive Trust Anchors:
Jul 27 16:34:57 lserver systemd-resolved[1992495]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683>
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.>
Jul 27 16:34:57 lserver systemd-resolved[1992495]: Using system hostname 'lserver'.
Jul 27 16:34:57 lserver systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jul 27 16:48:02 lserver systemd-resolved[1992495]: Flushed all caches.
Jul 27 16:48:30 lserver systemd-resolved[1992495]: Flushed all caches.
$ systemctl status dnsmasq
● dnsmasq.service - DNS caching server.
Loaded: loaded (/usr/lib/systemd/system/dnsmasq.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2022-07-27 16:49:49 EDT; 50s ago
Process: 2045570 ExecStart=/usr/sbin/dnsmasq (code=exited, status=0/SUCCESS)
Main PID: 2045572 (dnsmasq)
Tasks: 1 (limit: 76912)
Memory: 600.0K
CPU: 3ms
CGroup: /system.slice/dnsmasq.service
└─ 2045572 /usr/sbin/dnsmasq
Jul 27 16:49:49 lserver systemd[1]: Starting dnsmasq.service - DNS caching server....
Jul 27 16:49:49 lserver dnsmasq[2045572]: started, version 2.86 cachesize 150
Jul 27 16:49:49 lserver dnsmasq[2045572]: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP DHCPv>
Jul 27 16:49:49 lserver dnsmasq[2045572]: reading /etc/resolv.conf
Jul 27 16:49:49 lserver dnsmasq[2045572]: using nameserver 127.0.0.53#53
Jul 27 16:49:49 lserver systemd[1]: Started dnsmasq.service - DNS caching server..
Jul 27 16:49:49 lserver dnsmasq[2045572]: read /etc/hosts - 2 addresses
以前のルーターは、OpenWRTを含むLinksys WRT3200ACMでした。私の新しいルーターはFreshTomatoを含むNetegar R7000です。ルータソフトウェアを次のように設定したようです。ローカルDNSサーバーこれは、ネットワークのデフォルトゲートウェイアドレスであるマイnameserverCentOSシステムのデフォルトエントリに反映されます。10.0.1.1しかし、ネットワーク上の他のすべてのデバイスに基づいて見ると、そのタスクを実行しているようです。これは、なぜFedora 36が問題のある唯一のシステムなのかを説明しません。
このアップグレードは私のIPアドレスを変更しませんでした。デフォルトゲートウェイは常に10.0.1.1で構成され、システムのIPは常に固定10.0.1.21です。 LANへの唯一の変更はルータの切り替えです。必要なすべてのポート転送を事前設定したので、すべてが「正しく動作する」必要があります。
コメントで要求された追加情報：
$ dig @10.0.1.1 bbc.co.uk
; <<>> DiG 9.16.30-RH <<>> @10.0.1.1 bbc.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16748
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;bbc.co.uk. IN A
;; ANSWER SECTION:
bbc.co.uk. 177 IN A 151.101.64.81
bbc.co.uk. 177 IN A 151.101.128.81
bbc.co.uk. 177 IN A 151.101.192.81
bbc.co.uk. 177 IN A 151.101.0.81
;; Query time: 9 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Wed Jul 27 17:21:01 EDT 2022
;; MSG SIZE rcvd: 102
$ dig @127.0.0.53 bbc.co.uk
; <<>> DiG 9.16.30-RH <<>> @127.0.0.53 bbc.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58582
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bbc.co.uk. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Jul 27 17:21:26 EDT 2022
;; MSG SIZE rcvd: 38
$ dig @8.8.8.8
; <<>> DiG 9.16.30-RH <<>> @8.8.8.8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32553
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 615 IN NS m.root-servers.net.
. 615 IN NS b.root-servers.net.
. 615 IN NS c.root-servers.net.
. 615 IN NS d.root-servers.net.
. 615 IN NS e.root-servers.net.
. 615 IN NS f.root-servers.net.
. 615 IN NS g.root-servers.net.
. 615 IN NS h.root-servers.net.
. 615 IN NS a.root-servers.net.
. 615 IN NS i.root-servers.net.
. 615 IN NS j.root-servers.net.
. 615 IN NS k.root-servers.net.
. 615 IN NS l.root-servers.net.
;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jul 27 17:21:32 EDT 2022
;; MSG SIZE rcvd: 239
$ journalctl _SYSTEMD_UNIT=systemd-resolved.service
...
-- Boot 66eaabbbfb7e4f7b9f34c9b3316f1e07 --
Jul 15 08:06:43 lserver systemd-resolved[1456]: Positive Trust Anchors:
Jul 15 08:06:43 lserver systemd-resolved[1456]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jul 15 08:06:43 lserver systemd-resolved[1456]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.>
Jul 15 08:06:43 lserver systemd-resolved[1456]: Using system hostname 'lserver'.
Jul 15 08:06:48 lserver systemd-resolved[1456]: enp9s0: Bus client set default route setting: yes
Jul 15 08:06:48 lserver systemd-resolved[1456]: enp9s0: Bus client set DNS server list to: fdf5:328d:f2ee::1
Jul 27 12:35:17 lserver systemd-resolved[1456]: enp9s0: Bus client set default route setting: no
Jul 27 12:35:17 lserver systemd-resolved[1456]: enp9s0: Bus client reset DNS server list.
Jul 27 14:55:04 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:08 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:42 lserver systemd-resolved[1456]: Flushed all caches.
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=llmnr interface=enp9s0 family=AF_INET6]
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=llmnr interface=enp9s0 family=AF_INET]
Jul 27 14:55:47 lserver systemd-resolved[1456]: [Scope protocol=dns]
Jul 27 14:57:58 lserver systemd-resolved[1620611]: Positive Trust Anchors:
答え1
最終的に使用する解決策を共有するために私の質問に答えていますが、オペレーティングシステムがDNSサーバーを自動的に構成できる必要があると思うので、これを受け入れることは消えます。この問題がなぜ存在するのか、ルータを変更した後にのみ問題が発生するのか、Fedora 36システムでのみ発生するのかはまだわかりません。
この問題を解決するために、DNSサーバーがルーターアドレス10.0.1.1のデフォルトゲートウェイに設定されているCentOSシステムの動作を複製しました。 systemd-resolvedの場合は、/etc/systemd/resolved.confファイルを編集して行にエントリを追加するだけですDNS=。
[Resolve]
DNS=10.0.1.1
他の既知のDNSホスト（など）でもうまく機能します。8.8.8.8しかし、1.1.1.1ここでDNSルックアップを実行し、独自のキャッシュがあるので、私のルーターを使用するのは妥当です。
Fedora 36や私の環境では、これがなぜ問題なのか理解していませんが、処理する必要がない問題のようです。