我很好奇今天发布DURZ的L根服务器的实际效果是什么。 在nanog邮件列表中， 有人表示评估发布签名区域的根名称服务器的系统性影响是非常重要的，即使不使用DNSSEC也是如此。 同时，RIPE自己发布的关于对K根服务器进行更改的信息表示， 如果您的parsing器不使用DNSSEC，则不存在任何问题 。 有人可以清除这个吗？ DNSSEC似乎是一个混乱，纠结的networking。
如果在我的parsing器上没有启用DNSSEC，我有什么担心即将到来的根服务器更改吗？
您可能会看到一些内容，但在某种程度上取决于您运行的是哪个DNS软件。
特别是，即使没有特别要求DNSSEClogging或执行DNSSECvalidation，BIND也会在上游查询中设置“DNSSEC OK”（又名DO ）位。
在这种情况下，根服务器可能会发回额外的DNSSEClogging，这可能会导致问题，即使您的networking设备损坏或pathconfiguration不正确， 也可能导致问题。
这些问题主要与数据包大小有关。 有些套件不喜欢超过512字节长度的DNS UDP数据包，无论是通过错误的固件还是来自供应商错误的推荐configuration。 有关更多详细信息，请参阅我的RFC 5625 。 请注意，虽然我在RFC中报告的与DNSSEC有关的大多数问题都与消费者级别的设备有关，并且只能用于不同寻常的configuration。
请注意，如果您的工具包在UDP数据包较大时出现问题，那么回退就是使用TCP。 然而，一些（被误导的）安全人员configuration他们的防火墙来禁用TCP上的出站DNS，这就打破了回退。 有关DNS over TCP的更多信息，请参阅此 IETF草案。
顺便说一下，为了testing您的networkingconfiguration可能的DNS怪癖，我强烈推荐加州大学伯克利分校ICSI的Netalyzr网站。
但是，要清楚的是，大多数DNS专家并不期望因为引入DNSSEC而引起重大问题。 几个顶级域名（包括.org和.se）已经签署，因此互联网并没有崩溃。
DURZ是一个蓄意的尝试，逐渐地逐步在DNSSEC不可避免地产生的更大的反应，以便那些有networking问题的稀有站点可能在夏季整个根域到DNSSEC之前解决它们。
对于那些更喜欢命令式编程语言的人来说，在伪代码中可能出现什么错误的解释:-)
- 伪代码（或多或less的Ada语法）来显示发生了什么
- 根签名和响应成为时的DNSparsing器
- 更大。
- 背景信息：
- https://www.dns-oarc.net/oarc/services/replysizetest
- RFC 5625
- SSAC报告＃35 http://www.icann.org/committees/security/sac035.pdf
- Stephane Bortzmeyer
- 使用的variables：
- EDNS0：布尔值，指示parsing器是否发送EDNS0请求
- EDNS0_Size：正整数，由EDNS0公布的缓冲区大小
- DO_DNSSEC：boolean，表示parsing器支持DNSSEC的DO标志
- Min_Response_Size：整数，最小值（放下后
- 不必要的RR）大小的权威发送的DNS响应
- 服务器
- Clean_path_for_fragments：布尔值，表示UDP片段
- 可以从权威名称服务器到parsing器
- Clean_Path_For_EDNS0：布尔值，表示EDNS0响应
- （可能大于512字节）可以从中传输
- 权威的名称服务器到parsing器
- Can_TCP：boolean，表示parsing器可以通过TCP请求
- （这意味着一个干净的TCP补丁和一个权威的名称服务器
- 接受TCP）
- 对于一个请求，代码可以执行多次
- 实例，因为parsing器首先尝试使用UDP，然后重试
- 与TCP。
如果UDP那么 - MOst公共传输协议为DNS
如果EDNS0那么
如果EDNS0_Size> MTU那么
- BIND默认值，EDNS0_size = 4096字节
如果是DO_DNSSEC的话
- BIND默认，即使没有configurationvalidation
如果Min_Response_Size> MTU那么 - 今天不是用root的情况
如果是Clean_Path_for_fragments那么
好;
其他
- 一段时间后，BIND将切换到no-EDNS0，重新开始
重试（“未收到响应可能是因为EDNS0”）;
万一;
然后elsif Min_Response_Size> 512
- 不会发生碎片
如果是Clean_Path_For_EDNS0的话
好; - 这是BIND的正常和典型情况
- parsing器今天，与签署的根
其他
重试（“未收到响应可能是因为EDNS0”）;
万一;
否则 - 今天不会发生，来自根的响应已经> 512
好;
万一;
其他
- 没有DNSSEC，反应会更短，但一些
- 来自根目录的响应已经> 512
如果Min_Response_Size> MTU那么
- 不太可能，没有DNSSEC
如果是Clean_Path_for_fragments那么
好;
其他
重试（“未收到响应可能是因为EDNS0”）;
万一;
然后elsif Min_Response_Size> 512
如果是Clean_Path_For_EDNS0的话
好;
其他
重试（“未收到响应可能是因为EDNS0”）;
万一;
其他 - 今天最常见的情况下，典型的无符号
- 答案是100-200字节
好;
万一;
万一;
elsif EDNS0_Size> = 512 then - 但是比MTU低
如果是DO_DNSSEC的话
如果Min_Response_Size> EDNS0_Size那么
- 假设TC位集的DNS数据包到达
- 安全，并不总是如此
重试（ “截断”）;
然后，elsif Min_Response_Size> = 512
如果是Clean_Path_for_EDNS0的话
好;
其他
重试（“未收到响应可能是因为EDNS0”）;
万一;
否则 - 今天不会经常发生，一些来自根的响应已经> 512
好; - 并不总是，一些中间件可能会阻止EDNS0
- 反应，即使大小512然后
如果是Clean_Path_For_EDNS0的话
好;
其他
重试（“未收到响应可能是因为EDNS0”）;
万一;
其他
好;
万一;
万一;
否则 - 大小为512的EDNS0
重试（ “截断”）;
其他
好;
万一;
万一;
其他 - TCP
如果Can_TCP那么
好; - 但权威名称服务器上的延迟更高，负载更高
其他
错误（“回退到TCP失败”）; - 完全失败
万一;
万一;
testing你的设置的另一个解决scheme是OARC回复大小testing ，这个解决scheme比Netalyzr简单得多。