私はいくつかのドメインにDNSSECを導入しようとしており、その準備をする中でこのテーマについていくつか読んでみました。Microsoft Technetの記事で次のようなことが書かれていました。名前解決ポリシーテーブルこれにより、Windows DNSクライアントを次のように構成できます。IPSecを使用するDNS サーバーと通信して整合性と (オプションで) 認証を提供するとき。
これは私の立場からするとかなり良いアイデアのように思えますが、残念ながら NRPT は Windows のみのものです。Linux / OpenBSD の世界には同等のものはありますか? DNSSEC と IPSec の両方を組み合わせることは、セキュリティを重視するサーバー管理者にとって完璧なソリューションのように思えます。
答え1
このNRPTの件は、ドメイン名ある程度一致するDNSカーブただし、DNSCurve 自体の場合のように単一の標準と仕様を持つのではなく、無関係なものをまとめて、管理と構成の大きな混乱を招いているだけです。
再帰サーバーと権威サーバーに DNSSEC を導入することは、まったく異なるタスクです。
具体的に何を達成しようとしているのですか? Linux および BSD の世界では、DNSSEC の検証/妥当性確認が確実に行われるようにしたいだけであれば、独自のローカル再帰リゾルバまたはキャッシュ リゾルバを実行するのが最善の方法です。その方法の詳細については、近日リリースされる FreeBSD 10 に最近加えられた変更を参照してください。この変更では、unboundベース ツリーが導入されました。ベース ツリーは、正しく使用された場合 (たとえば、使用可能な唯一のリゾルバとして設定されている場合)、DNSSEC が有効になっているが、正しく署名されていないレコード (署名されているはずのレコード) を持つドメイン名は解決されないようになっています。
の限り権威あるサーバー側でセキュリティとプライバシーを強化したい場合は、DNSCurve をフロントエンドとして実行し、必要に応じてバックエンドで DNSSEC を使用するのが最善策です。
たぶん再帰的DNS では、まったく同じことを逆の方法で実行します。つまり、ローカルをunboundキャッシュ/検証リゾルバとして構成し、すべてのクエリをローカルの DNSCurve 対応の再帰リゾルバを介して発行しますが、それ以外の方法では発行しません。
しかし、上記の両方の例では、未知の領域に足を踏み入れていることになると思います。