DNSSECおよびIPSecDNSサーバーとDNSクライアントの構成
いくつかのドメインにDNSSECを導入しようとしています。準備をしているときに、このテーマについて読みました。 名前解決ポリシーテーブル について話しているMicrosoft Technetの記事に出くわしました。これにより、DNSサーバーと通信して整合性を提供するときにWindows DNSクライアントを IPSecを使用 に構成できます（オプションで） ）認証。
これは私が座っているところからはかなり良い考えのように思えますが、残念ながらNRPTはWindowsだけのものです。 Linux/OpenBSDの世界に同等のものはありますか？ DNSSECとIPSecの両方を組み合わせることは、セキュリティを重視するサーバー管理者にとって完璧なソリューションのように思われます。
このNRPT全体は、[〜＃〜] dnssec [〜＃〜]をDNSCurveとある程度一致させる方法のように聞こえますが、単一の標準とDNSCurve自体の場合と同じように、関係のないものをまとめて大きな管理と構成の混乱に陥れているだけです。
再帰サーバーと権限サーバーにDNSSECをデプロイすることは、まったく異なる2つのタスクです。
正確に何を達成しようとしていますか？ LinuxおよびBSDの世界では、DNSSEC検証/妥当性確認が行われていることを確認したいだけの場合、それを実行する最善の方法は、独自のローカル再帰を実行することです。またはキャッシングリゾルバ。それがどのように行われるかの詳細については、次のFreeBSD 10に加えられた最近の変更を見てください。ここでは、ベースツリーにunboundが導入されています。これは、正しく使用されると（たとえば、次のように設定されている場合）利用可能な唯一のリゾルバー）は、DNSSECが有効になっているが、正しく署名されていないが署名されているはずのレコードがあるドメイン名を解決することは想定されていません。
authoritativeサーバーに関する限り、追加のセキュリティとプライバシーが必要な場合は、DNSCurveをフロントエンドとして実行し、必要に応じてバックエンドにDNSSECを含めることをお勧めします。
recursive DNSの場合、まったく同じことをしていると思いますが、逆です。ローカルのunboundをキャッシング/検証リゾルバーとして構成すると、問題が発生します。ローカルDNSCurve対応の再帰リゾルバーを介したすべてのクエリ。それ以外の場合はありません。
ただし、上記の両方の例で、あなたは未知の領域にかなり足を踏み入れていると思います。