オープンDNSリカーサーまたは権限のあるDNSサーバーを実行しているかどうかにかかわらず、問題は同じであり、可能な解決策のほとんども同じです。
最適なソリューション
DNS Cookieは、クライアントIPアドレスがスプーフィングされていないことを証明するために、クライアントにCookieの送信を要求する方法をDNSサーバーに提供する提案された標準です。これにより、最初のルックアップに追加のラウンドトリップが1つかかります。これは、ソリューションが提供できる最小のオーバーヘッドです。
古いクライアントのフォールバック
DNS Cookieはまだ標準化されていないため、現在および今後数年間は、古いクライアントをサポートする必要があります。
DNS Cookieのサポートなしで、クライアントからのリクエストを制限することができます。ただし、レート制限により、攻撃者はDNSサーバーにDoSを簡単に送信できます。一部のDNSサーバーには、権限のあるDNSサーバー専用に設計されたレート制限機能があることに注意してください。あなたは再帰的なリゾルバについて尋ねているので、そのようなレート制限の実装はあなたに適用できないかもしれません。設計上のレート制限はサーバーのボトルネックになるため、攻撃者が送信するトラフィックが少なくなり、正当なリクエストがレート制限がない場合よりもドロップされます。
レート制限の利点の1つは、攻撃者がDNSサーバーをDNS要求であふれさせた場合、サーバーにsshして状況を調査できる容量が残っている可能性が高いことです。さらに、多くの要求を送信するクライアントIPからの要求を主にドロップするようにレート制限を設計できます。これにより、スプーフィングクライアントIPにアクセスできない攻撃者からのDoSから保護できます。
これらの理由から、実際に増幅から保護されていなくても、実際のキャパシティの下にあるレート制限は良いアイデアかもしれません。
TCPを使用する
回答がUDPには大きすぎることを示すエラーコードを送信することにより、クライアントにTCPを使用させることができます。これにはいくつかの欠点があります。追加の往復が2回かかります。また、一部の障害のあるクライアントはサポートしていません。
2回の追加ラウンドトリップのコストは、このアプローチを使用した最初のリクエストのみに制限できます。
クライアントIPが確認されていない場合、DNSサーバーは切り捨てられた応答を送信して、クライアントを強制的にTCPに切り替えることができます。切り捨てられた応答は、要求と同じくらい短くすることができ(クライアントがEDNS0を使用し、応答が使用しない場合は短くなります)、増幅を排除します。
TCPハンドシェイクを完了し、接続でDNS要求を送信するクライアントIPは、一時的にホワイトリストに登録できます。ホワイトリストに登録されると、IPはUDPクエリを送信し、最大512バイト(EDNS0を使用している場合は4096バイト)までのUDP応答を受信します。UDP応答がICMPエラーメッセージをトリガーした場合、IPはホワイトリストから再び削除されます。
この方法は、ブラックリストを使用して逆にすることもできます。これは、クライアントIPがデフォルトでUDPを介したクエリを許可されることを意味しますが、ICMPエラーメッセージによりIPがブラックリストに登録され、TCPクエリを使用してブラックリストを取得する必要があります。
関連するすべてのIPv4アドレスをカバーするビットマップは、444MBのメモリに保存できます。IPv6アドレスは他の方法で保存する必要があります。
DNSサーバーがこのアプローチを実装しているかどうかはわかりません。
一部のTCPスタックが増幅攻撃で悪用される可能性があることも報告されています。ただし、これはDNSだけでなく、TCPベースのサービスに適用されます。このような脆弱性は、SYNパケットに応答して複数のパケットを送信しないようにTCPスタックが修正されたカーネルバージョンにアップグレードすることで軽減する必要があります。