DNSSECを提供することで、どのようなセキュリティの脆弱性が現れますか？
DNSSECでDNSゾーンに署名することを計画していました。私のゾーン、レジストラ、およびDNSサーバー（BIND9）はすべてDNSSECをサポートしています。 DNSSECをサポートしていないのは、私のセカンダリネームサーバープロバイダー（つまり buddyns.com ）だけです。
彼らのウェブサイトで 、彼らはDNSSECに関してこれを述べています：
BuddyNSは、大量のDNSサービスに適さないいくつかの脆弱性にさらされるため、DNSSECをサポートしていません。
まあ、ほとんどのリゾルバーはレコードが正しく署名されているかどうかをチェックしないので、DNSSECの使用は現在何らかの形で疑わしいと思いました。彼らの発言によると、私が知らなかったのは、それを提供すると何らかのセキュリティの脆弱性が露呈するように思われるということでした。
それらの「脆弱性」とは何ですか？
DNSSECにはいくつかのリスクがありますが、反射や増幅とは直接関係ありません。 EDNS0メッセージサイズの拡張は、この場合、赤のニシンです。説明させてください。
以前のIDの証明に依存しないパケットの交換は、DDoS攻撃者による悪用の対象となります。DDoS攻撃者は、認証されていないパケット交換をリフレクターとして、またおそらくは増幅器としても使用できます。たとえば、ICMP（「ping」の背後にあるプロトコル）はこのように悪用される可能性があります。 TCP SYNパケットも同様です。SYNパケットは、SYNがそれらのSYN-ACKパケットを望まない犠牲者から来るように偽装されている場合でも、最大40のSYN-ACKパケットを要求します。そしてもちろん、NTP、SSDP、uPNPを含むすべてのUDPサービスがこの攻撃に対して脆弱であり、ここで他の応答で言及されているように、DNSも含まれています。
ほとんどの侵入検知、侵入防止、ロードバランサアプライアンスはボトルネックであり、「ラインレート」トラフィックに対応できません。また、多くのルーターはラインレートで実行できず、一部のスイッチも動作しません。これらのボトルネックは、「パス内」の最小のものであり、リンク自体よりも小さいため、輻輳ベースのDDoS攻撃の実際のターゲットです。誰かのファイアウォールを攻撃トラフィックでビジー状態に保つことができる場合、リンクがいっぱいでなくても、良好なトラフィックは通過しません。また、ファイアウォールの速度を低下させるのは、1秒あたりの総ビット数（より大きなメッセージを使用して増やすことができ、EDNS0とDNSSECが実行する）ではなく、1秒あたりのパケットの総数です。
DNSSECのメッセージサイズが大きいためにDNSSECがDDoSをどのように悪化させるかについては、都市の伝説がたくさんあります。これは直感的に理解でき、「音がいい」のですが、それは単に誤りです。しかし、この伝説に真実の断片があったとしても、実際の答えは他の場所にあります-[DNSSECは常にEDNS0を使用しますが、EDNS0はDNSSECなしで使用できるため]、多くの通常の非DNSSEC応答はDNSSECと同じ大きさです応答になります。 SPFポリシーまたはDKIMキーを表すために使用されるTXTレコードを検討してください。または、大規模なアドレスまたはMXレコードのセットのみを検討してください。要するに、攻撃にはDNSSECは必要ないため、DDoSとしてDNSSECに焦点を当てる必要はありませんリスクは、エネルギー不足です。
DNSSECにはリスクがあります。使いづらく、正しく使うのも難しいです。多くの場合、ゾーンデータの変更、レジストラ管理、新しいサーバーインスタンスのインストールのための新しいワークフローが必要です。これらすべてをテストして文書化する必要があり、DNSに関連する問題が発生した場合は常に、DNSSECテクノロジを考えられる原因として調査する必要があります。そして、もしあなたがすべてを正しくやれば、最終的な結果は、ゾーン署名者として、あなた自身のオンラインコンテンツとシステムがあなたの顧客にとってより脆弱になるということです。遠端のサーバーオペレーターとしての結果は、他のすべてのユーザーのコンテンツとシステムがより脆弱になることです。唯一の利点は、DNSデータを機内での変更または置換から保護することであるため、これらのリスクは利点を上回ることがよくあります。その攻撃は非常にまれであり、この努力のすべてに値するものではありません。 DNSSECが可能にする新しいアプリケーションにより、いつの日かDNSSECがユビキタスになることを望んでいます。しかし、真実は、今日、DNSSECはすべてコストがかかり、利益がなく、リスクが高いことです。
したがって、DNSSECを使用したくない場合、それはあなたの特権ですが、DNSSECの問題がDDoS増幅器としての役割であることをだれにも混乱させないでください。 DNSSECは、DDoS増幅器としての必要な役割はありません。 DNSをDDoS増幅器として使用するには、他に安価で優れた方法があります。 DNSSECを使用したくない場合は、クールエイドをまだ飲んでいないため、最初の発動者（現在）ではなく、最後の発動者（後で）になりたいためです。
DNSはUDPを使用し、UDPはスプーフィングされたソースパケットによって悪用されるため、DNSコンテンツサーバーは、 "権限サーバー"と呼ばれることもあります。この種の不正行為からDNSコンテンツサーバーを保護する方法は、UDPをブロックしたり、TCP（TC = 1トリックを使用））を強制したり、ANYクエリをブロックしたり、 DNSSECをオプトアウトします。これらはどれも役に立ちません。 DNS応答速度制限 （DNS RRL）が必要です。これは、BIND、Knot、とNSD。ファイアウォールに関するDNSリフレクションの問題を修正することはできません。DNSサーバー自体（RRLが追加されている）などのコンテンツ認識ミドルボックスだけが要求を十分に認識しているため、攻撃とは何かを正確に推測できます。強調しておきたいのは、DNS RRLは無料であり、すべての機関サーバーがそれを実行する必要があるということです。
最後に、自分の偏見を明らかにしたいと思います。 BIND8のほとんどを作成し、EDNS0を発明し、DNS RRLを共同で発明しました。私は1988年以来20代としてDNSに取り組んできましたが、今では50代で不機嫌になり、誤解されている問題に対する中途半端な解決策に対する忍耐がますます少なくなっています。このメッセージが「こんにちは、子供たち、私の芝生を手に入れよう！」のように聞こえる場合は、謝罪を受け入れてください。
2つの特定の脆弱性を知っています。 Håkanによって言及された反射/増幅があります。そして、ゾーン列挙の可能性があります。
反射/増幅
リフレクションとは、ソースIPが偽装されたリクエストがDNSサーバーに送信される攻撃を意味します。なりすましのホストは、攻撃の主な被害者です。 DNSサーバーは、知らないうちに、要求していないホストに応答を送信します。
増幅とは、反射された応答が元の要求よりも多くのバイトまたはより多くのパケットで構成される反射攻撃を指します。 DNSSEC + EDNS0以前は、このように増幅すると、最大512バイトしか送信できませんでした。 DNSSEC + EDNS0を使用すると、4096バイトを送信することが可能です。これは、通常3〜4パケットに及びます。
これらの攻撃には緩和策が考えられますが、それらを実装しているDNSサーバーについては知りません。
クライアントIPが確認されていない場合、DNSサーバーは切り捨てられた応答を送信して、クライアントを強制的にTCPに切り替えることができます。切り捨てられた応答は、要求と同じくらい短くなる（またはクライアントがEDNS0を使用し、応答が使用しない場合は短くなる）ため、増幅がなくなります。
TCPハンドシェイクを完了し、接続でDNS要求を送信するクライアントIPは、一時的にホワイトリストに登録できます。ホワイトリストに登録すると、IPはUDPクエリを送信し、最大512バイト（4096バイト）のUDP応答を受信します。 EDNS0を使用している場合）。UDP応答がICMPエラーメッセージをトリガーした場合、IPはホワイトリストから再度削除されます。
また、ブラックリストを使用してメソッドを逆にすることもできます。つまり、クライアントIPはデフォルトでUDPを介してクエリを実行できますが、ICMPエラーメッセージによってIPがブラックリストに登録され、TCPクエリを取得する必要があります。ブラックリストから。
関連するすべてのIPv4アドレスをカバーするビットマップは、444MBのメモリに格納できます。 IPv6アドレスは他の方法で保存する必要があります。
ゾーン列挙
そもそもゾーンの列挙が脆弱性であるかどうかは議論の的です。ただし、ゾーン内のすべての名前を公開したくない場合は、脆弱性と見なす可能性があります。ゾーンの列挙は、NSEC3レコードを使用することでほぼ軽減できます。
NSEC3を使用しても依然として持続する問題は、ランダムな名前を照会するだけで攻撃者が各ラベルのハッシュを見つけることができることです。攻撃者がすべてのハッシュを取得すると、それらのハッシュに対してオフラインのブルートフォース攻撃を実行できます。
ゾーンの列挙に対する適切な防御には、攻撃者がすべての推測について権限のあるサーバーにクエリを実行する必要があります。ただし、DNSSECにはそのような防御策はありません。
頭に浮かぶのは、実際にはDNSSEC固有ではなく、DNSSECが依存しているEDNS0拡張についてです。
EDNS0はより大きなUDPペイロードを可能にし、より大きなUDPペイロードはより悪いトラフィック反射/増幅攻撃を可能にします。
検証リゾルバーのパーセンテージはわかりませんが、人気のあるネームサーバーソフトウェアはデフォルトで検証がオンで出荷されているようで、ComcastやGoogleパブリックリゾルバ。
これに基づくと、検証リゾルバーのパーセンテージは、署名されたゾーンのパーセンテージよりもおそらくかなり良い形になっていると思います。