오늘 인터넷 라우터를 업그레이드했는데 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 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가 포함된 Netgear R7000입니다. 라우터 소프트웨어를 다음과 같이 구성한 것 같습니다.로컬 DNS 서버, 이는 네트워크의 기본 게이트웨이 주소인 nameserver내 CentOS 시스템의 기본 항목에 반영됩니다 . 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이나 내 환경에서 이것이 왜 문제인지 이해하지 못하지만, 처리할 필요가 없는 문제인 것 같습니다.