主页 / server / 问题 / 973666
Accepted
Lassi
Asked: 2019-07-03 02:19:20 +0800 CST

是否需要存在中间子域？

  • 772

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

domain-name-system

4 个回答

  1. Best Answer

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

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

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

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

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

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

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

    域名空间是一个树形结构。树中的节点或者
    拥有至少一个 RRSet 和/或具有共同拥有
    至少一个 RRSet 的后代。
    只有当它有后代时，一个节点才可能存在没有 RRSet ；这个节点是一个空的非终端。

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

    .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。如果它是其他任何东西，特别是NXDOMAINthen teh.k12.ca.us，也www.teh.k12.ca.us不可能存在。

    其次，ANSWER 部分是空的。没有A记录k12.ca.us。这不是错误，A此记录不存在此类型（正如我们已经知道的那样，它“低于”它（参见RFC 7719中的定义）（但通常分辨率是自上而下的，因此我们将在进入下一层之前到达这一步，而不是像我们在这里演示的那样相反目的）。

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

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

    查询结果与 zonefile 内容

    现在混乱从何而来？我相信这可能来自一些错误的想法，即 DNS 名称中的任何点都意味着有一个委托。这是错误的。换句话说，您的example.comzonefile 可以是这样的，它是完全有效且有效的：

    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在类似or的反向区域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它本身永远不会被使用，因此它将保持为空的非终端。这对于TLSADANE 中的记录（例如：）_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下面的协议）：

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

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

    我们现在有这个：

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

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

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

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

    我们可以消除 case b 和 c，因为我们的 zonefile 没有委托（因此永远不会引用其他名称服务器，没有 case b），也没有通配符（所以没有 case 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因为它不会出现在 zonefile 中。所以这里的副本是空的。现在我们完成第 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，因此我们是 case: set an authoritative name error in the response and exit，又名NXDOMAIN。

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

    空的非终端 [RFC2136, section 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 有一个很好的了解）。

    以下两条消息给出了一个提供商必须能够在空非终端上正确执行此规则的问题示例，它给出了问题的一些观点以及我们为什么在那里：

    • 41

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

    [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，并且它对上述主机名的解析没有影响。

    • 11

  3. 如果你直接查询权威的DNS服务器，你会得到没有问题的答案。

    但是，如果您通过另一个没有有效缓存的 DNS 服务器进行查询，您将不会得到有效的答案。查询intermediate.example.com会NXDOMAIN报错。

    • 2

  4. 要直接回答这个问题，您不需要为您实际未使用的中间名称添加记录，但这并不意味着这些名称不存在。

    至于这些名称是否存在，这实际上是一个完全独立的问题，我希望提供一个简短而直观的答案。

    这一切都归结为DNS是一个树结构，其中域名中的每个标签都是一个树节点。例如，www.example.com.有标签www、和 ``（根节点），它们是形成一直到根的路径的树节点。examplecom

    可能使 DNS 的这种基本性质不明显的是，在管理 DNS 数据时几乎总是看不到树，而且我们通常不直接使用树节点本身，而是通常有一个扁平化的记录列表应该存在于不同域名的数据（有效的树路径，如上所述）。

    foo.bar.example.com.使用此扁平列表时会发生什么情况，DNS 服务器软件根据现有记录构建树，如果有记录的节点之间存在间隙（例如，有记录example.com.但没有记录bar.example.com.），这些只是被认为是空树节点。也就是说，这些是确实存在的域名/节点，树没有损坏，这些节点只是没有任何与之关联的数据。

    因此，如果您查询这些空节点之一，您将收到NODATA响应（在权限部分中的NOERROR状态+ SOA），说明请求的记录类型在此节点不存在。如果您改为查询一些实际上不存在的名称，您将得到NXDOMAIN响应，说请求的域名在树中不存在。

    现在，如果您想了解细节，请阅读 Patrick Mevzek 的非常详尽的回答。

    • 2

相关问题