要求 DNS 服务器响应未知域请求的 RFC

Question

我的域注册商和 DNS 提供当前忽略对未知域的 DNS 请求。忽略我的意思是黑洞并且从不响应，这会导致我的 DNS 客户端和解析器库重试、退出并最终超时。

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

在调查其他流行的域名服务时，我发现这种行为非常独特，因为其他提供商返回的 RCODE 为 5 (REFUSED)：

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

全部返回如下内容：

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

或者

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

返回REFUSED或NXDOMAIN立即返回是合适的恕我直言，而不是仅仅在服务器机房地板上删除请求。

当我向我的提供商抱怨他们的服务器没有响应时，他们要求我引用他们的服务器违反的 RFC。我知道他们要求我证明他们的服务器应该响应所有请求，这很奇怪，但就这样吧。

问题：

• 我的规定是，除非有重复的请求 ID 或某种 DOS 响应，否则服务器应始终响应请求。这样对吗？
• 我应该引用哪些 RFC 和特定部分来支持我的规定？

对我来说，不响应 DNS 查询是不好的。大多数客户端将退出，然后将相同的查询重新传输到相同的 DNS 服务器或另一台服务器。它们不仅会减慢客户端的速度，还会导致它们自己或其他服务器根据权威名称服务器和 NS 条目再次执行相同的查询。

在RFC 1536和2308 中，我看到了很多关于出于性能原因和停止重传相同查询的负面缓存的信息。在4074 中，我看到有关返回 RCODE 为 0 的空答案的信息，因此客户端知道没有 ipv6 信息应该导致客户端询问 A RR，这是空响应的另一个示例。

但是我找不到一个 RFC，它说 DNS 服务器应该响应请求，可能是因为它是隐含的。

当我将我的域（以及相关的 DNS 记录）迁移到他们的服务器时，或者在我向他们的服务注册新域后的前 X 分钟时，就会发生特定问题。权威名称服务器更改的时间（现在非常快）与其服务器开始为我的 DNS 记录提供服务之间存在延迟。在这段延迟时间内，DNS 客户端认为他们的服务器是权威的，但他们从不响应请求——即使是REFUSED. 我理解延迟很好，但我不同意不响应 DNS 请求的决定。作为记录，我了解如何解决他们系统中的这些限制，但我仍在与他们合作以改进他们的服务，使其更符合 DNS 协议。

谢谢您的帮助。

---

编辑：

在发布此内容并跟进我的提供商的几个月内，他们更改了服务器以返回NXDOMAIN未知域。

Answer 1

谢恩的建议是正确的。在启动转换之前未能将数据从一个权威服务器迁移到另一个权威服务器是一个中断的邀请。不管从那时起发生了什么，这是由摆动 NS 记录的人发起的中断。这解释了为什么没有更多人向您的提供者投诉。

也就是说，这仍然是一个需要回答的有趣问题，所以我将全力以赴。

DNS 服务器的基本功能由文档RFC 1034和RFC 1035涵盖，它们共同构成STD 13。答案必须要么来自这两个 RFC，要么由更新它的后续 RFC 澄清。

在我们继续之前，这里有一个超出 DNS 范围的巨大陷阱需要指出：这两个 RFC 都早于BCP 14 (1997)，该文件澄清了 MAY、MUST、SHOULD 等的语言。

• 在这种语言正式化之前制定的标准可能使用了清晰的语言，但在一些情况下没有使用。这导致了软件的不同实现、大量混乱等。
• 不幸的是，STD 13 在几个方面具有解释性。如果某个操作领域的语言不明确，则经常需要找到一个明确的 RFC。

顺便说一下，让我们从RFC 1034 §4.3.1必须说的开始：

• 服务器的最简单模式是非递归的，因为它可以仅使用本地信息来回答查询：响应包含错误、答案或对“更接近”答案的其他服务器的引用。所有名称服务器都必须实现非递归查询。

...

如果递归服务未被请求或不可用，则非递归响应将是以下之一：

• 指示名称不存在的权威名称错误。

• 临时错误指示。

• 一些组合：

  回答问题的 RR，以及数据是来自区域还是缓存的指示。

  对名称服务器的引用，该名称服务器的区域比发送回复的服务器更接近名称的祖先。

• 名称服务器认为对请求者有用的 RR。

这里的语言相当坚定。没有“应该”，只有“将会”。这意味着最终结果必须是 1) 在上面的列表中定义，或 2) 被标准轨道上的后续文件所允许，该文件修改了功能。我不知道存在任何此类无视请求的言论，我想说开发人员有责任找到反驳研究的语言。

鉴于 DNS 在网络滥用场景中的频繁作用，不要说 DNS 服务器软件不提供选择性地将流量丢弃在地板上的旋钮，这在技术上是违反这一点的。也就是说，这些要么不是默认行为，要么是非常保守的默认值；两者的例子是用户要求软件删除特定名称 ( rpz-drop.)，或者超出了某些数字阈值 (BIND's max-clients-per-query)。根据我的经验，软件以违反标准的方式完全改变所有数据包的默认行为几乎是闻所未闻的，除非该选项增加了对违反标准的旧产品的容忍度。这里情况不同。

简而言之，根据运营商的判断，这个 RFC 可以而且确实会被违反，但通常这是以某种方式精确完成的。为了方便而完全无视标准的某些部分是非常罕见的，尤其是当专业共识（例如：BCP 16 §3.3）错误地倾向于不希望在整个 DNS 系统上产生不必要的负载时。考虑到这一点，从删除所有不存在权威数据的请求中进行不必要的重试是不可取的。

更新：

关于理所当然地将查询放在地板上是不可取的，@Alnitak 与我们分享了目前有一个BCP 草案详细介绍了这个主题。将其用作引用还为时过早，但它确实有助于加强社区共识与此处表达的内容一致。特别是：

除非名称服务器受到攻击，否则它应该响应由于以下委托而指向它的所有查询。此外，即使服务器未配置为为区域提供服务，代码也不应假定没有对服务器的委派。断开的委托在 DNS 中很常见，接收到对服务器未配置的区域的查询并不一定表明服务器受到攻击。父区域操作员应该定期检查委派 NS 记录与委派区域的记录是否一致，并在不一致时进行更正 [RFC1034]。如果定期这样做，代表团被破坏的情况会少得多。

当本文档的状态发生变化时，将更新此答案。