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

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

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

在调查其他流行的域名服务时，我看到此行为非常独特，因为其他提供程序返回的RCODE为5（拒绝）：

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，这是空响应的另一个示例。

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

当我将域（和关联的DNS记录）迁移到他们的服务器时，或者在我向他们的服务注册新域后的最初X分钟内，就会发生特定的问题。在权威性名称服务器更改（如今这真是太快了）的时间与它们的服务器开始为我的DNS记录提供服务之间存在时间差。在此滞后时间内，DNS客户端认为其服务器是权威的，但它们从未响应请求-即使使用REFUSED。我理解延迟是可以的，但是我不同意不响应DNS请求的决定。作为记录，我了解如何解决他们系统中的这些限制，但我仍在与他们合作，以改善他们的服务，使其更符合DNS协议。

谢谢您的帮助。

编辑：

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

Shane的建议是正确的。在启动转换之前无法将数据从一台权威服务器迁移到另一台权威服务器的原因是中断。无论从那时起发生什么，这都是由摆动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的max-clients-per-query）。在我的经验中，该软件完全违反了标准，完全改变了所有数据包的默认行为，这在我的经验中是闻所未闻的，除非该选项增加了对旧产品违反标准的容忍度。这里情况不同。

简而言之，此RFC可以而且确实会被操作员酌情违反，但是通常这是通过某种精确的方式来完成的。为了方便起见，完全无视标准的各个部分是非常罕见的，特别是当专业共识（例如：BCP 16§3.3）错误地支持它，而不希望在整个DNS系统上产生不必要的负载时。考虑到这一点，从丢弃所有不存在权威数据的请求中进行不必要的重试是不希望的。

更新：

对于理所当然地在地面上进行查询是不希望的，@ Alnitak与我们分享了当前有一个BCP草案详细介绍了这个主题。将其用作引用还为时过早，但这确实有助于加强社区共识与此处所表达的一致。尤其是：

除非名称服务器受到攻击，否则它应响应以下委派的结果，对指向它的所有查询作出响应。另外，即使未将服务器配置为服务于区域，代码也不应假定没有服务器委托。损坏的委托是DNS中的常见现象，接收到针对未为其配置服务器的区域的查询并不一定表示该服务器受到攻击。父区域操作员应定期检查委派的NS记录是否与委派区域的记录一致，并在不正确时进行更正[RFC1034]。如果定期进行此操作，则代表团中断的情况将大大降低。

当本文档的状态更改时，此答案将更新。

将域的权威DNS移至新的提供程序时，应始终（始终！）针对新的提供程序进行显式测试（并确保它们发送了正确的配置记录），然后再更改域注册（信息）信息指向新的权威DNS服务器。

大致来说，您将采取的步骤：

1. 在新的DNS提供程序上进行所有设置。您应该创建并填充所有区域。

2. 确保新的权威服务器正常运行。明确查询它们：

   dig @new-ns.example.com mydomain.com
   

   从您的问题来看，这听起来像是他们没有回应这些查询吗？但是，您说的是“未知域”，它现在不应该在它的系统中完全配置（并使用您配置的记录进行响应）。

   但是，如果你已经已经在他们的系统中配置的领域，它必须在这一点正确的记录响应。如果不是，那么他们就不能正确托管该区域，您应该对他们大喊大叫；它是否响应未配置的域应该无关紧要。（如果我仍然不知所措，请告诉我）。

3. 使用您的域注册商（whois）切换权威名称服务器，使旧的DNS提供程序可以正常运行，直到流量不再达到它（至少24小时）为止。

如果新提供者在进行切换之前绝对无法填充记录，那么他们的响应方式实际上就无关紧要-将用户指向完全拒绝查询的权威机构，将导致您的域停机，就像您完全没有回应。