在阅读了
Windows Server 2008 R2中的DNSSEC实现之后,在我看来它无论如何都增加了额外的复杂性而不是完全安全(我确实理解在大多数情况下更多的安全性总是意味着更复杂).
第一个DNS客户端不知道DNSSEC并要求解析该记录的同一服务器检查该记录的有效性,并且只在NRPT表存在的情况下才执行(您需要另外配置 – 没有表没有检查;这仍然是WS 2012 / Win 8中的案例.除了看起来笨拙的架构方面,问题是客户端没有任何选项来验证DNS服务器(在这方面100％安全,你需要在Windows网络中部署IPSec,这增加了更多的复杂性).
因此,考虑到所有这些,在现实世界中部署DNSSEC是否值得？它真的能提高安全性还是增加不必要的复杂性？
有人真的在企业Windows网络中使用这项技术吗？
一种看待它的方法是,它是否“值得”并不重要.在某些必须符合某些审核政策(如FISMA和FedRAMP)的环境中,它是强制性的. (阅读NIST特刊800-53 SC-20和SC-21.)
原文链接：/windows/367698.html如果您不满足这些要求,那么只有您可以决定是否值得.确实,DNSSEC和IPsec引入了复杂性.确实,将DNSSEC与内部/专用区域一起使用而不将其与IPsec耦合是有限的.当谈到内部/私有DNS区域时,DNSSEC仅在客户端可以信任他或她正在与真实,正确的DNS服务器通信时才真正有用.并验证身份验证通常还需要IPsec.
此外,请考虑不要在Windows Server上使用DNSSEC,而不要使用Server 2012.Server 2008 R2上的DNSSEC只能使用SHA-1,而不能使用SHA-2.由于互联网根区域(即.)使用RSA / SHA-256签名,这意味着Server 2008 R2将无法用作互联网区域的验证器. Server 2012及更高版本解决了此问题.
对于您或您的公司来说,这种复杂性是否过于复杂,或者额外的利益是否值得……太过主观,我们无法为您解答.
