DNSSECはどのような問題を解決しますか？
私はこのサイトで DNSSECSECのタグが付けられた質問 を読みましたが、長年にわたってDNSSECの採用と、ドメインでDNSSECを有効にする組織についての統計を聞いていますが、実際に解決しようとしていることについては誰も言及していません。 。まあ、それは「DNS応答に署名する」ことですが、それは方法であり目標ではありません。
「IPなりすましはできなくなります」トピックが出てくると技術ニュースが書かれます。または「DNSSECはドメイン名の所有者がDNSレコードに署名することを許可します」 howtogeekの書き込み 。それでも、攻撃者としてDNS応答を偽装できる場合、私はおそらく接続の読み取り/書き込みアクセスが明らかな中間にあり、関係なく内容を変更できます。または、誰かがHTTPSを使用している場合、一致するCA署名付き証明書がないため、IPアドレスを偽装できるかどうかは問題ではありません。
ドメイン所有者がDNSレコードに署名できることも意味がありません。これは、（データの署名に使用される）公開鍵がどのようにしてDNSクライアントに残るのでしょうか。各DNS応答を膨らませるのは非常に非効率的であるように見えますが、公開鍵を署名付きデータと組み合わせると、署名と一緒に公開鍵を交換するのは簡単な操作です。
DNSSECによって妨害されると思われる攻撃はDNSキャッシュポイズニングですが、再帰リゾルバーにランダム化されたソースポートを使用させることで解決された問題ではありませんか？
さらに、私は ISPから聞いた （オランダの） 今日、彼らはそれを可能にしています。レコードに署名したのはドメイン所有者ではなかったのですか？さらに、SIDN（オランダのTLD .nlの所有者）がしばらく前に有効にしたことも読みました。 their homepage にカウンターがあり、DNSSEC対応ドメインの数をカウントしています。一部のレジストラ（TransIPなど）でも有効になりました。ドメイン所有者、レジストラ、TLDなどの署名者は誰ですか？
最後に、すべてが署名されているわけではありません。一部のドメインではDNSSECが有効になっているようですが、有効になっていないドメインもあります（両方が同じトップレベルドメインからのものであっても）。クライアントは、署名されることになっていたかどうかをどうやって知るのでしょうか？レスポンスをスプーフィングするときにシグネチャを取り除くだけの簡単な攻撃のようです。
誰かが説明できますか：
- dNSSECの目的は何ですか？
- それが機能するために誰がそれを有効にしなければなりませんか？
- ドメインに署名するのは誰ですか？
- クライアントはどのようにして削除される署名を検出できますか？
完全性保証を解決します。署名されたゾーンをMITMすることはできなくなります。現在、誰でもDNSレコードを改ざんできる可能性がありますが、DNSSECでは不可能です。クライアントはすでにルートゾーンの公開鍵を知っており、ゾーンまでのチェーン全体を確認できます。
ドメインを登録するときは、ネームサーバーが存在するTLDゾーンを指定する必要があります。その時点で、公開鍵を添付することもできます。 TLDゾーンはあなたのエントリに署名し、それ以降、誰もがTLDゾーンをチェックすることでゾーンの整合性を検証できます。次に、自分のゾーンがそのレコードに署名できます。あなたの公開鍵は既知であり確認済みなので、ゾーンに署名できるのはあなただけです。 TLDゾーンはルートゾーンから同じ方法で署名され、その公開キーはDNSクライアントによって認識されます。このように、誰かがDNS応答を偽装しようとする場合、格納されているルートキーを置き換えるか、DNSSECを完全に無効にするために、まずDNSクライアントを変更する必要があります。
1。 DNSSECの目的は何ですか？
DNSSECはDNSレコードに署名します。暗号化は行わず、認証を確認するだけです。
ルートはTLD（.orgや.deなど）からの鍵に署名し、TLDはレジストラからの鍵に署名し、レジストラはWebインターフェースを介して（おそらく）入力したDNSレコードに署名します。[2]
署名されたゾーンを自分で維持できるように、キーに署名させることもできます。[3]
DNSSECはドメインに追加されたフィールドで存在するため、コンピューターで有効にした後、すべてのWebサイトで機能するわけではありません。レジストラーがサポートしていない場合、またはTLDがサポートしていない場合、コンピューターは、照会しているドメインのレコードの信頼性を検証できません。
2。それが機能するために誰がそれを有効にする必要がありますか？
ルート、選択したTLD、およびレジストラについてはすでに説明しました。これで、ISPまたは他の再帰リゾルバ（OpenDNSなど）でも、有効または無効にできます。これを有効にすると、リゾルバが署名をチェックし、検証が失敗した場合にエラーコードを返します。[4]
ユーザーのクライアントも、それが機能するために何かを有効にする必要があります。クライアント（Firefoxなど）が無効なシグニチャーでアラートを出さない場合、シグニチャーは決して値を追加しません。[5]
3。誰がドメインに署名しますか？
レジストラは、レコードに署名するか、レコードに署名するときに使用するキーに署名します。したがって、レジストラを信頼します。レジストラを信頼しない場合は、別のレジストラを取得する必要があります。そして、TLDを信頼します。彼らは、彼らが好きな任意の鍵でそれに署名できるからです（彼らはレジストラの鍵に署名できるからです）。そして、同じ理由でルートを信頼します。
4。クライアントは署名が削除されたことをどのように検出できますか？
誰かが署名を削除した場合、おそらく署名検証エラーをトリガーせずにレコードを変更するために、ドメインでDNSSECが有効になっていないように見えることがあります。ただし、親の署名者（TLD）は、ドメインでDNSSECが有効になっているはずであり、TLDの応答は署名されているため偽造できないことを述べています。[6]
では、TLDの署名も削除するとどうなるでしょうか。了解しました。ルートから（署名付きで）TLDを有効にすべきであることがわかります。
ルートが信頼でき、ルートが正当なTLDにのみ署名し、TLDが信頼でき、TLDがレジストラにのみ署名し、レジストラが信頼できる場合、署名されたレコードがドメイン所有者から直接送信されたことを確認できます。
5。おまけ：DNSSEC自体に問題はありますか？
これにより、応答が大きくなり（セキュリティではなくパフォーマンスの問題）、ドメインの列挙に役立ちます。
ドメインの列挙は、NXDOMAIN署名の解決方法により可能になりました。ネームサーバーがその場で署名する必要がないように、署名はオフラインで行われることを意図しています。しかし、存在しない何かに対して事前にどのように応答に署名するのですか？ 「ftp.example.com。とmail.example.com。の間に他のレコードはありません」という応答に署名し、jkl.example.comのようなものを要求したときにそれを返します。[1]
列挙するには、aaaa.example.comから始めます。 ftp.example.comのような最初のレコードが表示されます。次に、ftq.example.com（1文字増加）をリクエストすると、次のレコードが表示されます。
これは、名前をハッシュし、「ハッシュa8fba8 [...]とda8a8bfdf [...]の間に他のレコードがない」と解決することで解決されました。これはNSEC3と呼ばれます。[8] これにより、ハッシュの列挙が可能になり、オフラインでハッシュをクラックできるようになります。これは、ネームサーバーをクエリして推測するよりも桁違いに速く、ステルス的です。[9]
名前を列挙できるかどうかは、現在進行中の議論です。 DNSSECを設計する人々は通常、DNSシステムは公衆電話帳であるはずだと言っています。 DNSサーバーを展開する人々は、通常、電話帳を非公開にすることを好みます。[7]
[2] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Operation
[3]「DSレコードを作成して、レジストラに署名キーのフィンガープリントを伝える」 https://security.stackexchange.com/a/11571/1086
[4]「これらのDNSリゾルバー（ファンシードメイン名をIPアドレスに変換するために使用）を有効にしてDNSSECを検証します。今後、ISPにドメインのIPを要求し、署名が無効な場合、間違ったIPではなくエラーが表示されます。」 security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267595_142626
[5]「WebブラウザーのTLSのように、署名されていない応答を優先する（または警告する）のはクライアントの責任です。」 security.stackexchange.com/questions/142604/what-problem-does-dnssec-solve?noredirect=1#comment267602_142604
[6] https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Recursive_name_servers 「DS「example.com」のレコードがあるが、ない場合返信のRRSIGレコード、何かが間違っており、多分中間攻撃の男が続いている」
[7] https://security.stackexchange.com/a/11571/1086 "DNS（およびDNSSec）は主に最初のキャンプの人々によって設計されました; [...]サーバーは第二陣営の人々が運営する」
[8] https://security.stackexchange.com/a/126518/1086
[9] https://dnscurve.org/nsec3walker.html 「今後の作業」を参照