在阅读了Windows Server 2008 R2中的DNSSEC实现之后，我认为在没有完全安全的情况下，它会增加额外的复杂性（我明白，在大多数情况下，更多的安全性总是意味着更复杂）。
第一个DNS客户端不知道DNSSEC，并要求parsing该logging的服务器检查此logging的有效性，并仅在NRPT表存在的情况下执行（您需要另外configuration – 没有表没有检查;并且这仍然是WS 2012 / Win 8中的情况）。 除了以某种笨拙的体系结构的方式来看，问题是客户端没有任何选项来validationDNS服务器（在这方面100％安全，您需要在Windowsnetworking中部署IPSec，这增加了更多的复杂性）。
那么考虑到这一切，在现实世界中部署DNSSEC值得吗？ 它真的提高了安全性还是增加了不必要的复杂性？
有没有人真的在企业Windowsnetworking中使用这种技术？
一种看待它的方式是不pipe它是否“值得”。 在某些必须遵守某些审计政策（例如FISMA和FedRAMP）的环境中，这是强制性的。 （请阅读NIST特刊800-53 SC-20和SC-21。）
如果你不符合这些要求，那么只有你可以决定是否值得。 DNSSEC和IPsec确实引入了复杂性。 确实，将DNSSEC与内部/私有区域结合使用，而不将其与IPsec结合起来也是有限的。 当根据内部/专用DNS区域进行讲话时，如果客户端可以相信他或她正在与真正的，正确的DNS服务器交谈，那么DNSSEC才是真正有用的。 并validation身份validation通常也需要IPsec。
另外，请考虑在Windows Server上的任何小于Server 2012的情况下不使用DNSSEC。Server 2008 R2上的DNSSEC只能使用SHA-1，而不能使用SHA-2。 而且因为互联网根区（即. ）是用RSA / SHA-256签名的，这意味着Server 2008 R2作为互联网区域的validation器是没用的。 Server 2012及更高版本解决了这个问题。
无论您或您的公司处理这些复杂性是否太多，或者这些额外的好处是否值得，这都太主观了，我们无法为您解答。