応答が512バイトより大きく切り捨てられた場合、DNSクエリを実行できません。

」これがうまくいく理由についての洞察を提供し、いくつかの解決策（存在する場合）を提供するのに役立つ人はいますか？」

短い答え：

作成されたプライマリ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://www.rfc-editor.org/rfc/rfc7766

分析する:

これは思ったよりも難しいです。そのため、OPの有利なポイントでテストできるように、AzureでUbuntu 18.04 VMを起動しました。

私の出発点は、DNSクエリをブロックするものがないことを確認することです。

sudo iptables -nvx -L
sudo apparmor_status

すべてのチェーン店はiptablesデフォルトポリシーは次のように設定されます。受け入れるしかし、アパモアに設定実装する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。状態確認体系的分析上記のヒントによれば、私たちはそれがあることがわかります間違い:

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.confDNSクエリを解決するために使用されるソースの注文ソースを設定します。これは私たちに何を伝えますか？ :

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マッピングが見つからないかどうかを尋ねるようにフォワーダーが設定されていません。

これらすべての最終結果は次のとおりです。

• /etc/nsswitch.conf ローカルで利用できない場合は、DNS クエリを DNS に送信します。IP：名前次で見つけたマッピング/etc/hosts

• 照会するDNSサーバーは、127.0.0.53まだ構成されていない構成ファイルを見て、見つけたばかりのサーバーです/etc/systemd/resolved.conf。ここでフォワーダを指定しないと、問題を正常に解決できません。

テスト：

127.0.0.53168.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ブロック済み：フル '切り捨て 512「少し赤いニシンです。スタブレゾルバが設定されていません。私はDNSが別の方法で設定されていると仮定しました。「決して仮定しないでください。

設定方法systemd-resolved:

Ubuntu18.04

次のhostsディレクティブを編集して、DNS検証用の最初のソースに設定します。/etc/nsswitch.confresolvesystemd-resolved

hosts:          resolve files dns

この場合、希望のフォワーダを指定するDNSには、ディレクティブ（少なくとも）を編集します。/etc/systemd/resolved.conf

[Resolve]
DNS=168.63.129.16

再起動systemd-resolved:

sudo systemctl restart systemd-resolved

RHEL 8：

Red Hat は、systemd-resolvedスタブレゾルバの設定に関するほぼすべてのタスクを実行します。彼らはシステムにそれを使用するように指示しなかっただけです！

次のhostsディレクティブを編集して、DNS検証用の最初のソースに設定します。/etc/nsswitch.confresolvesystemd-resolved

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が期待どおりに機能しました。このように流れているようですが…