再帰的（ISP、パブリックなど）ネームサーバーのどの部分がDNSSECを厳密に検証しますか？
ドメインでDNSSECを初めて採用/設定しているので、期待できる実用的なメリットに興味があります。理論的には、クライアント/スタブリゾルバーがチェックを必要とするかどうかに関係なく、再帰的なネームサーバーは署名チェーンを要求できます。また、上位レベルの委任者が署名があるはずであることが示されているドメインでは、有効な署名がないことをクライアントに戻るハードルックアップエラー。これにより、ドメイン所有者を偽造レコードから保護します。現在、ISPおよびパブリック（Google、Cloudflareなど）再帰ネームサーバーのどの部分がこれを行っていますか？それは一般的ですか、それとも珍しいですか？
主に、質問の2番目の部分、つまりDNSSECの展開状態に焦点を当てたいと思います。しかし、それに入る前に、DNSポイズニングを軽減するなどの明らかな利点に加えて、DNSSECを使用しない場合の既知の脅威が他にもあることに注意することは興味深いと思いました。たとえば、2019年の最近の論文[1]は、DNSポイズニングがどのようにDV証明書を許可し、攻撃者がドメインを偽装すると同時にTLSを提供することを可能にし、正当であるかの印象を与えることを示しています！
今度は第2部について、人々はさまざまな設定でDNSSEC展開（NS側）と検証（クライアント側）の測定を行いました。 2013年の論文[2]はクライアント側でこれを行い、次の結論に達しました。
データクリーニング後、98,179の異なるIPアドレスから131,320の結果を収集しました。そのうち4.8％で検証が有効になりました。この比率は国ごとに大きく異なります。スウェーデン、チェコ共和国、および米国では、フィールドでの検証クライアントの比率が最も高くなっています。
2017年の別の[3]は、ネームサーバーとリゾルバーの両方でサポートを測定しました。
この方法論を使用して、2017年の初めに13日間で177か国、8,842のASからの合計403,355の出口ノードを測定します。これらの出口ノードは、合計59,513の一意のリゾルバを使用します。 49,424のリゾルバー（83.0％のリゾルバー、65.9％の出口ノードをカバー）がDOビットが設定された要求を送信することがわかり、大多数のリゾルバーがDNSSECをサポートしていることを示唆しています
ここにコピーした抜粋は全体像をカバーしていないので、これらの論文を読むことをお勧めします。最後に、 SecSpider をチェックアウトして、DNSSEC展開の最新状態の概要を確認したり、 DNSViz を使用してホスト名のDNSSECを視覚化したりすることもできます。クライアント側でDNSSECを強制したい場合は、NLnet Labsの DNSSEC Trigger をお勧めします。
個人的には、DNSSECの浸透が遅いのも、エンドユーザーの視覚的な手がかりが不足していることに関係していると思います。認証された安全なチャネルを示す緑色の南京錠とは対照的に、認証されたDNSの結果を示すものはありません。
[1] Schwittmann、L.、Wander、M.、＆Weis、T.（2019）。ドメインのなりすましが可能：CAドメイン検証の脆弱性の調査。 Proceedings-4th IEEE European Symposium on Security and Privacy、EURO S and P 2019、544–559。 https://doi.org/10.1109/EuroSP.2019.00046
[2] Wander、M。、およびWeis、T。（2013）。 DNSSEC検証の発生の測定。 M. Roughan＆R. Chang（編）、パッシブおよびアクティブ測定（pp。125–134）。スプリンガーベルリンハイデルベルク。 https://doi.org/10.1007/978-3-642-36516-4_1
[3] Chung、T.、Van Rijswijk-Deij、R.、Chandrasekaran、B.、Choffnes、D.、Levin、D.、Maggs、B。M.、Mislove、A。、およびWilson、C。（2017）。 DNSSECエコシステムの縦断的エンドツーエンドビュー。第26 USENIXセキュリティシンポジウムの議事録、1307〜1322。