☰

nslookup 失败，但 systemd-resolved 可以工作

tag-icon • tag-icon ubuntu dns systemd resolv.conf
nslookup 失败，但 systemd-resolved 可以工作

这是一个奇怪的问题，我花了一整天的时间来解决它。如果有人能解释一下，那就太好了。

该问题表现为名称解析问题，但我不确定这是否是根本原因：

# host www.google.com
;; connection timed out; no servers could be reached

到目前为止很无聊，但是等等！：

#systemd-resolve www.google.com
www.google.com: 209.85.202.103
                209.85.202.106
                209.85.202.105
                209.85.202.104
                209.85.202.147
                209.85.202.99

很简单，问题出在 resolv.conf 上，对吧？

# This file is managed by man:systemd-resolved(8). Do not edit.
#
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53

search xxx.uk xyz

那么系统正在使用 systemd 解析器？

#dig @127.0.0.53 www.google.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.53 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

好的，如果 systemd 解析器说它在 127.0.0.53 上，为什么它没有响应。

#sudo netstat -lupn | grep 127
udp        0      0 127.0.0.53:53           0.0.0.0:*                           1679/systemd-resolv

如果它没有监听，systemd-resolv 在做什么？

Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 20 (veth10858e2)
      Current Scopes: LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 14 (vnet0)
      Current Scopes: LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 13 (virbr0-nic)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 12 (virbr0)
      Current Scopes: LLMNR/IPv4
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 11 (docker0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 10 (docker_gwbridge)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (em2)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.100.1
                      192.168.100.2
                      192.168.100.3
                      192.168.100.4
          DNS Domain: cqp

Link 2 (em1)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: xxx.xxx.x.xx
                      xxx.xxx.x.xx
          DNS Domain: xxx.uk

我有几台服务器，它们都运行着最新的 ubuntu artful，在尝试修复此问题的过程中，这个问题在服务器之间转移了。
它们是 docker swarm 的一部分，删除后重新添加，在某一时刻修复了问题。

我打开了systemd-resolved 调试但提出请求时没有任何输出。

答案1

我发现Hacker News 上的这个答案建议符号链接/etc/resolv.conf到/run/systemd/resolve/resolv.conf：

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

这对我来说很有效。我认为在重新创建符号链接后，我不需要重新启动任何服务。

答案2

听起来很疯狂，但你需要允许访问才能127.0.0.53使用systemd-resolved

iptables -I INPUT -s localhost -d 127.0.0.53  -j ACCEPT

答案3

检查文件路径中是否有resolv.conf文件：/run/systemd/resolve/resolv.conf

它与/etc/resolv.conf

如果该文件不可用，则在此文件位置创建它/run/systemd/resolve/resolv.conf并删除该文件/etc/resolv.conf

现在通过cmd重新链接文件sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

现在尝试 ping，这将最有效地解决问题

相关内容