web-dev-qa-db-ja.com

17.10へのアップグレード後のDNS解決の問題

17.10にアップグレードした後、Ubuntuはsystemd-resolvedを使用してすべてのDNS要求を処理し、スタブリスナーを持っていますが、リスナーはローカルからの要求のみを受け入れます。私はVultr VPSを使用していますが、これが実際に起こったことです。

root@00:~# nslookup www.google.com 127.0.0.53
Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find www.google.com: SERVFAIL

エラーログで：

Dec 19 01:20:24 00.tokyo.jp.mole systemd-resolved[684]: Got packet on unexpected IP range, refusing.

私はudpパッケージをダンプしようとしましたが、ここに結果があります：

root@00:~# tcpdump -i lo udp port 53 -vv -X
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
01:20:24.230349 IP (tos 0x0, ttl 64, id 24187, offset 0, flags [none], proto UDP (17), length 60)
    45.xx.xx.xx.vultr.com.60360 > 127.0.0.53.domain: [bad udp cksum 0xbf8c -> 0xe032!] 58738+ A? www.google.com. (32)
    0x0000:  4500 003c 5e7b 0000 4011 5ce3 2dxx xxxx  E..<^{..@.\.-...
    0x0010:  7f00 0035 ebc8 0035 0028 bf8c e572 0100  ...5...5.(...r..
    0x0020:  0001 0000 0000 0000 0377 7777 0667 6f6f  .........www.goo
    0x0030:  676c 6503 636f 6d00 0001 0001            gle.com.....
01:20:24.230963 IP (tos 0x0, ttl 64, id 25931, offset 0, flags [DF], proto UDP (17), length 40)
    127.0.0.53.domain > localhost.60360: [bad udp cksum 0xfe5b -> 0xae9c!] 58738 ServFail [0q] 0/0/0 (12)
    0x0000:  4500 0028 654b 4000 4011 d743 7f00 0035  E..(eK@[email protected]
    0x0010:  7f00 0001 0035 ebc8 0014 fe5b e572 8182  .....5.....[.r..
    0x0020:  0000 0000 0000 0000                      ........

127.0.0.1の代わりにパブリックIPを使用して要求を送信しているため、systemdで解決された応答拒否を示しています。 systemd-resolve www.google.comを使用すると結果が得られ、サービスが正常に機能していることがわかります。

root@00:~# systemd-resolve www.google.com
www.google.com: 216.58.196.228
                2404:6800:400a:806::2004

-- Information acquired via protocol DNS in 6.6ms.
-- Data is authenticated: no

サーバーがインターネットにアクセスできるように、一時的に/etc/resolv.confのシンボリックリンクを/run/systemd/resolve/resolv.confに変更しましたが、この問題を解決するためにリクエストIPを変更する方法を知りたいのですが？

networking17.10dnssystemd-resolved
1
B. Zhang

Ubuntu 16.04からUbuntu 18.04にアップグレードしたサーバーでも同じ問題が発生しました。私の解決策は、ファイアウォールの設定を確認し、ループバックデバイスloをソースIPのマスカレードから除外することでした（D'oh！）。

必ず、ルーティングとPOSTROUTING {MASQUERADE;のようなファイアウォールルーティングマジックを確認してください。 }。以前のDNSリゾルバは、ソースIPに対してそれほどうるさくなかったため、以前は機能していました。

0
Roger Lehmann