web-dev-qa-db-ja.com

DNS Resolveが18.04サーバーで機能しない

私はかなり広範囲にわたる検索を実行しましたが、この問題を修正する干し草の山から針を見つけることができません。

Ubuntu 18.04を実行しているサーバーがあります

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:    18.04
Codename:   bionic

現在、LXC/LXDをサーバーで実行していますが、実際には16.04イメージである単一のコンテナーのみを使用しています。 DNSはコンテナ内から正常に機能します。これにより、ネットワークの潜在的な問題がすべて解消されると思います。

18.04でインストールすると、nslookupを使用すると次のようになります。

nslookup google.com
;; connection timed out; no servers could be reached

ただし、DNSサーバーを直接含める場合は、ルックアップが機能します。再びファイアウォール/ネットワークの問題を除外しているようです

nslookup google.com 1.1.1.1
Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.5.238
Name:   google.com
Address: 2607:f8b0:4006:802::200e

以下のヒント/トリック/ガイドの一部として、私が試した以下のことの一部と、これを特定するのに役立つ可能性のあるさまざまな出力を以下に示します。

次のファイルをそのように見えるように変更しました。ネームサーバーのみ追加しました。私はそこにある修正の1つに従ってこれを行いました。

$ cat /etc/netplan/50-cloud-init.yaml
network:
version: 2
ethernets:
    ens3:
        dhcp4: true
        match:
            macaddress: <redacted for post>
        set-name: ens3
        nameservers:
            addresses: [8.8.4.4, 8.8.8.8, 1.1.1.1, 1.1.0.0]

これにより、DNSサーバーがデバイスに追加されたようです

Sudo systemd-resolve --status
Global
      DNS Domain: openstacklocal
      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 5 (vethTR4JCU)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 3 (lxdbr0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Link 2 (ens3)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.4.4
                      8.8.8.8
                      1.1.1.1
                      1.1.0.0
                      <redacted for post>
         DNS Domain: openstacklocal

そこにDNSサーバーがリストされている場合でも、Digまたはnslookupを使用して検索することはできません。

私はガイドの一部としてresolvconfをインストールしましたが、それは不必要であり、さらに大きな混乱をもたらすことが判明しただけだと思います。

$ ls -al /etc/resolv.conf 
lrwxrwxrwx 1 root root 29 Jan 29 12:55 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

cat /run/resolvconf/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 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 openstacklocal

これは私が得ることができるように見える限りです。有効なネームサーバー（8.8.8.8、8.8.4.4、1.1.1.1など）を/run/resolveconf/resolv.confファイルに追加した場合：

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 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
nameserver 8.8.8.8   # manually added in for testing
search openstacklocal

以下に示すように、ルックアップを機能させることができます。ファイルに記述されているとおりのコースの場合、これらの変更は再起動時に上書きされます。

nslookup google.com
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.15.78
Name:   google.com
Address: 2607:f8b0:4004:810::200e

編集：適用コマンドの出力

Sudo netplan --debug apply
** (generate:15710): DEBUG: 14:11:34.829: Processing input file /etc/netplan/50-cloud-init.yaml..
** (generate:15710): DEBUG: 14:11:34.830: starting new processing pass
** (generate:15710): DEBUG: 14:11:34.878: ens3: setting default backend to 1
** (generate:15710): DEBUG: 14:11:34.879: Generating output files..
** (generate:15710): DEBUG: 14:11:34.879: NetworkManager: definition ens3 is not for us (backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:ens3 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    ens3:
      dhcp4: true
      match:
        macaddress: <redacted for post>
      nameservers:
        addresses:
        - 8.8.4.4
        - 8.8.8.8
        - 1.1.1.1
        - 1.1.0.0
      set-name: ens3
  vlans: {}
  wifis: {}

DEBUG:Skipping non-physical interface: lo
DEBUG:device ens3 operstate is up, not changing
DEBUG:Skipping non-physical interface: lxdbr0
DEBUG:Skipping non-physical interface: vethTR4JCU
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for ens3
DEBUG:netplan triggering .link rules for lxdbr0
DEBUG:netplan triggering .link rules for vethTR4JCU

編集：要求された

Sudo iptables -L -n -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     tcp  --  ens3   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443 /* allow connection to lxd */
 2336  152K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    1    60 ACCEPT     tcp  --  lxdbr0 *       10.100.106.40        0.0.0.0/0            tcp dpt:22
 1279 73342 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 8207 2604K ACCEPT     all  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            /* generated for LXD network lxdbr0 */
 9496 3318K ACCEPT     all  --  lxdbr0 *       0.0.0.0/0            0.0.0.0/0            /* generated for LXD network lxdbr0 */

Chain OUTPUT (policy ACCEPT 70 packets, 8606 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            tcp spt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            udp spt:53 /* generated for LXD network lxdbr0 */
    0     0 ACCEPT     udp  --  *      lxdbr0  0.0.0.0/0            0.0.0.0/0            udp spt:67 /* generated for LXD network lxdbr0 */

誰でもこの問題へのリンク/解決策を知っています。私は途方に暮れています。

networkingserver18.04dns
7
Dave

TL; DR：ポート53 tcpとudpからloインターフェースを許可します。

INPUTのデフォルトポリシーはACCEPTですが、まだ受け入れられていないものはすべて破棄するという最終規則があります。ポート53でトラフィックを受け入れる唯一のルールは、lxdbr0インターフェイス上にあります。 loインターフェース上のすべてを全面的に許可するか、必要に応じてポートを許可することができます。

他のルールよりも先にloインターフェース上のすべてを許可するルールをプッシュするには：

iptables -I INPUT 1 -i lo -j ACCEPT
6
mjb2kmn

私の場合、16.04から18.04にアップグレードすると、不可解な方法でsystemd-resolvedサービスが無効になります。修正はそれを再び有効にすることの問題でした。

0
zgoda

NetPlan構成に変更した後。走る

Sudo netplan apply

変更を拡大します。変更を評価するには、次を実行します。

Sudo netplan --debug apply

詳細情報で更新します。

私はこのファイル構成を持っています：/etc/netplan/01-netcfg.yaml

入力したパラメータは正しいです。試してみませんか：

Sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/01-netcfg.yaml

PS：バックアップを作成します。

0
Carlos Dagorret

16.04から18.04へのアップグレード中に、同じ問題が発生しました。上記に加えて、resolv.confに関連する他の多くのソリューションを試してみました。

私の真の犯人：POSTFIX。どういうわけか/何らかの形でpostfixがDNS設定を妨害していました。 --auto-removeを使用してpostfixを削除した後、魔法のようにDNSが再び解決し始めました。

これでpingしてapt-getを再度実行できます。なんて素晴らしい日でしょう:)

0
Goner

Netplan構成をもう一度適用してみてください。 dockerノードの1つを更新した後、DNS解決を失い、以下のコマンドを使用してサーバーにネットワーク構成を再適用しました。

Sudo netplan apply

その後はすべて期待どおりに機能しました。

0
Nikolay Andonov