Mik*_*ail 4 dnssec windows-server-2008-r2
在阅读了 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。)
如果您不符合这些类型的要求,那么只有您可以决定它对您是否值得。DNSSEC 和 IPsec 确实引入了复杂性。确实,将 DNSSEC 用于内部/私有区域而不将其与 IPsec 耦合的价值有限。当谈到内部/私有 DNS 区域时,只有当客户端可以相信他或她正在与真实、正确的 DNS 服务器交谈时,DNSSEC 才真正有用。并且验证该身份验证通常还需要 IPsec。
此外,请考虑不要在低于 Server 2012 的 Windows Server 上使用 DNSSEC。Server 2008 R2 上的 DNSSEC 只能使用 SHA-1,不能使用 SHA-2。由于 Internet 根区域(即.
)是使用 RSA/SHA-256 签名的,这意味着 Server 2008 R2 作为 Internet 区域的验证器将毫无用处。Server 2012 及以上版本解决了这个问题。
对于您或您的公司而言,这种复杂性是否过于复杂,或者增加的好处是否值得……太主观了,我们无法为您解答。
归档时间: |
|
查看次数: |
1248 次 |
最近记录: |