我很好奇L根服务器
publishing DURZ today的实际效果是什么.在nanog邮件列表
someone said中,评估发布签名区域的根名称服务器的系统效果非常重要,即使不使用DNSSEC也是如此.同时,RIPE自己发布的关于他们对K根服务器的更改的信息说有
no issue if your resolvers don’t use DNSSEC.有人可以清楚这个吗？ DNSSEC似乎是一个混乱,纠结的网络.
如果没有在我的解析器上启用DNSSEC,我对即将对根服务器进行的更改有什么担心吗？
解决方法
您可能会看到某些内容,但在某种程度上取决于您正在运行的DNS软件.
特别是,即使没有特别要求DNSSEC记录或执行DNSSEC验证,BIND也会在上游查询中设置“DNSSEC OK”(又称DO)位.
在这些情况下,根服务器可能会发回其他DNSSEC记录,这些记录可能会在路径中出现网络设备损坏和/或配置错误的防火墙的情况下出现问题.
这些问题主要与数据包大小有关.某些工具包不喜欢长度超过512字节的DNS UDP数据包,无论是通过有缺陷的固件还是来自供应商的错误推荐配置.有关详细信息,请参阅我的RFC 5625.请注意,我在该RFC中报告的大多数与DNSSEC相关的问题与消费类齿轮有关,并且仅在异常配置中有关.
请注意,如果您的工具包确实存在大型UDP数据包问题,那么回退就是使用TCP.然而,一些(误入歧途的)安全人员将其防火墙配置为禁用TCP上的出站DNS,从而打破了后备.有关DNS over TCP的更多信息,请参见this IETF草案.
顺便说一下,为了测试你的网络配置是否存在可能的DNS怪癖,我强烈推荐加州大学伯克利分校ICSI的优秀Netalyzr网站.
然而,需要明确的是,由于引入了DNSSEC,大多数DNS专家并不期待重大问题.几个顶级域名(包括.org和.se)已经签署,因特网没有崩溃.
DURZ是故意尝试逐步进入DNSSEC不可避免地产生的更大响应,以便那些有网络问题的稀有站点可以在整个根区域在夏天转移到DNSSEC之前解决它们.
