我即将为我的部分域名部署DNSSEC，而且在准备就绪时，我对这个主题进行了一些阅读。 我遇到了一些Microsoft Technet文章中讨论的名称parsing策略表 ，它允许在与DNS服务器通信时使用IPSec来configurationWindows DNS客户端以提供完整性和（可选）身份validation。
从我所坐的位置看，这似乎是一个非常好的主意，但唉，NRPT只是一个Windows。 在Linux / OpenBSD世界有没有相同的东西？ 将DNSSEC和IPSec组合在一起似乎是安全性明确的服务器pipe理员的完美解决scheme。
这整个NRPT的事情听起来像是一种方法，使DNSSEC有点符合DNSCurve ，除了有一个像DNSCurve本身一样的标准和规范，他们只是抛出一堆无关的一起成为一个大的pipe理和configuration混乱。
为recursion和授权服务器部署DNSSEC是两个完全不同的任务。
你究竟想要完成什么？ 在Linux和BSD领域，如果您只是想确保DNSSECvalidation/validation正在进行，那么最好的办法就是运行您自己的本地recursion或cachingparsing器。 有关如何完成的一些细节，请看看最近对即将到来的FreeBSD 10所作的改动，他们已经在基本树中引入了unbound ，如果使用正确（例如，如果它被设置为唯一可用的parsing器） ，不应该parsing任何启用了DNSSEC的域名，但是logging的签名不正确，但是应该签名。
就权威服务器而言，如果您想要一些额外的安全性和隐私，最好的办法就是将DNSCurve作为前端运行，并且如果需要，可能仍然在后端拥有DNSSEC。
我想对于recursion DNS，你会做同样的事情，但反过来：也许configuration一个本地的unbound是一个caching/validationparsing器，这将通过本地DNSCurve感知recursionparsing器发出所有的查询，但从来没有。
但是，在上面的两个例子中，我想你已经进入了一个未知的领域。