web-dev-qa-db-ja.com

nslookupは失敗しましたが、systemdで解決されました

これは私が一日中過ごした奇妙な問題です。誰かがこれに光を当てることができれば素晴らしいと思います。

この問題は名前解決の問題として現れますが、それが根本的な原因かどうかはわかりません。

# 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の群れの一部であり、削除してから再度追加すると、ある時点で問題が修正されます。

systemd-resolved debug をオンにしましたが、リクエストが行われたときに出力がありませんでした。

ubuntudnssystemdresolv.conf
4
Richard Collins

私は見つけました 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

それは私のために働いた。シンボリックリンクを再作成した後、サービスを再起動する必要はなかったと思います。

3
Neil Smith