DNSSecはどのように機能しますか？既知の制限または問題はありますか？
このサイトからの情報 に基づいて、DNSSecは、以下を含む多くのDNSおよびSSL/TLSハックから私たちを保護するために必要です。
- DNSスプーフィング 、特にwifiまたは共有メディア
- 信頼を悪用し、 無効なデータをルートサーバーに挿入するレジストラ
- SSLおよびHTTPS接続への攻撃を可能にする基本的な欠陥
RFC以外でDNSSecがどのように機能するかについては、まだよく説明していません。
- DNSSecはどのように機能しますか？
- 知っておくべき既知の制限はありますか？具体的には、MITMが「安全な」レコードをクライアントに表示されないようにし、クライアントが安全でないDNSを使用するケースをどのように防ぐことができますか？ （ this hack の変形）
DNSSecは通常のDNSですが、署名が付いています。 DNSスプーフィングを完全に防ぎます。それが目的であり、それが目的です。
レジストラはあなたの意図をルートサーバーに伝える責任があるため、理論的には自分の立場を悪用する可能性があります。これには、DNSSecキーに関する情報が含まれます。この関係が変わることはありません。レジストラを信頼できない場合は、新しいレジストラを取得してください。
DNSSecはMITM攻撃を防止しません。 DNSスプーフィングを完全に防ぎます。ただし、DNSスプーフィングだけでなく、トラフィックフローに自分を挿入する方法は他にもあります。
使い方
本質的には、DSレコードを作成することにより、レジストラに署名鍵のフィンガープリントを通知します。その情報は、同様の方法でグローバルに信頼された単一の鍵につながる上流鍵によって署名されたTLDから利用できます。
これで、キーはドメインの信頼できる機関と見なされ、DNSレコードへの署名が許可されます。したがって、ゾーン内の各レコードについて、関連するデジタル署名を含む対応するRRSIGレコードを作成します。
これで、誰かがゾーン内のドメインを検索するときに、応答を送信できるだけでなく、対応するRRSIGレコードも送信して、応答が自分によって署名されたことを示すことができます。署名を検証するために、クライアントは完全な公開鍵を含むDNSKEYレコードをフェッチし、通常の暗号化署名検証手法に従います。
明らかに、DNSKEYレコードには独自の対応するRRSIGレコードもあり、改ざんされていないことを確認できます。ただし、より重要なことは、DSレコードが実際にゾーンに対して承認されていることを確認するための公開鍵に関する十分な情報を含むDNSKEYレコードが親ゾーンから利用可能である（最初の段落でレジストラに提供したことを思い出してください）ことです。
そのDSレコードは、次に、親のDNSKEYによって歌われます。これには、対応するDSレコードがルートゾーンにあります。このように、すべてのキー署名は単一の信頼できるソースにさかのぼることができます。
問題
レコードが存在することを誰かに伝える必要がある場合に、問題が発生しますしないが存在します。当然、その応答には署名が必要ですが、通常、DNSサーバー自体は署名キーにアクセスできず、応答をオンザフライで署名できません。署名はすべて事前に「オフライン」で作成されます。これにより、DNSサーバーが危険にさらされた場合にキーが公開されるのを防ぎます。
したがって、代わりに、サブドメインをアルファベット順に並べて、「mail.example.comとpop.example.comの間のすべての名前について、他のサブドメインは存在しません」と言って、そのアサーションに署名します。次に、誰かがnachos.example.comを要求すると、その応答（すでに署名されている）を与えるだけでよく、クライアントは、nachos.example.comがアルファベット順でmail.example.comとpop.example.comの間にあるため、「このドメインは存在しません」という応答は正しくないと見なされます。署名し、実際にあなたから来ました。
これが問題となるのは、「XとYの間に応答が存在しないことを明示的に示すこれらの否定応答のセットを用意することで、ゾーン全体に存在するドメインを正確に簡単にマッピングできます。 "X"が存在することがわかります。 、「Y」が存在し、それらの間に他に何もないことを知っている。ランダムに少し突っ込むだけで、すべてのレコードのリストをすばやくコンパイルできますdo存在します。
論争
これが問題であるかどうかに関して、DNSの世界には2つの陣営があります。最初のグループは言う：
「では、人々がどのゾーンが存在するかを知っているとしたらどうでしょう。DNSは公開情報です。とにかく秘密であることが意図されていたわけではありません。」
2番目のグループが言うところ：
「これはセキュリティ上のリスクです。accounting.example.comという名前のサーバーを使用している場合、ネットワークに侵入した人は、どのマシンがジューシーな情報を持っているか、したがってどのマシンを攻撃するかをすばやく知ることができます。」
その後、最初のグループが返信します。
「それをそれと呼ばないでください！セキュリティモデル全体が公開情報を秘密に保つという概念に基づいている場合、あなたは、馬鹿です。」
2番目のグループが返信する先：
「秘密を守ることではなく、必要以上の情報を明らかにしないことです。」
等々、吐き気
DNS（およびDNSSec）は、主に最初のキャンプの人々によって設計されました。 DNSは公開されているため、ドメイン内に存在するサブドメインを特定できることは、重大なセキュリティ上の問題ではありません。とにかく、署名された否定的な応答を他の方法で実際に行うことはできません。
一方、サーバーは第2陣営の人々によって運営される傾向があります。彼らは自分のネットワークの安全性を懸念しており、すべての情報が最終的には自分たちに対して使用されることを知っているので、必要以上の情報を提供したくありません。
したがって、暗号化された方法で完全に機能するプロトコルがあり、実際の管理者は実装をためらう傾向があります。
私たちは皆、最終的にそこに着くと思います。結局のところ、DNSスプーフィングは、サブドメインをマッピングすることによって引き起こされる危険よりも、現実の問題です。しかし、変化には説得力があります。だからここにいる...まだ。
deploymentの問題に関しては、いくつかの「Gotchas」があります。
ゾーン再署名：
DNSSECは2つのキーを使用します。
- 鍵署名鍵（KSK）。通常、セキュリティを強化するために長い（2048ビット）鍵です。
- パフォーマンスを向上させるために短いゾーン署名キー（ZSK）。
ZSKは短いため、定期的に変更する必要があります。つまり、ゾーンに再署名します。
古いDNSSECチュートリアルのいくつかは、ゾーンに署名するように指示するだけで、定期的に再署名する必要があることを通知しません。これは通常、1週間後にゾーンに無効な署名が含まれることになります。
最新の権威ネームサーバーには、新しいZSKの生成とゾーンの再署名のサポートが組み込まれています。しかし、現在のディストリビューションに同梱されているものはそうではないかもしれません。
個人的には、ゾーンに再署名するために [〜＃〜] zkt [〜＃〜] を使用しています。小さなセットアップには問題ありません。
権限のあるネームサーバーと検証リゾルバーはIPアドレスを共有できません。
権威ネームサーバーはAAフラグ（「権威回答」）を設定しますが、検証リゾルバーはADフラグ（「AuthenticateD」）を設定します。これらのフラグは相互に排他的です。 「ハイブリッド」モードで実行されているネームサーバーがある場合、つまり、それらが再帰を実行し、権限のあるゾーンにサービスを提供する場合は、2つに分割する必要があります。さまざまな機能。
すべてのレジストラが公開をサポートしているわけではありませんDSルートへのレコード
ISCの [〜＃〜] dlv [〜＃〜] サービスを使用できるため、これはそれほど大きな問題ではありません。 EasyDNSに注意してください。独自のネームサーバーの署名ゾーンをサポートしていますが、DSレコードを使用して何も実行しないため、DNSSECサポートが少し役に立たなくなります。
あなたはおそらく "Against DNSSEC" by Thomas Ptacek とその [〜＃〜] faq [〜＃〜] を読むべきでしょう。