ユーザー・データグラム・プロトコル(UDP)は、RFC 768で定義された接続不要のトランスポート層プロトコルであり、最小限のオーバーヘッドで独立したメッセージを送信します。そのため、低遅延とサーバー状態の最小化が重要な運用要件となるDNSクエリやDHCPアドレス割り当てにおいて、デフォルトの選択肢となっています。 UDPは、トランスポート層での接続確立、確認応答、再送信を排除し、エラー処理をアプリケーションに委ねることで、信頼性や順序付き配信を犠牲にして速度を優先しています。 運用上、UDPの障害は明示的なエラーではなく、検知されないパケット損失やタイムアウトとして現れるため、断続的なDNS解決の失敗や、リフレクション増幅攻撃などのセキュリティ上の脆弱性を回避するには、慎重なネットワーク監視とファイアウォールの設定が必要となる。
UDPの仕組み
UDPは、アプリケーションデータを小さなデータグラムに包み込み、IPに渡します。トランスポート層では、接続の確立、確認応答、再送信は行われません。
- アプリケーションによるメッセージの構築:DNSリゾルバーなどのアプリケーションは、1つのデータグラムに収まる完全なリクエストを作成します。
- UDPはヘッダーを追加します。UDPは、送信元ポート、宛先ポート、長さ、チェックサムを含む8バイトのヘッダーを先頭に付加します。
- IPによるデータグラムの配信:データグラムはIPパケットとして伝送されます。各データグラムは個別にルーティングされるため、紛失、重複、または順序が入れ替わる可能性があります。
- 受信側がデータをアプリケーションに渡す:受信ホストは、宛先ポート(例えば、DNSの場合は53)を使用して、ペイロードを適切なサービスに渡します。
- アプリケーションによるパケット損失への対応:応答が届かない場合、アプリケーションが対応を決定します。通常はタイムアウトの後、再試行が行われ、場合によっては別のサーバーに対して再試行が行われます。
UDPは、輻輳制御、順序保証、または配信保証を提供しません。DNSは、応答が切り捨てられた場合や、ゾーン転送などの転送で信頼性の高い配信が必要な場合に、TCPに切り替わります。DHCPは、アドレスを持たないクライアントがTCP接続を維持できないため、UDPを使用します。
UDPの一般的な問題
TCP 53のみを許可するルールでは、ゾーン転送は機能しますが、通常のルックアップはタイムアウトします。クライアントでは断続的に解決に失敗し、パケットキャプチャを確認すると、クエリが送信されたものの応答がないことがわかります。
クライアントが通知したUDPペイロードサイズを超える応答は切り捨てられ、クライアントはTCP経由で再試行する必要があります。TCP 53がブロックされている場合、DNSSECで署名されたレコードなどの大きな応答は失敗しますが、小さな応答は成功します。
パスMTUを超える大きなUDPデータグラムはフラグメント化されますが、多くのファイアウォールやミドルボックスはフラグメントを破棄します。この現象の症状として、特定のクエリのみがタイムアウトすることがあり、多くの場合、応答サイズが大きいクエリで発生します。
ファイアウォールやNATデバイスは、短いアイドルタイマーを使用してUDPフローを追跡します。アップストリームからの応答が遅いと、マッピングの有効期限が切れた後に到着し、破棄されてしまうため、クライアント側ではタイムアウトと認識されます。
UDPは配信確認を返さないため、輻輳やインターフェースのキューが満杯になった場合は、アプリケーションによる再試行や遅延としてのみ現れます。エンジニアは、トランスポートエラーを想定するのではなく、インターフェースのドロップカウンターやサーバーログを確認する必要があります。