DNSプロトコルはどのようにUDPからTCPに切り替えますか？
誰かが尋ねる前に：私は見てきました DNSクエリがTCPを使用するのはいつですか であり、それは私の質問に答えません。
私が聞き続けるのは、「答えが長すぎる場合、DNSはTCPを使用する」ということだけです。ただし、これがどのように発生するかは説明していません。
つまり、状況は次のとおりです。DNSクライアントは、UDPを使用してレコードの解決を要求します。 UDPにはレコードが長すぎます：
- サーバーが特定のオペコードで応答し、クライアントをTCPに切り替えます
- サーバーはまったく応答せず、クライアントはTCP経由で再試行します
- サーバーが開くTCPクライアントへの接続（愚かな、NATを数えるなら、誰が知っている？）
- クライアントはどういうわけか（？）与えられたクエリを実行する必要があることを「知っている」TCPなので、そもそもUDPを気にしない
- 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フラグを設定します。クライアントがそのような応答を受信すると、代わりにTCフラグを受け取り、TCPで再試行する必要があることを示します。
そして： https://www.ietf.org/rfc/rfc2181.txt
そしてコメントで述べたように、もちろんDNSゾーン転送は常にTCPを使用しています。