![Linux 的 DNS 查询失败,Windows 成功 - 如何排除故障?](https://linux22.com/image/1633415/Linux%20%E7%9A%84%20DNS%20%E6%9F%A5%E8%AF%A2%E5%A4%B1%E8%B4%A5%EF%BC%8CWindows%20%E6%88%90%E5%8A%9F%20-%20%E5%A6%82%E4%BD%95%E6%8E%92%E9%99%A4%E6%95%85%E9%9A%9C%EF%BC%9F.png)
在小型网络中,路由器充当直通 DNS 服务器代理。当充当此代理时,来自 Linux 的 DNS 查询会失败,而来自 Windows 的 DNS 查询会成功且没有延迟。
问题:最终的问题是:有没有办法让 Linux DNS 查询通过我的路由器工作。如果做不到这一点,那么是什么原因导致只有 Linux DNS 查询失败,或者如果未知,那么我可以采取哪些步骤来进一步排除故障以找出根本故障原因。
网络设计:192.168.2.X 为子网。标准电缆调制解调器,Netgear R6700v2 路由器,地址为 192.168.2.1。路由器将其自己的 IP 地址作为 DNS 服务器提供给连接的设备,并将查询传递到 ISP 提供的上游 DNS 服务器。
几台 Apple、Android、Roku 和 Windows 设备连接正常且运行正常。但值得注意的是,一台本机 Linux 机器和两台运行不同版本 Linux Mint 的 Linux 虚拟机无法进行 DNS 查询。这两台虚拟机在其他方面运行正常的 Windows 主机上运行。在 Windows 中,“ping example.com”按预期工作,名称解析没有延迟。在 Linux 中,即使在同一台机器上运行的虚拟机上,“ping example.com”也会有 15 秒的延迟,并失败,并显示“名称解析暂时失败”。
所有 Linux 机器都可以编辑 resolv.conf 以指向上游 DNS 服务器或公共 DNS 服务器,然后正常运行。但是当它们指向路由器时,只有 Linux 机器的 DNS 查询会失败。已验证 Windows 机器已将路由器设置为 DNS 服务器,并且所有机器均正常运行。
奇怪的是,当 resolv.conf 指向路由器时,直接运行 dig 会失败,但手动指向 resolv.conf 设置的同一路由器 DNS 服务器 IP 地址时会成功:
~ $ cat /etc/resolv.conf
nameserver 196.168.2.1
~ $ ping example.com
ping: example.com: Temporary failure in name resolution
~ $ dig example.com
; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; global options: +cmd
;; connection timed out; no servers could be reached
~ $ dig example.com @192.168.2.1
; <<>> DiG 9.16.1-Ubuntu <<>> example.com @192.168.2.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43446
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 72211 IN A 93.184.216.34
;; Query time: 39 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Wed Sep 23 13:35:13 ADT 2020
;; MSG SIZE rcvd: 56
但是当 resolv.conf 直接指向公共 DNS 服务器时...
~ $ cat /etc/resolv.conf
nameserver 1.1.1.1
~ $ ping example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=54 time=30.0 ms
$ dig example.com
; <<>> DiG 9.16.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5675
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 82272 IN A 93.184.216.34
;; Query time: 39 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 23 13:47:49 ADT 2020
;; MSG SIZE rcvd: 56
~ $ dig example.com @192.168.2.1
; <<>> DiG 9.16.1-Ubuntu <<>> example.com @192.168.2.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65116
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 82267 IN A 93.184.216.34
;; Query time: 39 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Wed Sep 23 13:47:57 ADT 2020
;; MSG SIZE rcvd: 56
答案1
这听起来有点奇怪。为了缩小问题范围,我会尝试以下一些方法 -
在一个窗口中运行 tcpdump,同时在另一个窗口中执行 DNS 查询(类似“tcpdump -I any port 53”的命令)并观察离开和返回的流量。
尝试使用 did (dig @192.168.2.1 example.com)
为了完整起见,我也会尝试
- 如果 selinux 已打开,请暂时将其禁用。
- 禁用防火墙或插入 iptables 规则以允许端口 53 上的所有流量
- 确保我只有一个活动网络设备(以太网或 wifi,而不是两者)。
- 检查我是否可以通过 Linux(Web、ICMP)访问路由器
- 尝试重新启动路由器。