是否需要存在中间子域？

Question

如果我拥有 的主机example.com和leaf.intermediate.example.comDNS 记录example.com，但intermediate.example.com本身没有任何记录，这是否会在某些情况下导致问题，或者是否出于某种原因是错误的风格或礼节？我有这样设置的网络服务器，一切似乎都运行良好，但只是想检查是否有我遗漏的东西。

Answer 1

TL;DR：是的，中间子域需要存在，至少在查询时，根据 DNS 的定义；但是它们可能不存在于区域文件中。

首先要消除的可能混淆；“空非终端”的定义

您可能会混淆两件事，因为其他答案似乎也是如此。也就是说，查询名称与配置名称服务器和区域文件的内容时会发生什么。

DNS 是分层的。对于任何存在的叶节点，通向它的所有组件都必须存在，从某种意义上说，如果查询它们，负责的权威名称服务器应无错误地回复它们。

正如RFC 8020 中所解释的（这只是重复了一直以来的规则，但只是一些 DNS 提供商需要提醒），如果对于任何查询，权威名称服务器回复 NXDOMAIN（即：此资源记录不存在），那么这意味着该资源“下方”的任何标签也不存在。

在您的示例中，如果查询intermediate.example.com返回NXDOMAIN，那么任何适当的递归名称服务器将立即回复NXDOMAINforleaf.intermediate.example.com因为如果其中的所有标签都不作为记录存在，则该记录将不存在。

过去在RFC 4592中已经说明了通配符（此处不相关）：

域名空间是一个树状结构。树中的节点要么
拥有至少一个 RRSet 和/或具有共同拥有
至少一个 RRSet 的后代。一个没有RRSets的节点只有在它有
后代的情况下才可能存在；这个节点是一个空的非终端。

没有后代的节点是叶节点。空叶节点不存在。

.US 域名的实际示例

让我们从历史上有很多标签的 TLD 中举一个工作示例，即.US. 在线挑选任何示例，让我们使用www.teh.k12.ca.us.

当然如果你查询这个名字，甚至teh.k12.ca.us你也可以找回A记录。对于我们的目的，这里没有任何结论（中间甚至还有一个 CNAME，但我们不在乎）：

$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86

现在让我们查询k12.ca.us（我不是在查询它的权威名称服务器，但这实际上并没有改变结果）：

$ dig k12.ca.us A

; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us.         IN  A

;; AUTHORITY SECTION:
us.         3587    IN  SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400

;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE  rcvd: 104

我们从这个答案中学到了什么？

首先，它是成功的，因为状态是NOERROR。如果它是其他任何东西，特别是NXDOMAIN那么teh.k12.ca.us，也www.teh.k12.ca.us不可能存在。

其次，ANSWER 部分是空的。没有A记录k12.ca.us。这不是错误，此A记录不存在此类型 ( )，但此记录可能存在其他记录类型，或者此记录是 ENT，又名“空非终端”：它是空的，但不是叶子，正如我们已经知道的那样（请参阅RFC 7719 中的定义），我们已经知道（但通常分辨率是自上而下的，因此我们将在下一级之前到达此步骤，而不是相反，就像我们在这里做的演示一样）目的）。

这就是为什么事实上，作为一种快捷方式，我们说状态代码是NODATA：这不是一个真正的状态代码，它只是表示NOERROR+ 空的 ANSWER 部分，这意味着没有该特定记录类型的数据，但可能有其他记录类型的数据。

如果您使用下一个“向上”标签（即 name ）进行查询，您可以对相同的结果重复相同的实验ca.us。

查询结果与区域文件内容

现在混乱可能来自哪里？我相信这可能来自一些错误的想法，即 DNS 名称中的任何点都表示存在委托。这是错误的。example.com换句话说，您的区域文件可以是这样的，并且它是完全有效且有效的：

example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....

leaf.intermediate.example.com IN A 192.0.2.37

使用这样的区域文件，查询此名称服务器，您将获得与上面观察到的完全相同的行为：查询intermediate.example.com将返回NOERROR空答案。您不需要在 zonefile 中专门创建它（如果您出于其他原因不需要它），权威名称服务器将负责合成“中间”回复，因为它认为它需要这个空的非终端（以及任何其他“中间”（如果有其他标签），因为它看到叶子名称leaf.intermediate.example.com。

请注意，这实际上在某些领域是一种普遍情况，但您可能看不到它，因为它针对的是人们未接触到的更多“基础设施”记录：

• 在像in-addr.arp或这样的反向区域ip6.arpa，特别是最后一个。您将有类似的记录，1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.并且显然每个点都没有委托，每个标签上也没有附加资源记录
• 在SRV记录，如_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.，一个域可以有很多_proto._tcp.example.com和_proto._udp.example.com SRV记录，因为设计它们必须有这个形式，但在同一时间_tcp.example.com，并_udp.example.com会保留为空非终结，因为从来没有使用记录
• 实际上，对于各种协议（例如 DKIM），您还有许多其他基于“下划线标签”的特定名称构造案例。DKIM 要求您拥有类似 的 DNS 记录whatever._domainkey.example.com，但显然_domainkey.example.com它本身永远不会被使用，因此它将保持为空的非终端。这是相同的TLSA记录DANE（例如：_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==），或URI记录（例如：_ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public"）

名称服务器行为和中间回复的生成

为什么名称服务器会自动合成这样的中间答案？DNS 的核心解析算法，如RFC 1034 第 4.3.2 节中详述的原因，让我们在查询上述权威名称服务器以获取名称intermediate.example.com（这是QNAME下面的in 协议）时总结一下我们的案例：

2. 在可用区域中搜索与 QNAME 最近的祖先区域。如果找到这样的区域，则转至步骤 3，否则转至步骤 4。

名称服务器发现 zoneexample.com作为 QNAME 的最近祖先，因此我们可以转到第 3 步。

我们现在有这个：

3. 在区域中开始逐个标签匹配。[..]

一种。如果整个 QNAME 匹配，我们就找到了节点。[..]

湾 如果匹配将我们带出权威数据，我们有推荐。当我们遇到一个带有 NS RRs 标记沿区域底部切割的节点时，就会发生这种情况。[..]

C。如果在某个标签处不可能匹配（即对应的标签不存在），则查看“*”标签是否存在。[..]

我们可以消除情况 b 和 c，因为我们的区域文件没有委托（因此永远不会引用其他名称服务器，没有情况 b），也没有通配符（所以没有情况 c）。

我们这里只需要处理情况a。

我们开始在区域中逐个标签地进行匹配。因此，即使我们有一个很长的sub.sub.sub.sub.sub.sub.sub.sub.example.com名字，在某些时候，我们也会遇到情况 a：我们没有找到推荐人，也没有找到通配符，但我们最终得到了我们想要结果的最终名字。

然后我们应用案例a的其余内容：

如果节点上的数据是CNAME

不是我们的情况，我们跳过那个。

否则，将与 QTYPE 匹配的所有 RR 复制到答案部分并转到步骤 6。

无论我们选择什么 QTYPE（A、AAAA、 NS等），我们都没有 RR，intermediate.example.com因为它没有出现在区域文件中。所以这里的副本是空的。现在我们完成第 6 步：

仅使用本地数据，尝试添加可能对查询的附加部分有用的其他 RR。出口。

在这里与我们无关，因此我们以成功结束。

这完全解释了观察到的行为：此类查询将返回NOERROR但也没有数据。

现在，您可能会问自己：“但是如果我使用任何名称，就像another.example.com上面的算法那样，我应该得到相同的答复（没有错误）”，但NXDOMAIN在这种情况下，观察结果将改为报告。

为什么？

因为所解释的整个算法都是从以下开始的：

下面的算法假设 RRs 被组织成几个树结构，一个用于每个区域，另一个用于缓存

这意味着上面的 zonefile 被转换成这棵树：

+-----+
| com |  (just to show the delegation, does not exist in this nameserver)
+-----+
   |
   |
   |
+---------+
| example | SOA, NS records
+---------+
   |
   |
   |
+--------------+
| intermediate | no records
+--------------+
   |
   |
   |
+------+
| leaf | A record
+------+

所以按照算法，从上往下，确实可以找到路径：（com > example > intermediate因为路径com > example > intermediate > leaf存在）但是对于another.example.com，在 树中com > example没有找到another标签之后，作为 的子节点example。因此，我们属于上述选项 c 的一部分：

如果“*”标签不存在，请检查我们要查找的名称是查询中的原始 QNAME 还是我们由于 CNAME 而遵循的名称。如果名称是原始的，则在响应中设置权威名称错误并退出。否则直接退出。

标签*不存在，我们没有遵循 a CNAME，因此我们在 case: set an authoritative name error in the response and exit，又名NXDOMAIN。

请注意，上述所有内容在过去确实造成了混乱。这被收集在一些 RFC 中。例如，参见定义通配符的这个意想不到的地方（DNS 规范的乐趣是如此难以理解）：RFC 4592“通配符在域名系统中的作用”，特别是其第 2.2 节“存在规则”，也在我的答案，但这里更完整：

空非终结符 [RFC2136，第 7.16 节] 是不拥有资源记录但具有拥有资源记录的子域的域名。在第 2.2.1 节
“_tcp.host1.example”中。是一个空的非终端名称的例子。
RFC 1034 的第 3.1 节中的文本引入了空的非终结符：

# The domain name space is a tree structure.  Each node and leaf on
# the tree corresponds to a resource set (which may be empty).  The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.

括号中的“which may be empty”指定空的非
终结符被明确识别并且空的非终结符
“存在”。

迂腐地阅读上面的段落可能会导致
所有可能的域都存在的解释——
一个域名的建议限制为 255 个八位字节 [RFC1035]。例如，
www.example。可能有一个 A RR，就实际
而言，它是域树的一片叶子。但是定义可以理解
为sub.www.example。也存在，尽管没有数据。通过扩展，所有可能的域都存在，从根向下。

由于 RFC 1034 在第 4.3.1 节中还定义了“指示名称不存在的权威名称错误”，因此这显然不是原始定义的意图，证明需要在下一节中更新定义。

然后下一节的定义就是我开头引用的那段。

请注意，RFC 8020（上NXDOMAIN真正意义NXDOMAIN，那就是，如果你回复NXDOMAIN了intermediate.example.com，那么leaf.intermediate.example.com就不能存在），部分被授权由于各种DNS提供商没有按照这种解释并造成严重破坏，或者他们只是错误的，例如参见这一个2013 年在一个开源权威域名服务器代码中修复：https : //github.com/PowerDNS/pdns/issues/127

然后人们需要为他们制定特定的对策：这不是积极的缓存，NXDOMAIN因为对于那些提供者来说，如果你到达NXDOMAIN某个节点，它可能仍然意味着你得到的东西不同于NXDOMAIN它下面的另一个节点。

这使得 QNAME 最小化 (RFC 7816) 无法获得（有关详细信息，请参阅https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf） ，同时希望增加隐私。在 DNSSEC 的情况下，空非终端的存在在过去也造成了问题，围绕不存在的处理（参见https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf如果有兴趣，但您之前确实需要对 DNSSEC 有很好的了解）。

以下两条消息举例说明了一个提供商必须能够在 Empty Non-Terminals 上正确执行此规则的问题，它给出了问题的一些视角以及我们为什么会出现这种情况：

• https://mailarchive.ietf.org/arch/msg/dnsop/XIX16DCe2ln3ZnZai723v32ZIjE
• https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018640.html

Answer 2

我可能误解了 Khaled 的回答，但缺少中间记录绝不应该成为分区名称解析的问题。请注意，此 dig 输出既不来自也不指向其teaparty.net或其任何子区域的权威 DNS 服务器：

[me@nand ~]$ dig very.deep.host.with.no.immediate.parents.teaparty.net
[...]
;; ANSWER SECTION:
very.deep.host.with.no.immediate.parents.teaparty.net. 3600 IN A 198.51.100.200

事实上，您应该能够dig自己做到这一点，并得到那个答案 -teaparty.net是一个真正的域，在我的控制之下，并且确实包含该A记录。您可以验证very和之间的任何区域都没有记录teaparty.net，并且它不会影响您对上述主机名的解析。