メインコンテンツまでスキップ

5. Transport (トランスポート)

5. Transport (トランスポート)

DNS Update [RFC2136] などの他の DNS 操作は, DNS over User Datagram Protocol (UDP) [RFC0768] または DNS over Transmission Control Protocol (TCP) [RFC0793] をトランスポートプロトコルとして使用してもかまいませんが, DNS クエリは最初に DNS over UDP を使用して送信され, 必要な場合にのみ DNS over TCP に切り替える必要があるという歴史的な先例に従う必要があります [RFC1123]。UDP を優先するこの要件は, その後緩和されました [RFC7766]。

より最近の先例に沿って, DNS Push Notification は TCP に対してのみ定義されています。DNS Push Notification クライアントは, TLS over TCP [RFC7858] 上で実行される DNS Stateful Operations [RFC8490] を使用しなければなりません。

TCP 上の接続設定は, 返信の到達可能性を保証し, サーバーでの状態過負荷の懸念を軽減します。これは, コネクションレスプロトコルの潜在的な問題であり, スプーフィングされたソースアドレスを使用する攻撃者によって悪用されやすくなります。TCP の 3 ウェイハンドシェイクにより, すべてのサブスクライバーがサーバーによって到達可能であることが保証されます。フラッディング攻撃はどのプロトコルでも可能ですが, TCP の利点は, SYN フラッディングおよび同様の攻撃に対する防御のために既に確立された業界のベストプラクティスが存在することです [SYN] [RFC4953]。

TCP の使用により, DNS Push Notifications は, Multipath TCP (MPTCP) [RFC8684], TCP Fast Open (TFO) [RFC7413], TCP RACK 高速損失検出アルゴリズム [TCPRACK] などの TCP の現在および将来の開発を活用することもできます。

Transport Layer Security (TLS) [RFC8446] はよく理解されており, TCP 上で実行される多くのアプリケーション層プロトコルによって使用されています。TLS は, 盗聴, 改ざん, およびメッセージ偽造を防ぐように設計されています。このプロトコル仕様では, クライアントサブスクライバーとサーバー間のすべての接続に TLS が必要です。TLS ネゴシエーション中のクライアント認証などの追加のセキュリティ対策を使用して, クライアントとサーバー間の信頼関係を高めることもできます。