我的域名注册商和DNS提供当前忽略对未知域名的DNS请求。 通过忽略我的意思是黑洞和永不回应，这导致我的DNS客户端和parsing器库重试，退避，并最后超时。
dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org ... ;; connection timed out; no servers could be reached 在调查其他stream行的域名服务时，我发现这种行为是非常独特的，因为其他提供者返回5（REFUSED）的RCODE：
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 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
立即返回REFUSED是适当的恕我直言，而不是把请求放在服务器机房楼层。
当我向服务提供商抱怨他们的服务器没有响应时，他们要求我引用他们的服务器违反的RFC。 我知道奇怪的是，他们要求我certificate他们的服务器应该响应所有的请求，但这样做。
问题 ：
对我来说，不答复DNS查询是不好的。 大多数客户端将退避，然后重新发送相同的查询到相同的DNS服务器或另一台服务器。 它们不仅会减慢客户端速度，而且会导致相同的查询由其自己或其他服务器再次执行，具体取决于权威名称服务器和NS条目。
在RFC 1536和2308中 ，出于性能方面的考虑，我看到了很多有关负面caching的信息，并停止重新发送相同的查询。 在4074年，我看到有关返回RCODE为0的空答案的信息，所以客户端知道没有ipv6信息会引起客户端询问A RRs，这是另一个空响应的例子。
但是我找不到一个RFC，它说DNS服务器应该响应请求，可能是因为它是隐含的。
当我将我的域名（和相关的DNSlogging）迁移到他们的服务器时，或者在我用他们的服务注册一个新域名后的第一个X分钟时，就会出现特定的问题。 权威域名服务器发生变化的时间（现在相当快）以及服务器开始为DNSlogging服务的时间之间存在滞后。 在这段时间内，DNS客户端认为他们的服务器是权威的，但是他们从不回应请求 – 即使是REFUSED 。 我理解这个延迟是正确的，但我不同意不答复DNS请求的决定。 为了logging，我知道如何在他们的系统中解决这些限制，但我仍然在与他们合作，以改善他们的服务，使之更符合DNS协议。
谢谢您的帮助。
谢恩的build议是正确的。 在启动切换之前未能将数据从一台授权服务器迁移到另一台授权服务器是一个中断的邀请。 无论从那一刻起发生什么事情，这都是摆脱NSlogging的人发起的中断。 这就解释了为什么更多的人不会向您的提供商提出这种投诉。
这就是说，这仍然是一个有趣的问题，所以我要采取我的破解。
DNS服务器的基本function由文档RFC 1034和RFC 1035涵盖，共同组成STD 13 。 答案必须来自这两个RFC，或由后来更新它的RFC来澄清。
在我们继续之前，在DNS的范围之外还有一个很大的缺陷需要被提出：这两个RFC早于BCP 14 （1997），这个文件澄清了可能的语言，必须，等等。
那么，让我们从RFC 1034§4.3.1必须说：
- 服务器的最简单模式是非recursion的，因为它只能使用本地信息来回答查询：响应包含错误，答案或者与其他服务器的引用“更靠近”答案。 所有名称服务器都必须实现非recursion查询。
…
如果recursion服务未被请求或不可用，则非recursion响应将是以下之一：
指示该名称不存在的权威性名称错误。
临时错误指示。
一些组合：
回答问题的RR，以及数据是来自区域还是被caching的指示。
名称服务器的引用，这些名称服务器具有比发送回复的服务器更接近名称祖先的区域。
名称服务器认为的RR将certificate对请求者有用。
这里的语言是相当坚定的。 没有“应该”，而是“将要”。 这意味着最终的结果必须是1）在上面的列表中定义的，或者2）由标准轨道上修改function的稍后文档所允许的。 我不知道有任何这样的言辞是无视这个请求的，我认为开发者有责任去find反驳这个研究的语言。
鉴于DNS在networking滥用情况下的频繁作用，不要说DNS服务器软件不提供select性地将stream量丢在地板上的旋钮，这在技术上是违反的。 也就是说，这些要么不是违约行为，要么是非常保守的违约; 两者的例子都是需要软件删除特定名称（ rpz-drop. ）的用户，或者超过了某个数字阈值（BIND的max-clients-per-query的max-clients-per-query ）。 根据我的经验，这种软件几乎没有听说过以违反标准的方式完全改变所有数据包的默认行为，除非该选项是增加对违反标准的旧产品的容忍度的选项。 情况并非如此。
简而言之，这个RFC可以被运营商自行决定，但通常这是以某种精确的方式完成的。 特别是当专业共识（例如： BCP 16§3.3 ）不利于在整个DNS系统上产生不必要的负担时， 完全忽视标准的各个部分是非常罕见的。 考虑到这一点，删除不存在权威数据的所有请求的不必要的重试是不太理想的。
更新：
关于放弃查询当然是不可取的，@Alnitak与我们分享，目前有一个关于这个主题的BCP草案的细节。 把这个引用作为引用还为时过早，但是这有助于加强社区共识与这里所expression的内容相一致。 尤其是：
除非名称服务器受到攻击，否则它应该响应所有针对它的查询，作为后续授权的结果。 此外，代码不应该假定没有委派给服务器，即使它没有configuration为服务区域。 破坏的委托在DNS中是经常发生的，并且接收对服务器未configuration的区域的查询不一定表示服务器受到攻击。 家长区域操作员应定期检查委派的NSlogging是否与委派区域的logging一致，并在不是[RFC1034]时进行更正。 如果这样做是定期进行的，破碎的代表团的情况会更低。
当这个文档的状态改变时，这个答案会被更新。
当您将域名的权威DNS移动到新的提供商时，您应该始终（总是）在您更改域名注册（whois）信息之前，明确地对新提供商进行testing（并确保它们发送准确的configurationlogging）指向新的权威DNS服务器。
粗略地说，你会采取的步骤：
确保新的授权服务器正常工作。 明确地查询它们：
dig @new-ns.example.com mydomain.com
从你的问题，听起来像是他们没有回应这些查询？ 但是，你说的“未知的域名”不应该在这一点上，它应该在他们的系统中完全configuration（并响应你configuration的logging）。
但是，如果您已经在自己的系统中configuration了域，则必须在此时用正确的logging进行响应。 如果不是，那么他们不能正确地托pipe这个区域，你应该对他们大喊大叫。 不pipe它是否响应一个没有configuration的域名都是无关紧要的。 （如果我仍然不知道你在说什么，请让我知道）。
如果新的提供商绝对不能在交换之前填充logging，那么他们如何回应并不重要 – 将用户指向完全拒绝查询的权威会导致域名停机，就像您是根本得不到答复。