DNSプロトコルはどのようにUDPからTCPに切り替わりますか？

誰かが尋ねる前に：DNSクエリがUDPではなくTCPを使用するのはいつですか？それは私の質問に答えません。

私が聞き続けるのは、「答えが長すぎる場合、DNSはTCPを使用します」です。しかし、これはそれがどのように起こるかを説明しません。

状況は次のとおりです。DNSクライアントはUDPを使用してレコードの解決を要求します。レコードはUDPには長すぎます：

1. サーバーが特定のオペコードで応答し、クライアントをTCPに切り替えます
2. サーバーはまったく応答せず、クライアントはTCPで再試行します
3. サーバーはクライアントへのTCP接続を開きます（NATをカウントする場合は愚かですが、誰が知っていますか？）
4. クライアントは何らかの形で（？）与えられたクエリがTCP上で実行されるべきであることを「知っている」ので、そもそもUDPに煩わされません
5. DNS pixiesは必要に応じてUDPをTCPに魔法のように変換します

私は答えをインターネットで探していましたが、多くのノイズがあり（上記を参照）、そのための適切なGoogleクエリを書くことはできません（RFCで情報を見つけることもできません） 。

クライアントは、応答が大きすぎることを事前に知らないため、UDPを介してサーバーに照会します。
サーバーはUDPを介して応答し、可能な限り多くの情報を含めて、切り捨てられたヘッダービット（「TC」http://www.networksorcery.com/enp/protocol/dns.htm）を設定します。
その後、クライアントはTCPを介して要求を再送信し、完全な応答を取得できます。

参照：https : //tools.ietf.org/html/rfc5966

EDNS0（DNS 0の拡張メカニズム）がない場合（以下を参照）、512バイトの制限を超えるUDP応答を送信する必要があるDNSサーバーの通常の動作は、サーバーが適合するように応答を切り捨てることです。その制限内で、応答ヘッダーにTCフラグを設定します。クライアントがこのような応答を受信すると、代わりにTCPで再試行する必要があることを示すものとしてTCフラグを使用します。

および：https : //www.ietf.org/rfc/rfc2181.txt

そしてコメントで述べたように、もちろんDNSゾーン転送は常にTCPを使用しています。