DNSクエリは常にUDPを経由しますか？
私はこのトピックを調査するのに少し時間を費やしましたが、正確な答えを見つけることができないようですので、それが重複ではないと確信しています。私の質問はセキュリティのニーズに基づいていますが、それでも安全だと思いますここで質問しますが、セキュリティコミュニティを移動する必要があるかどうかを教えてください。
基本的に、DNSクエリはTCPを使用しますか（そうである場合、これが発生する可能性のあるシナリオ））？繰り返しますが、私はクエリについてのみ話します。TCP経由で移動することは可能ですか？ドメインが最大長は253バイトのみで、UDPパケットは512バイトまで可能ですが、クエリは常にUDPとして送信されませんか？解決可能なクエリは、TCPの使用を必要とするほど大きくなるとは思いませんでした。DNSサーバーが253バイトを超えるドメインに対する要求を受け取った場合、サーバーはそれをドロップしますか、それを解決しようとしませんか？ここで誤った仮定をしたことは確かです。
状況によっては、セキュリティグループと協力してDNSクエリをセキュリティ監視ツールにオンボードします。さまざまな理由により、DNSサーバーとドメインコントローラーで標準のパケットキャプチャを介してこのトラフィックをキャプチャすることにしました。中心的な要件は、すべてのDNSクエリをキャプチャして、特定のドメインを解決しようとしたクライアントを識別できるようにすることです。この要件に基づいて、DNS応答やゾーン転送などのその他のトラフィックのキャプチャは関係ありません。これは、ログの量をできるだけ制限する必要があるという事実によっても推進されます。そのため、DNSサーバー宛てでUDP経由で送信されたDNSクエリのみをキャプチャすることを計画しています。より多くのコンテキスト（ここでは質問スコープが忍び寄るようなもの）のために、セキュリティの可視性を拡張して、DNSで実行されている隠れチャネル（DNS応答もキャプチャする必要があることなど）のようなアクティビティを監視できるようにする必要があるかもしれません。 TCPトラフィック）。しかし、そのようなシナリオでも、送信DNSトラフィックはルックアップ/クエリの形式であり、これらのトラフィックは常にUDP上にあると考えました悪意のあるソースから（最初の段落での私の推論のため）これにより、いくつかの追加の質問が表示されます。
私は少なくとも、私が概説したアプローチで会話の半分をとらえるでしょうか？または、クライアントはクエリの形式ではないDNSトラフィックを送信しますか？ （おそらく、DNSサーバーの応答に対するある種の応答のようであり、最終的にはTCP経由で送信されることになります）
TCPを使用するようにDNSクエリを変更できますか？ DNSサーバーは、TCP経由のDNSクエリを受け入れて応答しますか？
妥当かどうかはわかりませんが、DNSリクエストを許可されたDNSサーバーに制限し、ポート53経由で送信される他のすべてのトラフィックをブロックします。私は間違いなく新人なので、質問に準拠していない場合は申し訳ありません。修正方法。
通常のDNSクエリはUDPポート53を使用しますが、より長いクエリ（> 512オクテット）は「切り捨てられた」応答を受け取り、TCP 53会話が発生してクエリ全体を送受信しやすくなります。また、 、DNSサーバーはポート53にバインドしますが、クエリ自体はポート53に送信されたランダムな番号の大きいポート（49152以上）から発信されます。応答はポート53からこの同じポートに返されます。
DNSで使用されるネットワークポート| Microsoft Docs
したがって、ネットワークからのDNSクエリでセキュリティスヌーピングを行う予定の場合は、上記を考慮する必要があります。
非ルックアップトラフィックについては、DNSもゾーン転送（クエリタイプAXFR）を使用して、他のDNSサーバーを新しいレコードで更新することを考慮してください。中間の攻撃者は、そのような転送から始まり、プライマリネームサーバーをDDOSにして、更新されたレコードを要求するセカンダリに応答するにはビジー状態になります。次に、ハッカーは同じプライマリをスプーフィングして「汚染された」レコードをセカンダリにフィードし、人気のあるDNSドメインを侵害されたホストにリダイレクトします。
したがって、セキュリティ監査ではクエリタイプAXFRに細心の注意を払い、DNSシステムでは特定のIPアドレスからのAXFR交換のみを受け入れる必要があります。
これはジョージの答えへのコメントとして始まりましたが、長くなりました。いくつかの歴史を理解する必要があるため、大きな図はやや複雑です。
RFC 1035 UDPフラグメンテーションを回避するために、最初は512バイトの制限で呼び出されました。断片化されたUDPデータグラムとTCPは、DNSトランザクションのオーバーヘッドを最小限に抑えるために、最後の手段として選択されました。ゾーン転送は常に512バイトを超えるため、ゾーン転送は常にTCPを使用します。性質（UDPから始めるのは帯域幅の浪費です）
切り捨て時のTCP再試行は、1989年以降 RFC 112 で指定されているため、広くサポートされています。
EDNS（0）は RFC 6891 （2013）によって定義され、それ以前は提案された標準 1999年まで遡る として存在していました。これは、クライアントとサーバーが512を超えるUDPサイズをネゴシエートできるメカニズムを定義します。EDNS（0）の新しさにより、多くのハードウェアアプライアンスは、準拠パケットが破棄される原因となるDNSパケットの構造について想定しています。最も一般的な理由は、512バイトを超えるDNSメッセージは無効であるという想定ですが、これはいくつかの1つです。
これを観察された動作に分解すると、次のようになります。
- DNSクエリ通常応答が大きすぎて開始できないことが事前にわかっている場合を除き、UDPとして開始します。 （ゾーン転送）
- 応答mayトリガーa TCP切り捨てられた応答が見られた場合、クライアントで再試行します。これはかなりよくサポートされています。
- 512バイトを超えるUDP応答mayクライアントがEDNS（0）を使用してより大きなペイロードをアドバタイズした場合に表示されますand受信サーバーがそれをサポートします。これは発生するだけですif 2つの間にあるハードウェアは干渉せず、パケットのドロップや破損が発生します。
- クライアントmay応答が見られない場合、より小さなアドバタイズされたペイロードでEDNS（0）クエリを再試行することを選択しますが、詳細は実装間で異なります。
- 最終的にそれを通過する応答が、要求されたサイズに収まらないほど大きくなる可能性があることに注意することが重要です。これにより、上記の動作＃2が発生します。 （はいTCP再試行）
- クライアント側may最終的に成功したサイズを覚えておくことを選択します。これにより、不要なクエリが無駄になるのを防ぎ、再度検索することができます。そうでなければ、特に最終結果が必要な場合TCPフォールバックの場合、非常に無駄になります。
RFC 7766ではTCPを介した接続の再利用が可能 であり、実際にTCPを介してクエリのパイプライン処理が発生する可能性があります。一部のツールしないTCPセッションで最初に見られるDNSクエリを超えてDNSクエリを検出します。dnscapはその例です。
ありisRFC 7766、DNS Transport over TCP-実装要件。
- 前書き
ほとんどのDNS [ RFC1034 ]トランザクションはUDP [ RFC768 ]を介して行われます。 TCP [ RFC79 ]は常にフルゾーン転送（AXFRを使用）に使用され、サイズがDNSプロトコルの元の512バイト制限を超えるメッセージによく使用されます。 DNSセキュリティ（DNSSEC）とIPv6の展開の拡大により、応答サイズが増加し、したがってTCPの使用が増加しています。TCP使用の増加の必要性は、アドレススプーフィングに対する保護によっても推進されており、そのためリフレクション/増幅攻撃におけるDNSの悪用。これは現在、レスポンスレート制限[ RRL1 ] [ RRL2 ]で広く使用されています。さらに、[ DNS-over-TLS ]は、DNS-over-TCP要件を再検討するもう1つの動機です。
DNS resolvers and recursive servers MUST support UDP, and SHOULD support TCP, for sending (non-zone-transfer) queries.ただし、一部の実装者は、上記のテキストを引用して、TCPサポートはDNSプロトコルのオプション機能であることを意味します。
ほとんどのDNSサーバーオペレーターは既にTCPをサポートしており、ほとんどのソフトウェア実装のデフォルト構成はTCPをサポートすることです。このドキュメントの主な対象読者は、TCPのサポートが制限されており、相互運用性を制限し、新しいDNS機能の展開を妨げている実装者です。
したがって、このドキュメントでは、コアDNSプロトコル仕様を更新して、TCP=のサポートが、今後、完全なDNSプロトコル実装の必須の部分になるようにします。
TCP（ 付録A を参照）の使用の増加には、考慮が必要な実装の詳細だけでなく、いくつかの利点と欠点があります。このドキュメントでは、これらの問題とTCP DNSの有効なトランスポート代替として提示します。これは、[ RFC5966 ]の内容を拡張し、=の研究、開発、実装から得られた追加の考慮事項と教訓を追加しますTCP DNSおよび他のインターネットプロトコル。
このドキュメントでは、DNSサーバーのオペレーターが満たす必要のある特定の要件はありませんが、サーバーとネットワークでのTCPのサポートが最適であることを確認するのに役立ついくつかの提案をオペレーターに提供しています。注意してください。サポートの失敗TCP（またはDNS over TCPネットワーク層でのブロッキング）は、おそらく解決の失敗および/またはアプリケーションレベルのタイムアウトになります。
TCP/53をどの方向にもフィルタリングしないでください。たとえば、nsupdateクエリでは、TCPが使用される可能性があります（リクエストが大きすぎるとすぐに発生する可能性があります）。したがって、UDPとTCPポート53（IPv4およびV6の場合）の場合、全方向に流れます。
また、TLS over DNSへの取り組みがますます進んでいるため、TCPが両方向で必要になります。RFC7858を参照してください。