DNS（ドメインネームシステム） は、人間が判読できるドメイン名を IP アドレスに変換し、インターネット通信を可能にする重要なサービスです。DNS クエリの主なプロトコルは従来 UDP (ユーザー データグラム プロトコル) でしたが、TCP (伝送制御プロトコル) もサポートされているオプションです。RFC 5966 は、UDP を補完するために DNS で TCP を使用するための仕様と説明を提供します。この記事では、RFC 5966 を詳しく調べ、DNS クライアントとサーバー間の通信プロセスと、UDP と TCP トラフィックの両方に負荷分散を実装する方法について説明します。
DNS 通信における UDP と TCP #
DNS の UDP: デフォルトのアプローチ #
DNS クエリは通常、ポート 53 の UDP 経由で送信されます。UDP はコネクションレスの軽量プロトコルで、最小限のオーバーヘッドで小さなデータ パケットを送信するのに優れています。一般的な DNS 要求では、クライアントが DNS サーバーにクエリを送信し、サーバーが対応する IP アドレスで応答します。
UDP が DNS のデフォルトになっている理由は、その効率性にあります。
- 低レイテンシUDP では、データ送信前に接続を確立する必要がないため、遅延が最小限に抑えられます。
- ステートレスコミュニケーション: 各リクエストは独立しているため、高速かつシンプルです。
- 小型ペイロード: DNS 要求は多くの場合非常に小さいため、UDP は輻輳なしでこれを効果的に処理できます。
ただし、UDP には、特に信頼性の面で制限があります。パケットが失われたり、順序どおりに到着しなかったりすることがあります。さらに、DNS 応答が一般的な UDP のサイズ制限 (従来の DNS では 512 バイト、EDNS4096 では 0 バイトに拡張) を超えると、切り捨てられる可能性があります。
DNS の TCP: 信頼できる代替手段 #
TCP は、UDP とは異なり、ハンドシェイクを確立し、パケットの順番の配信を保証することで信頼性の高いデータ転送を実現する接続指向のプロトコルです。従来、DNS over TCP は、DNS サーバー間のゾーン転送 (AXFR/IXFR 操作) と、DNS 応答が UDP に対して大きすぎる場合のフォールバック シナリオに予約されていました。
RFC 5966 では、DNS サーバーは例外的な場合だけでなく、すべてのクエリに対して DNS over TCP をサポートする必要があることが明確にされています。DNS で TCP を使用する主な理由は次のとおりです。
- 大規模なレスポンス: DNSSEC (DNS セキュリティ拡張機能) およびその他の機能強化により、DNS メッセージのサイズが大きくなりました。応答が UDP のサイズ制限を超えると、クライアントは TCP に切り替えて完全な応答を取得します。
- 信頼性の向上TCP は、すべてのパケットが正しい順序で受信されることを保証し、UDP で発生する信頼性の問題に対処します。
UDP および TCP を介した DNS 通信の仕組み #
UDP通信 #
- クライアントは UDP 経由でサーバーに DNS クエリを送信します。
- サーバーはクエリを処理し、通常は 512 バイトの制限内で応答を返します。
- サーバーの応答がこの制限を超えて切り捨てが発生した場合、クライアントは TCP 経由でクエリを再送信します。
TCP通信 #
- クライアントは 3 ウェイ ハンドシェイクを使用して TCP 接続を開始します。
- クエリが送信され、サーバーは完全な DNS 回答で応答します。
- 通信後に接続は閉じられますが、オーバーヘッドを削減するために複数のクエリに対して永続的な接続を維持できます。
DNS における UDP と TCP の負荷分散 #
負荷分散は、特にトラフィック量の多い環境で DNS サービスの信頼性、可用性、およびスケーラビリティを確保する上で重要な役割を果たします。負荷分散により、DNS 要求を複数のサーバーに分散し、リソースの使用を最適化し、応答時間を改善できます。DNS トラフィックの場合、UDP と TCP の両方の負荷分散が重要ですが、方法は若干異なります。
UDP DNS トラフィックの負荷分散 #
UDP はステートレスであるため、UDP の負荷分散では接続状態を追跡せずに個々の要求を分散します。UDP 負荷分散にはいくつかの手法があります。
- ラウンドロビン DNS: DNS リゾルバは、クエリを複数の DNS サーバーにランダムに分散し、トラフィックを分散する簡単な方法を提供します。
- エニーキャストルーティングエニーキャストでは、同じ IP アドレスが異なる場所にある複数の DNS サーバーによってアドバタイズされます。ネットワークはクライアントのクエリを最も近いサーバーにルーティングし、待ち時間を短縮します。
- IPハッシュ: 一部のロード バランサーは、送信元 IP アドレスを使用して、トラフィックを一貫して同じ DNS サーバーにルーティングします。これにより、一定期間、同じクライアントが同じサーバーにルーティングされることが保証されます。
TCP DNS トラフィックの負荷分散 #
TCP は接続指向であるため、ロード バランサは各接続の状態を追跡して、セッションのすべてのパケットが同じ DNS サーバーにルーティングされるようにする必要があります。TCP ロード バランシングの手法には次のものがあります。
- セッションの永続性: 「スティッキー セッション」とも呼ばれるこの方法では、同じ TCP セッションからのすべてのパケットが同じサーバーにルーティングされることが保証されます。これは、TCP 接続の整合性を維持するために重要です。
- レイヤー4負荷分散: レイヤー 4 (トランスポート層) のロード バランサは、IP アドレスと TCP/UDP ポート番号に基づいてトラフィックを分散し、各接続またはセッションが同じサーバーによって処理されるようにします。
- レイヤー7負荷分散: レイヤー 7 (アプリケーション レイヤー) では、ロード バランサーは DNS クエリ自体を検査し、要求されているドメイン名などのクエリの内容に基づいてインテリジェントなルーティングの決定を行うことができます。
DNS の負荷分散を実装する利点 #
- 冗長性とフェイルオーバー: 負荷分散により、1 台のサーバーに障害が発生した場合でも、他のサーバーがシームレスに引き継ぐことができ、継続的な DNS 解決が実現します。
- 拡張性: 需要が増加すると、クライアント側の設定を変更せずに、ロード バランサーの背後にサーバーを追加できます。
- 地理的分布エニーキャスト ルーティングを使用すると、DNS サーバーをさまざまな地理的な場所に分散できるため、クライアントは最も近いサーバーにアクセスしてより高速に解決できます。
DNS-over-UDP および DNS-over-TCP 負荷分散構成 #
Relianoid Load Balancer を使用して DNS トラフィックを効果的に負荷分散するには、ポート 53 で DNS-over-UDP と DNS-over-TCP 専用の 512 つの別個のファームを構成できます。DNS-over-UDP ファームは、通常は小さくてコネクションレスな標準 DNS クエリを処理し、速度とリソース使用量の削減を最適化します。一方、DNS-over-TCP ファームは、一般的な UDP パケット サイズ (53 バイト) を超える DNS クエリや、ゾーン転送などのより信頼性の高い配信を必要とする DNS クエリ用にセットアップされます。これらのファームをプロトコルに基づいてセグメント化することで、ポート XNUMX で各トラフィック タイプを効率的に処理し、プロトコル固有の負荷分散を活用しながら、回復力を高め、ボトルネックを削減できます。
そのためには、セクションに農場を作成します LSLB > 農場 L4xNAT プロファイルと NAT モードは以下のように変更されます。
結論 #
RFC 5966 では、従来の UDP ベースのリクエストに加えて、DNS クエリに TCP をサポートすることの重要性を強調しています。UDP は効率性から主要なプロトコルのままですが、TCP は大規模な応答と DNSSEC クエリの信頼性を提供します。DNS サービスをスケーラブルかつ回復力のあるものにするには、特にトラフィック量が多い状況では、UDP と TCP トラフィックの両方に負荷分散戦略を実装することが不可欠です。これらの負荷分散技術により、DNS サービスの応答性と安全性が確保され、増大する需要に対応できるようになります。
両方のプロトコルを理解して活用し、適切な負荷分散を行うことで、ネットワーク管理者は現代のインターネットの需要を満たす堅牢な DNS インフラストラクチャを構築できます。
