TL; DR：是的，根据DNS的定义，至少在查询时，需要存在中间子域；它们可能不存在于zonefile中。
首先可能消除的混乱；“空非终端”的定义
您可能会混淆两件事，因为其他答案似乎也是如此。即，在查询名称时会发生什么，以及如何配置名称服务器和区域文件的内容。
DNS是分层的。对于任何叶节点而言，从某种意义上说，如果要查询所有叶节点，则负责任的权威名称服务器应为它们答复而不会出错。
如RFC 8020所述（这只是通常的规则的重复，但仅某些DNS提供程序需要提醒），如果对任何查询，权威的名称服务器都回复NXDOMAIN（即：该资源记录不存在），则表示该资源“下方”的任何标签也不存在。
在您的示例中，如果查询intermediate.example.comreturn NXDOMAIN，则任何适当的递归名称服务器都将立即答复NXDOMAIN，leaf.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，又名“ Empty Non Terminal”：它为空，但不是叶，正如我们已经知道的（在RFC 7719中的定义）之下有一些东西（但通常分辨率是自上而下的，因此我们将在到达下一级之前到达此步骤，而不是像在此处进行演示那样相反）目的）。
这就是为什么事实上，作为捷径，我们说状态代码是NODATA：这不是真正的状态代码，它仅表示NOERROR+空的ANSWER部分，这意味着该特定记录类型没有数据，而其他类型可能存在。
如果您使用下一个“ up”标签（即名称）进行查询，则可以针对相同的结果重复相同的实验ca.us。
查询结果与区域文件内容
现在混乱从何而来？我相信这可能是由于一些错误的想法，即DNS名称中的任何点都意味着存在授权。这是错误的。example.com换句话说，您的zonefile可以像这样，并且完全有效并且可以正常工作：
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协议）：
- 在可用区域中搜索最接近QNAME的区域。如果找到这样的区域，请转到步骤3，否则转到步骤4。
域名服务器将区域查找example.com为QNAME的最近祖先，因此我们可以转到步骤3。
我们现在有这个：
- 在区域中按标签开始向下匹配。[..]
一种。如果整个QNAME都匹配，我们就找到了该节点。[..]
b。如果匹配将我们从权威数据中剔除，我们会推荐您。当我们在区域底部遇到带有NS RR标记切口的节点时，就会发生这种情况。[..]
C。如果在某个标签上不可能进行匹配（即对应的标签不存在），请查看是否存在“ *”标签。[..]
我们可以消除大小写b和c，因为我们的zonefile没有委托（因此，永远不会引用其他名称服务器，没有大小写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，因为它没有出现在zone数据文件。所以这里的副本是空的。现在，我们完成第6步：
仅使用本地数据，尝试添加可能对查询的其他部分有用的其他RR。出口。
在这里与我们无关，因此我们成功了。
这正好解释了观察到的行为：此类查询将返回，NOERROR但也没有数据。
现在，您可能会问自己：“但是，如果我使用任何名称，例如another.example.com通过上述算法，我应该得到相同的答复（没有错误）”，但是NXDOMAIN在这种情况下，观察结果会报告。
为什么？
因为整个算法如所解释，所以从此开始：
以下算法假定RR以几种树结构组织，每个区域一个，而另一个用于缓存
这意味着将上面的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，因此我们的情况是：set an authoritative name error in the response and exitaka 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.
括号中的“可能为空”指定
明确识别出空的非终端，并且
“存在” 空的非终端。
认真阅读上面的段落可能会导致
所有可能的域都存在的解释-
域名[RFC1035] 的建议上限为255个八位字节。例如，
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有很好的了解）。
以下两条消息举例说明了一个提供者必须能够在空非终端上正确执行此规则的问题，它提供了问题的一些观点以及我们为什么会出现在其中：