我很好奇 L 根服务器的实际效果今天发布 DURZ将会。在 nanog 邮件列表中，有人说评估根名称服务器发布签名区域的系统性影响非常重要，即使不使用 DNSSEC 也是如此。与此同时，RIPE 自己发布的有关他们对 K 根服务器的更改的信息表明如果你的解析器不使用 DNSSEC，那就没问题了有人能帮我理清一下吗？DNSSEC 看起来乱糟糟的，乱糟糟的。
如果我未在解析器上启用 DNSSEC，我是否需要担心根服务器即将发生的更改？
答案1
你可能看到一些东西，但在某种程度上，这取决于您正在运行哪种 DNS 软件。
DO具体来说，即使没有明确要求 DNSSEC 记录或执行 DNSSEC 验证，BIND 也会在上游查询中设置“DNSSEC OK”（又名）位。
在这种情况下，根服务器可能会发回额外的 DNSSEC 记录，可能万一您的网络设备损坏和/或路径中的防火墙配置错误，则会导致问题。
这些问题主要与数据包大小有关。有些套件不喜欢长度超过 512 字节的 DNS UDP 数据包，要么是由于固件存在缺陷，要么是由于供应商推荐的配置有误。请参阅我的RFC 5625了解更多详情。但请注意，我在该 RFC 中报告的大多数 DNSSEC 相关问题都与消费者级设备有关，并且只在特殊配置中出现。
请注意，如果您的套件在处理大型 UDP 数据包时确实存在问题，那么后备方案是使用 TCP。然而，一些（被误导的）安全人员配置了防火墙以禁用通过 TCP 的出站 DNS，这会破坏后备方案。请参阅这有关 TCP 上的 DNS 的更多信息，请参阅 IETF 草案。
顺便说一句，为了测试你的网络配置是否存在可能的 DNS 问题，我强烈建议使用出色的 Netalyzr加州大学伯克利分校 ICSI 网站。
但需要明确的是，大多数 DNS 专家不是由于引入 DNSSEC，预计会出现重大问题。几个 TLD（包括 .org 和 .se）已经签名，互联网并未因此崩溃。
DURZ 是一种刻意尝试，旨在逐步引入 DNSSEC 必然会产生的更大响应，以便那些存在网络问题的罕见站点能够在夏季整个根区域转移到 DNSSEC 之前解决这些问题。
答案2
对于那些喜欢命令式编程语言的人来说，用伪代码来解释可能出现的问题:-)
-- 伪代码（语法或多或少类似于 Ada）来展示发生了什么
-- 当根被签名并且响应变为
—— 更大。
-- 背景信息：
-- 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：布尔值，DO 标志表示解析器是否支持 DNSSEC
-- Min_Response_Size：整数，最小值（删除后）
-- 权威服务器发送的 DNS 响应的不必要的 RR）大小
- 服务器
-- clean_path_for_fragments: boolean，表示UDP碎片
——可以从权威名称服务器传输到解析器
-- Clean_Path_For_EDNS0：布尔值，表示 EDNS0 响应
-- （可能大于 512 字节）可以从
-- 解析器的权威名称服务器
-- Can_TCP：布尔值，表示解析器可以通过 TCP 进行请求
——（这意味着一个干净的 TCP 补丁和一个权威的名称服务器
-- 接受 TCP)
-- 该代码可以针对一个请求执行多次，例如
-- 例如，因为解析器首先尝试使用 UDP，然后重试
—— 使用 TCP。
如果是 UDP 则 -- DNS 最常见的传输协议
如果 EDNS0 那么
如果 EDNS0_Size > MTU 则
-- BIND 默认值，EDNS0_size = 4096 字节
如果 DO_DNSSEC 那么
-- BIND 默认值，即使没有配置验证
如果 Min_Response_Size > MTU，则 -- 今天根的情况并非如此
如果 Clean_Path_for_fragments 那么
好的;
别的
-- 过一会儿 BIND 将切换到 no-EDNS0，重新开始
重试（“未收到响应可能是由于 EDNS0”）；
万一;
elsif Min_Response_Size > 512 那么
-- 不会发生碎片
如果 Clean_Path_For_EDNS0 那么
好的；——这是 BIND 的正常和典型情况
-- 今天的解析器，具有签名的根
别的
重试（“未收到响应可能是由于 EDNS0”）；
万一;
else —— 今天不会发生，来自根的响应已经 > 512
好的;
万一;
别的
-- 如果没有 DNSSEC，响应将会更短，但有些
-- 来自根的响应已经 > 512
如果 Min_Response_Size > MTU 那么
-- 不太可能，没有 DNSSEC
如果 Clean_Path_for_fragments 那么
好的;
别的
重试（“未收到响应可能是由于 EDNS0”）；
万一;
elsif Min_Response_Size > 512 那么
如果 Clean_Path_For_EDNS0 那么
好的;
别的
重试（“未收到响应可能是由于 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 那么
好的;
别的
重试（“未收到响应可能是由于 EDNS0”）；
万一;
else —— 今天不会经常发生，来自根的一些响应已经 > 512
好的；——并非总是如此，一些中间件可能会阻止 EDNS0
-- 响应，即使大小为 512
如果 Clean_Path_For_EDNS0 那么
好的;
别的
重试（“未收到响应可能是由于 EDNS0”）；
万一;
别的
好的;
万一;
万一;
else -- EDNS0 大小为 512
重试（“截断”）；
别的
好的;
万一;
万一;
否则——TCP
如果 Can_TCP 那么
好的；——但权威名称服务器的延迟和负载更高
别的
错误（“回退到 TCP 失败”）；——彻底失败
万一;
万一;
答案3
测试设置的另一种解决方案（我发现它比 Netalyzr 简单得多）是OARC 回复大小测试。