"なぜこれがこのように機能するのかについての洞察を提供して、解決策があれば助けてもらえますか? "
短い答え:
デフォルトの Azure VM は壊れた DNS で作成されます:systemd-resolved さらに設定が必要です。 sudo systemctl status systemd-resolved これをすぐに確認します。 /etc/resolv.conf 127.0.0.53 を指す - ローカルの構成されていないスタブ リゾルバー。
ローカル スタブ リゾルバ systemd-resolved 構成されていませんでした。フォワーダーが設定されていなかったので、127.0.0.53 をヒットした後 他に尋ねる人はいませんでした。うーん。最後にジャンプして、Ubuntu 18.04 用に構成する方法を確認してください。
その結論にどのように到達したかが気になる場合は、長い回答を読んでください。
長い回答:
DNS 応答が 512 バイトを超えて切り捨てられた理由:
<ブロック引用>TCP [RFC793] は常にフル ゾーン転送 (AXFR を使用) に使用され、サイズが DNS プロトコルの元の 512 バイト制限を超えるメッセージによく使用されます。
ソース:https://tools.ietf.org/html/rfc7766
分析:
これは思ったよりもトリッキーでした。そこで、OP の視点からテストできるように、Azure で Ubuntu 18.04 VM をスピンアップしました。
私の出発点は、DNS クエリを詰まらせるものが何もないことを検証することでした:
sudo iptables -nvx -L
sudo apparmor_status
iptables 内のすべてのチェーン デフォルトのポリシーが ACCEPT に設定されていた Apparmor でも 「強制」に設定されました "、それは DNS に関係するものではありませんでした。そのため、この時点でホストで接続やアクセス許可の問題は観察されませんでした。
次に、方法を確立する必要がありました DNS クエリは歯車をくねくねと回っていました。
cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0
search ns3yb2bs2fketavxxx3qaprsna.zx.internal.cloudapp.net
resolv.confによると の場合、システムは systemd-resolved というローカル スタブ リゾルバを想定しています . systemd-resolved のステータスを確認しています 上記のテキストで与えられたヒントによると、エラー であることがわかります :
sudo systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-10-08 12:41:38 UTC; 1h 5min ago
Docs: man:systemd-resolved.service(8)
https://www.freedesktop.org/wiki/Software/systemd/resolved
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 871 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 441)
CGroup: /system.slice/systemd-resolved.service
└─871 /lib/systemd/systemd-resolved
Oct 08 12:42:14 test systemd-resolved[871]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
<Snipped repeated error entries>
/etc/nsswitch.conf 解決された DNS クエリに使用されるソースの順序ソースを設定します。これは何を教えてくれますか?:
hosts: files dns
DNS クエリがローカルの systemd-resolved にヒットすることはありません。 /etc/nsswitch.conf で指定されていないため、スタブ リゾルバー .
フォワーダーは systemd-resolved 用に設定されていますか? スタブ リゾルバ?!?!? /etc/systemd/resolved.conf でその構成を確認しましょう
[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes
いいえ:systemd-resolved ローカル ip:name マッピングが見つからないかどうかを確認するフォワーダーが設定されていません。
これらすべての最終結果は次のとおりです。
-
ローカル IP:name がない場合、/etc/nsswitch.conf は DNS クエリを DNS に送信します。
/etc/hostsで見つかったマッピング -
照会する DNS サーバーは
127.0.0.53です 構成ファイル/etc/systemd/resolved.confを確認して、これが構成されていないことを確認しました。 .ここでフォワーダーが指定されていないため、問題を解決することはできません。
テスト:
スタブ リゾルバー 127.0.0.53 をオーバーライドしようとしました 168.63.129.16 を直接指定します。これは失敗しました:
dig aerserv-bc-us-east.bidswitch.net 168.63.129.16
; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> aerserv-bc-us-east.bidswitch.net 168.63.129.16
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24224
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;168.63.129.16. IN A
;; Query time: 13 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 08 13:26:07 UTC 2019
;; MSG SIZE rcvd: 42
いいえ:;; SERVER: 127.0.0.53#53(127.0.0.53) を見ています 出力の は、それをオーバーライドしておらず、ローカルの未構成のスタブ リゾルバーがまだ使用されていることを示しています。
ただし、次のコマンドのいずれかを使用すると、デフォルトの 127.0.0.53 が上書きされます スタブリゾルバであり、したがって NOERROR を返すことに成功しました 結果:
sudo dig aerserv-bc-us-east.bidswitch.net @168.63.129.16
または
dig +trace aerserv-bc-us-east.bidswitch.net @168.63.129.16
したがって、systemd-resolved の使用に依存するクエリはすべて スタブ リゾルバーは、構成されるまで運命づけられていました。
解決策:
私のイニシャル - 不正解 - TCP/53 が信じられていた ブロックされていました:"Truncated 512 全体 スタブ リゾルバーが構成されていませんでした。私は仮定を行いました-知っている、知っている、「絶対に想定しないでください;-) - DNS が別の方法で構成されていると。
systemd-resolved の設定方法 :
Ubuntu 18.04
hosts を編集します /etc/nsswitch.conf のディレクティブ 以下のように resolve を先頭に追加します systemd-resolved を設定する DNS 解決の最初のソースとして:
hosts: resolve files dns
DNS を編集します /etc/systemd/resolved.conf のディレクティブ (最低) 目的のフォワーダーを指定します。この例では次のようになります:
[Resolve]
DNS=168.63.129.16
systemd-resolved を再起動します :
sudo systemctl restart systemd-resolved
RHEL 8:
systemd-resolved の設定に関しては、Red Hat がほとんどすべてを行ってくれます。 スタブ リゾルバとして、システムにそれを使用するように指示しなかったことを除いて!
hosts を編集します /etc/nsswitch.conf のディレクティブ 以下のように resolve を先頭に追加します systemd-resolved を設定する DNS 解決の最初のソースとして:
hosts: resolve files dns
systemd-resolved を再起動します :
sudo systemctl restart systemd-resolved
ソース :https://www.linkedin.com/pulse/config-rhel8-local-dns-caching-terrence-houlahan/
結論:
一度 systemd-resolved テスト VM の DNS が期待どおりに動作するように構成されました。私はそれについてだと思います....