我很好奇今天L根服务器发布DURZ的实际效果会是什么。在 nanog 邮件列表中，有人说评估根名称服务器发布签名区域的系统影响很重要，即使在不使用 DNSSEC 的情况下也是如此。同时，RIPE 自己发布的关于 K 根服务器更改的信息表明，如果您的解析器不使用 DNSSEC 就没有问题。有人可以澄清一下吗？DNSSEC 似乎是一个杂乱无章的网络。
如果没有在我的解析器上启用 DNSSEC，我是否需要担心即将对根服务器进行的更改？
AskOverflow.Dev
我很好奇今天L根服务器发布DURZ的实际效果会是什么。在 nanog 邮件列表中，有人说评估根名称服务器发布签名区域的系统影响很重要，即使在不使用 DNSSEC 的情况下也是如此。同时，RIPE 自己发布的关于 K 根服务器更改的信息表明，如果您的解析器不使用 DNSSEC 就没有问题。有人可以澄清一下吗？DNSSEC 似乎是一个杂乱无章的网络。
如果没有在我的解析器上启用 DNSSEC，我是否需要担心即将对根服务器进行的更改？
您可能会看到一些东西，但在某种程度上这取决于您正在运行的 DNS 软件。
特别是，BIND
DO在上游查询中设置“DNSSEC OK”（aka ）位，即使没有专门要求 DNSSEC 记录或执行 DNSSEC 验证。在这种情况下，根服务器可能会发回额外的 DNSSEC 记录，这可能会在您的网络设备损坏和/或路径中的防火墙配置错误的情况下导致问题。
这些问题主要与数据包大小有关。一些套件不喜欢长度超过 512 字节的 DNS UDP 数据包，无论是通过有缺陷的固件还是来自供应商的错误推荐配置。有关详细信息，请参阅我的RFC 5625 。请注意，尽管我在该 RFC 中报告的大多数与 DNSSEC 相关的问题都与消费类设备有关，并且仅在不寻常的配置中。
请注意，如果您的工具包确实存在大型 UDP 数据包问题，那么后备方案是使用 TCP。然而，一些（被误导的）安全人员将他们的防火墙配置为禁用 TCP 上的出站 DNS，这会破坏回退。有关基于 TCP 的 DNS 的更多信息，请参阅此IETF 草案。
顺便说一句，为了测试您的网络配置是否存在可能的 DNS 怪癖，我强烈推荐加州大学伯克利分校 ICSI的优秀 Netalyzr网站。
然而，需要明确的是，大多数 DNS 专家并没有预料到由于 DNSSEC 的引入会出现重大问题。几个顶级域名（包括 .org 和 .se）已经签署，互联网并没有因此而崩溃。
DURZ 是有意尝试逐步逐步引入 DNSSEC 不可避免地产生的更大响应，以便那些存在网络问题的罕见站点可以在夏季整个根区移交给 DNSSEC 之前解决它们。
对于那些喜欢命令式编程语言的人，用伪代码解释可能出错的地方:-)
-- 伪代码（语法或多或少类似于 Ada）来显示发生了什么 -- 当根签名并且响应变为时的 DNS 解析器 ——更大。 -- 背景资料： -- https://www.dns-oarc.net/oarc/services/replysizetest -- RFC 5625 -- SSAC 报告 #35 http://www.icann.org/committees/security/sac035.pdf ——斯蒂芬·博茨迈耶 -- 使用的变量： -- EDNS0：布尔值，表示解析器是否发送 EDNS0 请求 -- EDNS0_Size：正整数，EDNS0通告的缓冲区大小 -- DO_DNSSEC：布尔值，表示解析器支持 DNSSEC 的 DO 标志 -- Min_Response_Size：整数，最小值（丢弃后 -- 不必要的 RR) 权威机构发送的 DNS 响应的大小 - 服务器 -- clean_path_for_fragments：布尔值，表示UDP分片 -- 可以从权威名称服务器传送到解析器 -- Clean_Path_For_EDNS0：布尔值，表示 EDNS0 响应 -- （可能大于 512 字节）可以从 -- 解析器的权威名称服务器 -- Can_TCP: boolean, 表示解析器可以通过TCP请求 --（这意味着一个干净的 TCP 补丁和一个权威的名称服务器 -- 接受 TCP) -- 一个请求可以多次执行代码，对于 -- 实例，因为解析器首先尝试使用 UDP，然后重试 -- 使用 TCP。 if UDP then -- 最常见的 DNS 传输协议 如果 EDNS0 然后 如果 EDNS0_Size > MTU 然后 -- BIND 默认，EDNS0_size = 4096 字节 如果 DO_DNSSEC 则 -- BIND 默认，即使没有配置验证 如果 Min_Response_Size > MTU then -- 今天的情况与根不同 如果 Clean_Path_for_fragments 那么 好的; 别的 -- 一段时间后 BIND 会切换到 no-EDNS0，重新开始 Retry("未收到响应可能是因为 EDNS0"); 万一; elsif Min_Response_Size > 512 然后 -- 不会产生碎片 如果 Clean_Path_For_EDNS0 然后 好的; -- 这是 BIND 的正常和典型情况 -- 今天的解析器，带有签名的根 别的 Retry("未收到响应可能是因为 EDNS0"); 万一; else -- 今天不会发生，来自根的响应已经 > 512 好的; 万一; 别的 -- 如果没有 DNSSEC，响应会更短，但有些 -- 来自根的响应已经 > 512 如果 Min_Response_Size > MTU 然后 -- 不太可能，没有 DNSSEC 如果 Clean_Path_for_fragments 那么 好的; 别的 Retry("未收到响应可能是因为 EDNS0"); 万一; elsif Min_Response_Size > 512 然后 如果 Clean_Path_For_EDNS0 然后 好的; 别的 Retry("未收到响应可能是因为 EDNS0"); 万一; else -- 今天最常见的情况，典型的无符号 -- 答案是 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 然后 好的; 别的 Retry("未收到响应可能是因为 EDNS0"); 万一; else -- 今天不会经常发生，一些来自根的响应已经> 512 好的; -- 并非总是如此，一些中间盒可能会阻止 EDNS0 -- 响应，即使大小为 512 如果 Clean_Path_For_EDNS0 然后 好的; 别的 Retry("未收到响应可能是因为 EDNS0"); 万一; 别的 好的; 万一; 万一; else -- EDNS0 大小为 512 then 重试（“截断”）； 别的 好的; 万一; 万一; 否则——TCP 如果 Can_TCP 那么 好的; -- 但是权威域名服务器的延迟和负载更高 别的 Error("回退到 TCP 失败"); -- 彻底失败 万一; 万一;另一个测试您的设置的解决方案是OARC reply size test，我发现它比 Netalyzr 简单得多。