粘合记录/子主机是否会覆盖域名 DNS 服务器记录中的 DNS 通配符条目或 A 记录？
例如：ns1.example.com = 1.1.1.1 at 注册商 DNS glue /子主机
ns1.example.com = 2.2.2.2 DNS 服务器 example.com 上的通配符条目
如果我从 8.8.8.8 或外部 DNS 互联网 ping ns1.example.com，它会转到 1.1.1.1 还是 2.2.2.2？
如果是的话，哪个 RFC 规定了这一政策？
那么，在超过 40 条回复/答案/评论中，人们却投票否决了我的问题？
因此，一百万条评论之后又出现了另一个示例。如果我的 DNS 服务器中有一个通配符记录，即 *.example.com = 6.6.6.6 注册商有一个 ns1.example.com 的胶水记录 = 1.1.1.1 在全球互联网上，ns1.example.com 会解析为什么？–
答案1
TL;DR：您将去哪里是不确定的（取决于您将使用哪个解析器），并且没有 RFC 明确说明这一点，但下面描述了各种提示。
首先，不要混淆。你使用的 3 个 IP 地址是存在的，其中至少有两个目前使用率很高。使用它们不但不会给你带来任何好处，还会造成很多危害。有一个 RFC (5737) 给出了这方面的建议，但简而言之，192.0.2.0/24就是为了满足这种需求。
另外，您的术语有点错误：胶合器位于给定委派切割的父级，并且该父级通常被称为注册表，至少在您处理接近树的顶部时是这样。请注意，这里的注册商可能根本没有任何作用，除非它也是 DNS 托管公司，但从技术上讲，这是一项单独的工作。
然后，没有 RFC 明确说明这一政策，而且它至今仍是热门讨论的话题。它被称为“以儿童为中心”与“以父母为中心”，以决定当“相同”内容位于区域切割的两侧时，应该考虑哪一个。
当然，RFC 所说的是，两者的内容应该相同，因此这一点没有意义。但是，NS记录也是如此，确实存在差异，这通常是配置错误的迹象，会导致问题从解决的最小延迟到更深层次的破坏。
参见RFC 1034关于此：
作为安装的最后一步，应将使委托生效所需的委托 NS RR 和粘合 RR 添加到父区域。两个区域的管理员应确保标记切口两侧的 NS 和粘合 RR 一致并保持一致。
RFC 可能会略微暗示子节点应该具有权威性，因为通常父节点中的所有内容都只是为了帮助找到子节点并与其通信，因此如果出现差异，父节点数据应该被丢弃。然而，这有一个后果：执行此操作的解析器仍必须定期再次询问父节点，以确保委托没有改变，否则子节点将永远保留。
为什么我们可以从 RFC 中解释这一点：因为 DNS 数据包有部分，所以有一个部分可以是“答案”，另一个部分可以是“附加”。当父级返回NS包含粘合详细信息的记录集时，粘合位于“附加”中，因为它们不被视为答案的一部分，它们只是用来帮助解析。此外，使用 DNSSEC，粘合（NS实际上是父级的记录）未签名，暗示它们的权威性“较低”。
在 DNSSEC 签名区域中，每个资源记录集 (RRset) 都有对应的 RRSIG 资源记录。请注意，用于委派到子区域的记录（NS 和粘合记录）未经签名；这些记录出现在子区域中并在那里签名。
还有另一个暗示RFC 2181 §5.4.1，我在此引用其中的部分内容：
在考虑是否接受回复中的 RRSet 或者保留其缓存中的 RRSet 时，服务器应该考虑各种数据的相对可信度。
[...]
可信度应按从高到低的顺序排列：
[...]
- 权威回复的答案部分包含的权威数据。
[...]
- 来自主要区域的胶水，或来自区域转移的胶水，
[...]
- 来自权威答案的附加信息，来自非权威答案的权威部分的数据，来自非权威答案的附加信息。
请注意，在这个精简的列表中，只有第一个点可以来自子节点，接下来的 2 个点来自父节点。因此，通过阅读此列表，您通常会推断解析器应该以子节点为中心（本节的其余部分进一步讨论了粘合，以及 DNSSEC 签名数据应被视为更值得信赖的事实，这再次将子节点置于父节点之上）。但正是因为它增加了其他复杂性，所以并非所有递归名称服务器都是以子节点为中心的。
因此，在这种情况下，一些解析器是以父级为中心的。
关于这个主题有各种研究，例如：
- https://www.dns-oarc.net/files/workshop-201103/ICANN-SF-Looking-at-DNS-traces.pdf进一步讨论了以子为中心和子粘性（不再询问父母）之间的区别，表明大多数解析器都是以子为中心或子粘性的……至少除了以父母为中心的 Google 公共 DNS
- https://conferences.sigcomm.org/imc/2019/presentations/p10.pdf讨论了如果父级和子级的 TTL 不同，如何选择 TTL；表明在这种情况下，大多数解析器都是以子级为中心的（正如预期的那样）
- https://annasperotto.org/publication/papers/2020/sommese-pam-2020.pdf一份最新的完整研究论文；结论包括：“这是第一项研究，表明在 .com、.net 和 org 区域（占 DNS 命名空间的 50%）中，大约 8%（1300 万）的域名不符合该标准。”和“最后，我们还建议解析器供应商遵守 RFC2181 中的权威信息排名（考虑到 RFC5452 中规定的缓解 Kaminsky 攻击的建议），并在可能的情况下明确询问子节点的 NS 记录，类似于 DNSSEC 中所做的操作，其中签名记录仅在子节点处可用”
此外，目前关于 DNS 术语的规范文档RFC 8499，遗憾地避开了这个话题，但你可以在之前的电子邮件讨论中找到这个话题，开始于https://mailarchive.ietf.org/arch/msg/dnsop/fXmzHFzh153OO01hA5Oq8-T-fO8/；此存档提案位于https://www.ietf.org/archive/id/draft-huque-dnsop-ns-revalidation-01.txt讨论了以孩子为中心时必须在父母处重新验证 NS 记录的问题。
为了说明还存在多少争论，或者更准确地说，区域削减和数据问题双方各执一词，目前至少 IETF 中的这些文档涉及该主题，每个文档都提出了新的记录或处理该削减的新方法：
但正是因为要点不明确，每个人都会选择其中一种情况，所以您陷入了 DNS 的盲区，结果并不确定，具体取决于您询问的对象。换句话说：您应该不惜一切代价避免这种情况。
答案2
我会尝试写一个非常简洁的答案来补充帕特里克发布的长答案：
首先，通配符记录本身不会受到任何粘合记录的影响。
但是您描述的粘合记录与权威区域中的地址记录不匹配（您的示例中可能存在非通配符记录）的情况显然很糟糕，并且绝不是我们所希望的，因为它会导致不一致的查找结果。
example.com当解析器服务器在（例如）中查找名称时foo.example.com，它（如 Patrick 所述）不确定它是在代表客户端执行的查找过程中仅使用来自NS引荐响应的和粘合记录供自己内部使用，还是在进行客户端要求的实际查询之前实际从权威服务器查找NS+ 相关地址记录。
因此，如果您混淆了名称服务器的粘合记录和/或权威记录，则可能会得到不同的结果，在某些情况下可能会彻底失败。
也就是说，如果客户端请求ns1.example.com，那么返回的始终是权威服务器的答案，而不是引用响应中的粘合剂（对此没有不确定性）。
这里的复杂因素是，如果您对哪个服务器实际上是权威的看法不一致（请参阅上文），那么查询哪个所谓的权威服务器可能会因实施而异。
TL;DR 永远不要做问题中描述的场景中的事情。