☰

哪个 RFC 鼓励 DNS 服务器对未知域的查询回复“REFUSED”？

tag-icon • tag-icon domain-name-system bind dns-zone
哪个 RFC 鼓励 DNS 服务器对未知域的查询回复“REFUSED”？

这个问题非常非常如同要求 DNS 服务器响应未知域请求的 RFC但我想我应该把它作为一个新问题来提出。

看起来，权威 DNS 服务器对REFUSED任何针对其不具有权威性的域名的查询都以 rcode 进行响应是一种标准做法。例如：

$ dig @ns1.google.com yahoo.com A | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53533

从先验角度来看，这里有一些替代行为可能是有意义的：

  • 将查询完全黑洞化
  • 返回非权威NXDOMAIN响应
  • 返回非权威的NOERROR回应（这很愚蠢，但我为了完整性而提到它）
  • 返回根名称服务器的预定推荐（这更愚蠢）

是否有 RFC 或类似文档说“REFUSED在这种情况下你必须返回”？

我希望看到关于这种情况的讨论RFC 1034 第 4.3.1 和 4.3.2 节，但我没有。

答案1

我认为标准文档（至少原始 DNS RFC 中没有）中没有明确说明如何处理这种特殊情况。
尽管如此，多年来，大家的共识或多或少已经变成，这REFUSED是我们现有工具中最好的选择。

我将在下面概述对一些不同选项的想法：

问题中列出的选项

将查询完全黑洞化

这对于权威服务器的运营商来说是不利的，因为这种方法会使服务器看起来已关闭，从而导致出现这样的情况：递归服务器反复观察到它不回答他们的查询并完全放弃它，无论QNAME。

从客户端的角度来看这也是不好的，因为它可能导致等到某个超时到期而不是快速收到错误。

（我认为这是最糟糕的选择。）

返回非权威NXDOMAIN响应

这与其他用法不符NXDOMAIN。NXDOMAIN用于表明你知道这个名字不存在， 不是那个你对名字一无所知。

返回非权威的NOERROR回应（这很愚蠢，但我为了完整性而提到它）

首先，我要指出的是，“转介至根”替代方案是这一方案的一个特例。

反对的论点也NXDOMAIN适用于NODATA（权威部分中的NOERROR+ SOA），只需进行微小的调整；它是一种状态，用于表明你知道没有这样的 RRset， 不是那个你缺乏知识。
此外，NODATA表明您知道该名称以某种形式存在（例如，它可能具有其他类型的记录，或者它可能是一个空的非终端）。

NOERROR表示查询被视为有效且可回答，因此应该有某种形式的答案。如果这是一个无法回答的查询，NOERROR则似乎不太合适。

返回根名称服务器的预定推荐（这更愚蠢）

这是过去处理此问题的一种非常常见的方法。答案的内容本身并没有什么用，但它是一个有效格式的引用响应，至少可以清楚地表明被查询的服务器不知道该名称。

NOERROR（我认为在这种情况下这可能是最不愚蠢的使用形式。）

其他选择

地位REFUSED

REFUSED通常被认为是最佳方法，表示服务器配置为不回答此查询。总体而言，这是一种不错的选择，无论是否明确规定必须在这种特定情况下使用。

地位SERVFAIL

也被某些服务器实现使用。
不太清楚的REFUSED是，它没有明确表明不回答是故意的；SERVFAIL通常用于处理有效查询时遇到的意外错误。

答案2

其实很简单，RFC1035 第 4.1.1 节 RCODE 5

Refused - The name server refuses to perform the specified operation 
for policy reasons.  For example, a name server may not wish to
provide the information to the particular requester, or a name server 
may not wish to perform a particular operation (e.g., zone transfer) 
for particular data.

系统管理员已决定配置他们的系统以返回 REFUSED 响应而不是执行其他任何事情。

答案3

以下是部分答案，首先是这篇 DynDNS 博客文章我发现。

从名称服务器的角度来看，它被要求回答一个超出其配置响应能力的问题（DNS 双关语！）。它没有该域名的区域文件，因此无法做出响应。以下RFC 1035，符合要求的名称服务器应该发出 RCODE 5（REFUSED）响应。这是因为“名称服务器由于政策原因拒绝执行指定的操作”而导致的拒绝。

原则上，名称服务器收到对其不具有权威性的名称的查询应该是一件很奇怪的事情。毕竟，从父服务器委派名称服务器这一行为本身就意味着（权威地）声明 NS 记录指定的名称服务器是正确的名称服务器。因此，从历史上看，许多名称服务器都会通过引用根来做出响应。

如今，这种答案似乎被 DNS 运营商广泛鄙视（部分原因是它可以用于放大攻击），如今许多名称服务器都会返回错误。错误通常是 RCODE 5（REFUSED），理由是名称服务器出于政策原因拒绝执行指定的操作。有时，你会看到 RCODE 2 (SERVFAIL)，原因与您在区域由名称服务器加载时看到的情况相同：服务器实际上还不能回答查询，并且不知道它是否能够这样做。

谷歌搜索“引用到根”，结果显示 DNS-OARC 发布了一篇名为“向上推荐被认为有害”：

最近，托管公司 ISPrime 成为使用欺骗源地址的 DNS DDoS 攻击的受害者。有些人称之为放大攻击，因为查询“。IN NS”非常小（47 个八位字节），而向上推荐响应稍大一些（256 个八位字节）。...这次袭击再次引发了一场老争论：对于无法回答的查询，权威名称服务器的适当响应是什么？某些权威域名服务器的配置和/或实施会导致它们返回向上转至根区域。我们建议不要采取此行为，原因如下：

  • 向上引用一般是无用的。遍历空间的解析器已经知道从哪里开始。
  • 适当的迭代解析器应该考虑“超出管辖范围”的向上引用并且忽略数据。
  • 如果没有得到妥善维护，权威名称服务器的根区域“提示”可能会随着时间的推移而变得陈旧，从而导致查询被传递到已退役的根服务器地址。
  • 众所周知，向上推荐会引起“推荐循环”，从而产生数百个无用的查询。

我们认为“REFUSED”响应代码比向上推荐更好。...

此外，在RFC 7719（2015 年 12 月发表）我们发现：

从历史上看，当查询不具有权威性的名称时，许多权威服务器都会参考根区域来回答，但这种做法已经减少。

因此，“转至根目录”显然是一个糟糕的想法 — 但公平地说，这已经是我“最愚蠢”的选择。我还没有弄清楚非权威的 NXDOMAIN 或类似的东西有什么问题。我可能会稍后更新这个答案。

相关内容