DNSSECを提供すると、どのようなセキュリティの脆弱性が露呈しますか？

DNSSECでDNSゾーンに署名することを計画していました。私のゾーン、レジストラ、およびDNSサーバー（BIND9）はすべてDNSSECをサポートしています。DNSSECをサポートしていないのは、私のセカンダリネームサーバープロバイダー（つまりbuddyns.com）だけです。

彼らのウェブサイトで、彼らはDNSSECに関してこれを述べています：

BuddyNSは、大量のDNSサービスに適さないいくつかの脆弱性にさらされるため、DNSSECをサポートしていません。

ほとんどのリゾルバはレコードが正しく署名されているかどうかをチェックしないので、DNSSECの使用は現在何らかの形で疑わしいと思いました。私が知りませんでした-彼らの声明によると-それを提供することは何らかの種類のセキュリティ脆弱性を公開するようです。

それらの「脆弱性」とは何ですか？

DNSSECにはいくつかのリスクがありますが、それらは反射や増幅に直接関係しません。この場合、EDNS0メッセージサイズの拡張は、赤いニシンです。説明させてください。

以前の身元証明に依存しないパケット交換は、その未認証のパケット交換をリフレクタとして、またおそらくはアンプとして使用できるDDoS攻撃者による悪用の対象となります。たとえば、ICMP（「ping」の背後にあるプロトコル）はこの方法で悪用される可能性があります。SYNがそれらのSYN-ACKパケットを望まない被害者から来たようになりすました場合でも、最大40のSYN-ACKパケットを要求するTCP SYNパケットと同様に。そしてもちろん、NTP、SSDP、uPNPを含むすべてのUDPサービスは、この攻撃に対して脆弱です。また、DNSを含む他の応答で示されているように。

ほとんどの侵入検知、侵入防止、およびロードバランサアプライアンスはボトルネックであり、「ラインレート」トラフィックに対応できません。また、多くのルーターはラインレートで動作できず、一部のスイッチも動作します。これらのボトルネックは、「パス内」の最小のものであり、リンク自体よりも小さいため、輻輳ベースのDDoS攻撃の実際のターゲットです。攻撃トラフィックで誰かのファイアウォールをビジー状態に保つことができる場合、リンクがいっぱいではなくても、良好なトラフィックは通過しません。また、ファイアウォールの速度を低下させるのは、1秒あたりの総ビット数ではなく（より大きなメッセージを使用することで増加でき、EDNS0とDNSSECでも可能です）、1秒あたりの総パケット数です。

DNSSECのメッセージサイズが大きいためにDNSSECがDDoSを悪化させることについて、多くの都市伝説がありますが、これは直感的に理にかなっており、「良い音」ですが、それは単純に間違っています。しかし、この伝説に真実が刻まれていれば、本当の答えはまだ他の場所にあります-（DNSSECは常にEDNS0を使用しますが、DNSSECなしでEDNS0を使用できるため）、多くの通常の非DNSSEC応答はDNSSECと同じくらい大きいです応答になります。SPFポリシーまたはDKIMキーを表すために使用されるTXTレコードを検討してください。または、アドレスまたはMXレコードの大規模なセット。要するに、DNSSECを必要とする攻撃はないため、DDoSリスクとしてDNSSECに重点を置くのはエネルギーの浪費です。

DNSSECにはリスクがあります！使用するのが難しく、正しく使用するのが難しくなります。多くの場合、ゾーンデータの変更、レジストラ管理、新しいサーバーインスタンスのインストールのための新しいワークフローが必要です。これらはすべてテストおよび文書化する必要があり、DNSに関連する何かが壊れるたびに、DNSSECテクノロジーを考えられる原因として調査する必要があります。そして、あなたがすべてを正しくすれば、最終結果は、ゾーン署名者として、あなた自身のオンラインコンテンツとシステムがあなたの顧客により脆弱になるということです。遠端サーバーオペレーターとしての結果は、他のすべてのユーザーのコンテンツとシステムがより脆弱になることです。これらのリスクは多くの場合、メリットを上回ると考えられています。これは、DNSデータを実行中の変更または置換から保護することだけだからです。この攻撃は非常にまれであるため、この努力のすべての価値はありません。DNSSECが可能にする新しいアプリケーションのおかげで、DNSSECがいつか遍在することを願っています。しかし、真実は、今日、DNSSECはすべてコストがかかり、利益がなく、リスクが高いということです。

したがって、DNSSECを使用したくない場合、それは特権ですが、DNSSECの問題がDDoSアンプとしての役割であることをだれにも混乱させないでください。DNSSECにはDDoSアンプとしての必要な役割はありません。DNSをDDoSアンプとして使用する他の安価な方法があります。DNSSECを使用したくない場合は、まだKool Aidを飲んでおらず、先発者（今）ではなく、後発者（後）になりたいからです。

DNSはUDPを使用しているため、またUDPはスプーフィングされたソースパケットによって悪用されるため、「権限サーバー」と呼ばれることもあるDNSコンテンツサーバーは、アンプを反映する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バイト（EDNS0を使用している場合は4096バイト）までのUDP応答を受信します。UDP応答がICMPエラーメッセージをトリガーした場合、IPはホワイトリストから再び削除されます。

この方法は、ブラックリストを使用して逆にすることもできます。これは、クライアントIPがデフォルトでUDPを介したクエリを許可されることを意味しますが、ICMPエラーメッセージによりIPがブラックリストに登録され、TCPクエリがブラックリストを取得する必要があります

関連するすべてのIPv4アドレスをカバーするビットマップは、444MBのメモリに保存できます。IPv6アドレスは他の方法で保存する必要があります。

ゾーン列挙

そもそもゾーン列挙が脆弱かどうかは議論の対象です。ただし、ゾーン内のすべての名前を公開情報にしたくない場合は、おそらく脆弱性と見なします。ゾーンの列挙は、主にNSEC3レコードの使用により軽減できます。

NSEC3を使用している場合でも解決しない問題は、攻撃者がランダムな名前を照会するだけで各ラベルのハッシュを見つけることができることです。攻撃者がすべてのハッシュを取得すると、それらのハッシュに対してオフラインの総当たり攻撃を実行できます。

ゾーンの列挙に対する適切な防御のためには、攻撃者が推測ごとに権限のあるサーバーにクエリを実行する必要があります。ただし、DNSSECにはそのような防御策はありません。

頭に浮かぶのは、実際にはDNSSEC固有ではなく、DNSSECが依存するEDNS0拡張に関するものです。

EDNS0は、より大きなUDPペイロードを可能にし、より大きなUDPペイロードは、より悪いトラフィック反射/増幅攻撃を可能にします。

リゾルバの検証の割合がわからないが、一般的なネームサーバーソフトウェアはデフォルトで検証が有効になっているようで、ComcastやGoogleパブリックリゾルバなど、検証を行っている有名なサービスプロバイダを簡単に見つけることができます。

これに基づいて、リゾルバを検証する割合は、署名されたゾーンの割合よりもおそらくかなり良い形になっていると思います。