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 ;; flags: qr rd; QUERY: 1,ANSWER: 0,AUTHORITY: 0,ADDITIONAL: 0
立即返回REFUSED是适当的恕我直言,而不是只是在服务器机房的地板上删除请求.
当我向我的提供商抱怨他们的服务器没有响应时,他们要求我引用他们的服务器违反的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协议.
谢谢您的帮助.
解决方法
也就是说,这仍然是一个有趣的问题,所以我将采取我的解决方案.
文档RFC 1034和RFC 1035涵盖了DNS服务器的基本功能,它们共同形成STD 13.答案必须来自这两个RFC,或者由更新它的后续RFC澄清.
在我们继续之前,在DNS范围之外存在一个巨大的陷阱需要被调出：这两个RFC早于BCP 14(1997),该文件阐明了MAY,MUST,SHOULD等语言.
>在该语言正式化之前编写的标准可能使用了清晰的语言,但在某些情况下却没有.这导致了软件的不同实现,大规模混乱等.
>不幸的是,STD 13在几个方面被解释了
区域.如果语言在某个操作区域不牢固,那就是
经常需要找到澄清的RFC.
有了这个,让我们从RFC 1034 §4.3.1开始说：
- The simplest mode for the server is non-recursive,since it
can answer queries using only local information: the response
contains an error,the answer,or a referral to some other
server “closer” to the answer. All name servers must
implement non-recursive queries.
…
If recursive service is not requested or is not available,the non-
recursive response will be one of the following:
An authoritative name error indicating that the name does not
exist.A temporary error indication.
Some combination of:
RRs that answer the question,together with an indication
whether the data comes from a zone or is cached.A referral to name servers which have zones which are closer
ancestors to the name than the server sending the reply.RRs that the name server thinks will prove useful to the
requester.
这里的语言相当坚定.没有“应该”,但是“将会”.这意味着最终结果必须是1)在上面的列表中定义,或者2)标准轨道上的后续文档所允许的,该文档修改了功能.我不知道有任何这样的措辞存在忽略请求,我会说开发人员有责任找到反驳研究的语言.
鉴于DNS在网络滥用场景中的频繁作用,不要说DNS服务器软件没有提供选择性地丢弃地板上的流量的旋钮,这在技术上违反了这一点.也就是说,这些不是默认行为,也不是非常保守的默认行为;两者的例子是用户要求软件删除特定名称(rpz-drop.),或者超出某些数字阈值(BIND的max-clients-per-query).根据我的经验,几乎闻所未闻的软件以违反标准的方式完全改变所有数据包的默认行为,除非该选项增加了对违反标准的旧产品的容忍度.这里情况不同.
简而言之,这个RFC可以并且确实会被运算符自行决定违反,但通常这是以某种精确的方式完成的.完全忽略标准的各个部分是非常不常见的,特别是当专业共识(例如：BCP 16 §3.3)错误地支持在整个DNS系统上产生不必要的负载时.考虑到这一点,删除所有没有权威数据的请求的不必要的重试是不可取的.
更新：
关于在场上放弃查询是不可取的,@ Alnitak与我们分享了目前有一个Draft BCP详细介绍了这个主题.将此作为引文使用起来还为时过早,但它确实有助于强化社区共识与此处所表达的内容保持一致.特别是：
Unless a nameserver is under attack,it should respond to all
queries directed to it as a result of following delegations.
Additionally code should not assume that there isn’t a delegation
to the server even if it is not configured to serve the zone.
broken delegations are a common occurrence in the DNS and receiving
queries for zones that the server is not configured for is not
necessarily an indication that the server is under attack. Parent
zone operators are supposed to regularly check that the delegating
NS records are consistent with those of the delegated zone and to
correct them when they are not [RFC1034]. If this was being done
regularly,the instances of broken delegations would be much lower.
当此文档的状态发生变化时,将更新此答案.
