bre*_*ent 6 domain-name-system dnssec
很好奇今天发布DURZ的L根服务器实际效果如何。在 nanog 邮件列表中，有人说评估根名称服务器发布签名区域的系统影响很重要，即使不使用 DNSSEC。同时，RIPE 自己发布的关于他们对 K 根服务器的更改的信息说，如果您的解析器不使用 DNSSEC 就没有问题。有人可以解决这个问题吗？DNSSEC 似乎是一个凌乱、纠结的网络。
如果没有在我的解析器上启用 DNSSEC，我是否需要担心即将对根服务器进行的更改？
Aln*_*tak 10
您可能会看到一些东西，但在某种程度上这取决于您正在运行的 DNS 软件。
特别是，DO即使没有特别要求 DNSSEC 记录或执行 DNSSEC 验证，BIND也会在上游查询上设置“DNSSEC OK”（又名）位。
在这些情况下，根服务器可能会发回额外的 DNSSEC 记录，这可能会导致在不太可能发生的情况下出现问题，即您的网络设备损坏和/或路径中的防火墙配置错误。
这些问题主要与数据包大小有关。一些套件不喜欢长度超过 512 字节的 DNS UDP 数据包，无论是通过有缺陷的固件还是来自供应商的错误推荐配置。有关更多详细信息，请参阅我的RFC 5625。请注意，我在该 RFC 中报告的大多数与 DNSSEC 相关的问题都与消费者类设备有关，并且仅在不寻常的配置中。
请注意，如果您的工具包在处理大型 UDP 数据包时确实存在问题，则后备方案是使用 TCP。然而，一些（被误导的）安全人员将他们的防火墙配置为禁用 TCP 上的出站 DNS，这会破坏回退。有关 DNS over TCP 的更多信息，请参阅此IETF 草案。
顺便说一句，为了测试您的网络配置是否可能出现 DNS 怪癖，我强烈推荐来自加州大学伯克利分校 ICSI的优秀 Netalyzr网站。
但是，需要明确的是，由于引入了 DNSSEC ，大多数 DNS 专家都没有预料到会出现重大问题。几个顶级域名（包括 .org 和 .se）已经被签署，互联网并没有因此崩溃。
DURZ 是故意尝试逐步分阶段处理 DNSSEC 不可避免地产生的较大响应，以便那些有网络问题的罕见站点可以在整个根区在夏季转移到 DNSSEC 之前解决这些问题。