4. 議論 (Discussion)

EDNS0 (Extension Mechanisms for DNS 0 [RFC6891]; 下記参照) がない場合、512 バイト制限を超える UDP 応答を送信する必要がある DNS サーバーの通常の動作は、その制限内に収まるように応答を切り詰め、応答ヘッダーに TC フラグを設定することです。クライアントがそのような応答を受信すると、TC フラグを TCP 経由で再試行すべきであるという指示として受け取ります。

RFC 1123 には次のようにも記載されています:

... 将来定義されるいくつかの新しい DNS レコードタイプには、UDP に適用される 512 バイト制限を超える情報が含まれるため、TCP が必要になることも明らかです。したがって、リゾルバとネームサーバーは、将来 TCP サービスが必要になることを承知の上で、今日 UDP のバックアップとして TCP サービスを実装すべきです。

DNSSEC [RFC4033] の既存の展開は、512 バイト境界での切り詰めが現在一般的であることを示しています。たとえば、NextSECure 3 (NSEC3) [RFC5155] を使用した DNSSEC 署名ゾーンからの存在しないドメイン (NXDOMAIN) (RCODE == 3) 応答は、ほぼ間違いなく 512 バイトより大きくなります。

DNS の元のコア仕様が書かれて以来、DNS の拡張メカニズムが導入されました。これらの拡張機能は、クライアントが 512 バイトより大きい UDP パケットを受信する準備ができていることを示すために使用できます。EDNS0 互換クライアントからの要求を受信する EDNS0 互換サーバーは、切り詰めなしでそのクライアントが通知したバッファサイズまで UDP パケットを送信できます。

ただし、パス MTU のサイズを超える UDP パケットの転送は IP パケットの断片化を引き起こし、多くの状況で信頼性がないことがわかっています。多くのファイアウォールは日常的に断片化された IP パケットをブロックしており、断片化されたパケットを再構築するために必要なアルゴリズムを実装していないものもあります。さらに悪いことに、一部のネットワークデバイスは、EDNS0 オプションを含む DNS パケットの処理を意図的に拒否します。UDP 転送とパケットサイズに関するその他の問題は、[RFC5625] で議論されています。

インターネットのコアで最も一般的に見られる MTU は約 1500 バイトですが、DNSSEC 署名付き応答ではその制限さえも日常的に超えています。

RFC 1123 で予想されていた未来が到来しましたが、パケットサイズの問題を解決した可能性のある唯一の標準化された UDP ベースのメカニズムは不十分であることが判明しました。