![nslookup 在发现有关 VPN 的非权威答案后暂停 10 秒](https://linux22.com/image/1019658/nslookup%20%E5%9C%A8%E5%8F%91%E7%8E%B0%E6%9C%89%E5%85%B3%20VPN%20%E7%9A%84%E9%9D%9E%E6%9D%83%E5%A8%81%E7%AD%94%E6%A1%88%E5%90%8E%E6%9A%82%E5%81%9C%2010%20%E7%A7%92.png)
我注意到,对于 ssh 和 docker pull,与一些(并非全部)内部机器的连接大约需要 10 秒。
如果我对它们运行 ping 命令,一些主机也需要 10 秒才能启动,有些则需要立即启动 - 通常对于任何给定的地址都是相同的,无论我重新运行 ping 的频率如何。
无论哪种方式,运行 nslookup 总是会快速打印来自一台服务器的非权威响应,然后在超时之前“尝试下一台服务器”时挂起:
$ nslookup xxxx.internaldomain
Server: 10.10.x.x
Address: 10.10.x.x#53
Name: xxxx.internaldomain
Address: 10.20.y.y
;; Got recursion not available from 10.10.x.x, trying next server
<---- 10s delay here
;; connection timed out; no servers could be reached
另一个稍微复杂一些,但含义相同:
$ nslookup something.company.com
;; Got recursion not available from 10.10.x.x, trying next server
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
something.company.com canonical name = docker-reg.internal.
docker-reg.internal canonical name = something.internaldomain.
Name: something.internaldomain
Address: 10.10.r.r
;; Got recursion not available from 10.10.x.x, trying next server
<---- 10s delay here
;; connection timed out; no servers could be reached
nslookup 对外部 DNS(例如 bbc.co.uk)的处理很顺利,而且速度很快。
我的 resolv.conf 如下所示:
domain internaldomain
nameserver 10.10.x.x
nameserver 127.0.0.53
search internaldomain some other internal tlds
我没有看到提到任何其他名称服务器,因此我假设它正在尝试全局名称服务器,但我不明白为什么对于选定的内部主机,ssh 和 ping 可靠地不会挂起,对于某些主机,它们会挂起,但 nslookup 总是会挂起。
我相信这是一个不同的问题DNS 查找非常慢
更新:
$ sudo -s netstat -anlp|grep ':53 '
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 2228/dnsmasq
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1121/systemd-resolv
udp 0 0 192.168.122.1:53 0.0.0.0:* 2228/dnsmasq
udp 0 0 127.0.0.53:53 0.0.0.0:* 1121/systemd-resolv
此外,这个问题似乎影响了 Ubuntu,而不是大多数使用 Macbook 的开发人员:我的 Ubuntu 同事也遇到了同样的问题。
另一个更新!
我的 /etc/systemd/resolved.conf 全是注释:
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
另外,如果我尝试使用“nslookup -anything xxxx.internaldomain”运行,我会毫不延迟地得到这个(我在-debug 之后尝试了-anything 但没有产生大量有用的东西):
$ nslookup -anything dockerio.badoo.com
Server: 10.10.x.x
Address: 10.10.x.x#53
Non-authoritative answer:
something.company.com canonical name = docker-reg.internal.
docker-reg.internal canonical name = something.internaldomain.
Name: something.internaldomain
Address: 10.10.r.r
我可以得到一个版本:
$ nslookup -version
nslookup 9.11.3-1ubuntu1.13-Ubuntu
另一个更新:
$ systemd-resolve --status
Global
DNS Servers: 10.10.x.x
DNS Domain: various
internal
domains
DNSSEC NTA: 10.in-addr.arpa
xx1.172.in-addr.arpa
168.192.in-addr.arpa
xx2.172.in-addr.arpa # Lots of these 172s
internal
x.x.ip6.arpa
various
other
internals
Link 191 (cscotun0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 15 (docker0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 14 (br-04d8e612xxxx)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 7 (virbr0-nic)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 6 (virbr0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 5 (virbr1-nic)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 4 (virbr1)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wlp4s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 194.168.4.100 # These are my home ISP
194.168.8.100
DNS Domain: ~.
Link 2 (enp0s3xxx)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
答案1
该问题归结于 systemd-resolved,并通过使用指向文件副本的符号链接替换 /etc/resolv.conf 来修复。
# mv /etc/resolv.conf /etc/resolv.conf_bak && \
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
我不能为此承担功劳——服务工程主管对我提出的内部票很感兴趣,但这就是他付大笔钱的原因。
经过一些实验和搜索,他引用了https://moss.sh/name-resolution-issue-systemd-resolved/
看起来该服务正在尝试处理所有事情,但它会根据 /etc/resolv.conf 在其配置中是否为符号链接来改变其工作模式!
一个令人困惑的事情:当我用 vi 编辑 /etc/resolv.conf 或仅仅用 shell 重定向添加行时,文件要么立即恢复,要么受到保护(尽管 lsof 没有显示任何内容,lsattr 也没有显示任何内容)。