サブドメインが保護されている場合でも、TLDがDNSSECで保護されていない場合に考えられるセキュリティの問題は何ですか？
私たちは、BIND9サーバー（および他の多くのサービス）が実行されている安定したネットワークに取り組んでいます。私は、現在に準拠するように古い構成ファイルを学習して再編成しようとしています（多くのデッドマシン、未使用の名前、リバースマッピングなど）。
それまでの間、ベストプラクティスに従い、DNSSECでDNSを保護したいと思います。構成を確認しているときに、使用しているTLDがDNSSECで保護されていないことに気付きました。
私の質問：2階（スーパードメイン）で誰もそうしていない場合、DNSSECでDNSを保護することに何か意味がありますか（そうだと思います）？
私たちのゾーン/ドメインスペースは、私たちの大学ドメインの下、ve.スペース（ベネズエラTLD）のすぐ下にあります。つまり、example.university.ve.のようなものはveも私たちの大学のDNSも保護されていません。
とにかくサブドメインを保護する必要がある場合でも、攻撃者が来た場合に安全でないTLDがどのような問題を引き起こすのかを知りたいと思います。
PS： http://dnsviz.net/ や https://dnssec-debugger.verisignlabs.com/ などのツールを使用してDNSSECconfをチェックしました。
DNSSECのセキュリティは、特定のデータ（Aレコードのセットなど）から既知の信頼できる公開鍵（「トラストアンカー」と呼ばれる）への暗号で検証された委任チェーンを持つことから得られます。今日のDNSSECの場合、通常使用されるトラストアンカーは ルートゾーンキー です。親ゾーンが署名されていない場合、ゾーンからルートゾーンへのチェーンが切断され、DNSSECのセキュリティ保証は完全に失敗します。ゾーンに署名するかどうかは関係ありません。これは、ゾーンに署名するために使用したキーを信頼する理由が他にないためです。キーを作成してゾーンに署名できるのと同じように、悪者はキーを作成して（おそらくわずかに変更された）データに署名することができます。トラストアンカーへの署名されたチェーンがないと、サードパーティはあなたのキーと悪者のキーのどちらを信頼すべきかを知る方法がありません。
これで、特定の他の人にあなたの署名を信頼してもらいたい場合は、ドメインのトラストアンカーとして使用できるキーを他の人に与えることができます。これは「ルックアサイド検証」と呼ばれ、ルートゾーンが署名されてからあまり使用されていませんが、標準と実装はまだ存在しています。これがあなたにとって興味深いものであるなら、 RFC 5074 を見てください。
ただし、一般に、親ゾーンが署名されていない場合は、署名しても意味がありません。
（DNSSECを有効にするという）あなたの目標は称賛に値しますが
- dNSSECを正しく行うのは大変な作業です。ワンショットではないため、それを維持し（キーを回転させるなど）、監視する必要があります。
- あなたは他の多くの問題から始めて書いているので、DNSSECを有効にするなど、新しいプロジェクトを開始する前に、まずすべてをクリーンアップし、数週間/数か月間適切なゾーンを実行することをお勧めします
- calleが述べたように、実際、.VEはDNSSECに関するマップから完全に外れているように見えますが、すべてのレベルでDNSSECがないと（そして今から私のコメントで述べたようにDLVを使用できなくなったため）、それを自分のに追加する価値はありません。ゾーン
代わりに、.VEが実行しない理由を検索する必要があります。実行しないことを決定したか、開始することを決定したが、まだ準備段階にある可能性があります。もちろん、レジストラでも同じ問題が発生します。
自分で使用して、十分なデータとドキュメントを提供する必要があるこれらのリソースにそれらを向けることができます： http://www.internetsociety.org/deploy360/dnssec/
ところで、 https://stats.labs.apnic.net/dnssec ベネズエラのリゾルバーの10％以上がDNSSECレコードを検証していることがわかります。これは、.VETLDがDNSSECのアクティブ化を決定するのに役立つ可能性があります。