厳密なDNSSECチェックをオプトインする-DNSSECはゾーンが厳密な署名検証を要求する方法を提供しますか？
ドメインgood.comがすべてのDNSレコードに署名し、ホスト*.good.comの署名されていないレコードを拒否することを約束する方法はありますか？つまり、ゾーンがDNSSEC保護されていることを示す署名付きステートメントを提供し、DNSSECクライアントがそのゾーンのDNSレコードに対して厳密な署名チェックを使用できることを示唆する方法はありますか？
これは、HSTSレコード（サイトがHTTPSのみをオプトインしており、安全でないHTTP経由で接続しようとする試みを拒否することを示唆している）または厳密なチェックをオプトインするSPFポリシー（電子メールに準拠していないことを示す）に類似していますSPFポリシーでは拒否されます）。
背景（私が理解しているように）。原則として、DNSSECは中間者攻撃に対する保護を提供します。クライアントはDNS応答に有効な署名があるかどうかを確認し、署名されていない応答と無効な署名を持つ応答をすべて無視できます。残念ながら、実際には、これは 許容できない互換性コストがあります です。署名されていないすべての応答を無効として扱うと、「インターネットを破壊する」ことになります。一部のサイトは、ドメインが一貫してすべてのレコードに署名していないか、または（私が聞いたように）署名がミドルボックスによってときどき削除されるためです。
その結果、実際の展開上の理由から、 多くのDNSSEC対応クライアントは実際には検証されていません ：署名を確認しますが、署名がない場合でも、DNSSEC応答を受け入れます。 （GoogleのパブリックDNSリゾルバでも 場合によってはこれを行います 。）
これは厄介なman-in-the-middle攻撃を引き起こします。man-in-the-middleは単にすべてのDNSSECシグネチャを取り除き、好きなようにレコードを変更します。クライアントが署名されていないDNS応答を受け入れる場合、この中間者攻撃はDNSSECの値を無効にします。もちろん、この不幸な状況の反対側は、クライアントが署名されていないすべてのDNS応答を拒否した場合、中間者攻撃に対して安全である可能性がありますが、多くのレガシーサイトが機能しなくなり、許容できない互換性コストが発生します。少なくとも、これは私の理解です。
DNSSEC対応クライアントが、どのゾーンで厳密な署名検証を使用するかを通知する方法がある場合は、より良いソリューションが可能であると想像できます。特に、google.comまたはgood.comに「すべてのDNSレコードが署名されることを保証し、署名されていないすべてのレコードを無効として処理してほしい」と宣言する方法があった場合、協力するクライアントは*.good.comのDNSレコードに厳密な検証を適用し、他のゾーンの検証は行いません。これにより、従来のドメインとの互換性を確保しながら、オプトインしたいゾーンを厳密にチェックできるようになります。つまり、「インターネットを壊すことなく」中間者攻撃に対する部分的な保護を提供できます。
そのようなメカニズムは存在しますか？
DNSSecパケットには、ドメインの検証要件の伝達を担当する3つのフラグがあります。
DOビットはリゾルバーによって設定され、応答に認証リソースレコードを含める必要があることを示します。
リゾルバがセキュリティを認識している場合は、DOビットを設定する必要があります。ネームサーバーがDOビットのないメッセージを受け取った場合、認証リソースレコードを削除する必要があります。認証レコードに対する特定の要求がない限り。
このビットにより、中間ネームサーバーは署名の検証を無効にできます。これは基本的に、「検証の手間をかけないで、自分でやります。生のレコードを送ってください」
これは実際にあなたの質問に答える部分です。
ネームサーバー側は、リゾルバー側がAnswerセクションのすべてのRRsetとAuthorityセクションの関連する否定応答RRを真正であると見なす場合にのみ、ADビットを設定する必要があります（SHOULD）。
ADビットは言う、これらのレコードはそれらが署名された本物です。
安全なクエリを実行する
Www.example.comに正しいキーとリソースレコードが構成されている場合。それでも、DNSSecを理解しないクライアントに応答する必要があります。 DNSSecは下位互換性を持つように設計されており、DNSSecを理解しない要求に応答する必要があります。これはあなたが強調した脆弱性を作り出します。
ただし、プロセスは存在し、上記のフラグを使用して確実なレコードのみが受信されるようにしますが、これを行うにはリゾルバーを構成する必要があります。 Bindは DNSSec-validation フラグでこのメカニズムを提供します（デフォルトで有効になっています）
名前付きでDNSSec検証を有効にします。注DNSSec-enableを有効にするには、yesに設定する必要もあります。デフォルトはyesです。
したがって、独自のDNSリゾルバーを作成し、検証された応答のみを受け入れるように構成すると、完全な信頼チェーンが関連付けられていないドメインを解決できなくなります。ただし、DNSSecレコードのないドメインは以前と同様に機能します。
Googleのネームサーバーが同じように動作するのは、ドメインが人気がある場合、ADビットを無視するように設定しているためです。したがって、stackexchangeで証明書に問題があった場合でも、Googleは引き続きネームサーバーで解決します。これは、Google DNSを使用している大多数の人々にとって、stackexchangeがインターネットから落ちるのを防ぐ決断のようです。
実際の質問に回答するように編集されました！
安全なリゾルバを設定していて、上流の誰かがそのクエリをハイジャックできる場合、DOビットを取り除き、上流のサーバーにすべての認証レコードを取り除いてしまう可能性があります。安全なリゾルバーがそのレコードを受け取ったとき、探していたドメインに認証が設定されていなかったと単純に推定します。
この攻撃を実行するには、途中まで完全に挿入する必要はありません。発信DNSパケットを調整する機能で十分です。
これは、DNSSecの元の設計の一部と見なされていました。 RFC3833-ドメイン名システムの脅威分析 によると
TSIGやIPsecなどのチャネルセキュリティメカニズムを使用してDNSメッセージに署名したり、IPsecを使用してそれらを暗号化したりすることは確かに可能ですが、これは傍受攻撃にはあまり良いソリューションではありません。
[...]
頻繁に使用されるネームサーバー（ルートゾーンのサーバーなど）の場合、このコストはほぼ確実に法外に高くなります。ただし、さらに重要なのは、このような設計の基礎となる信頼モデルが誤っていることです。これは、せいぜいDNSメッセージのホップバイホップの整合性チェックのみを提供し、エンドツーエンドの種類を提供しないためです。整合性チェック
DNSSecは、キャッシュポイズニングなどの特定の攻撃から保護するように設計されています。中間者攻撃は、上記の理由により単純に割り引かれました。
簡単に言えば、ゾーンでDNSSECを使用する場合、すべてのレコードに署名する必要があります。したがって、このステートメントはDNSSEC署名ゾーンのデフォルトかつ唯一のポリシーであるため、このステートメントを明示的に伝達するメカニズムは必要ありません。
例外はありません。 NSEC3オプトアウトメカニズムですが、これはTLDなどの委任のみのゾーンを対象としています。これは、DNSSECが有効になっている子ゾーンのみに署名することでサイズを削減するためです。
そのため、ゾーンでDNSSECが有効になっていて、リゾルバーが検証している場合、署名されていないすべてのレコードを検証エラーとして扱い、SERVFAILを返す必要があります。
詳細については、 RFC4035 の「4.3。データのセキュリティステータスの判別」を参照してください。セクション5のこの最後の段落に注意してください。
リゾルバは、署名されたゾーンからの認証情報を期待する必要があります。リゾルバーは、リゾルバーがゾーンの公開鍵情報で構成されている場合、またはゾーンの親が署名されていて、親からの委任にDS RRsetが含まれている場合、ゾーンが署名されていると信じるべきです。
要約すると、ゾーン内のキーの存在と、ルートからゾーン内のこのキーまでのすべての信頼チェーンに対する検証では、ゾーン内のすべてのレコードにRRSIGレコードが付随しているという結果になります。彼らの信憑性を検証します。
その場合、RRSIGレコードなしで応答を取得すると、進行中の攻撃を示す可能性があるため、これは検証エラーとして扱う必要があるため、SERVFAILとなります。
さて、あなたが引用したように、さまざまなリゾルバーがchooseしてデフォルトの標準動作を上書きし、無効または欠落しているDNSSECレコードを通過させます。これは、各解決者次第のローカルポリシー決定ですが、明らかに標準の範囲外です。
リンクしたとおり、Googleは「非常に人気のあるドメイン」などの場合にそれを行います。ドメイン名が適切に構成されていない場合に責任を負うため、多くのISP（Comcastなど）は時々それを行います（この例を参照： https://www.darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked/d/d-id/113699 そして、関連する問題の精選されたリストを-で見つけることができます https://ianix.com/pub/dnssec-outages.html ）。そして今、この問題に特化したRFCもあります： RFC7646：DNSSECネガティブトラストアンカーの定義と使用
このドキュメントでは、指定されたドメインでDNSSEC検証を無効にすることでDNSSEC検証エラーを軽減するために使用できるネガティブトラストアンカー（NTA）を定義します。
そして：
トップレベルドメイン（TLD）または人気のあるドメイン名（トップ100のWebサイトなど）の設定ミスによる検証エラーの場合、影響を受けるTLDまたはドメインのコンテンツまたはサービスに多数のユーザーがアクセスできなくなる可能性があります。このような場合、設定ミスが確認されたらすぐにNTAを使用するのが適切な場合があります。 「上位N」のWebサイトのリストの例は、Alexaの「Web上の上位500サイト」[Alexa]、またはリゾルバーのキャッシュで最もアクセスされている名前のリストです。
このドラフトにも興味があるかもしれません： https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-05 これは、リゾルバーが取る必要があることを検証する難しさを扱います構成の誤りと悪意のある環境の両方が原因です。