nslookup 在发现有关 VPN 的非权威答案后暂停 10 秒

nslookup 在发现有关 VPN 的非权威答案后暂停 10 秒

我注意到,对于 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 也没有显示任何内容)。

相关内容