将带有“www”的主机名添加到名称服务器中的 TXT 条目会使网站不可用 - 为什么？

Question

在使用 Google 的网站管理员工具时验证站点的一种方法是将 TXT 条目添加到名称服务器，使用主机名并添加提供的文本。

偶然地（因为我根本不知道）我添加了两个 TXT 条目，一个带有“www”，一个没有，只是为了确保 Google 会接受代码（因为在网站管理员工具中，网站是用“www”输入的）。

发生的事情是：在 DNS 条目传播后，当使用带有“www”的主机名时，站点不再可用。编辑：没有特别的错误信息，只是“找不到服务器”。

为什么？认为 TXT 条目格式有点随意可能是天真的，但有人可以向震惊的开发人员（=非管理员）解释为什么 TXT 记录可以如此破坏性地影响应该由 A 记录处理的内容？

编辑：这是示例（但当然它不再在线）。该站点托管在 domainfactory 上，这是一个共享主机，您可以在其中编辑 DNS 设置（或让 domainfactory 管理它们 - 在这种情况下，“Ziel”列显示他们的名称；通常混合条目没有问题）：

这正是使该站点不可用的最后一个条目。

但是，告诉我这不应该发生也是一个很好的答案 - 然后我可以询问托管服务提供商。

如果我不熟悉 nslookup，请原谅我，但我在仍然无法正常工作的域之一上进行了一次查找和不使用 www 的查找，结果如下：

C:\>nslookup www.foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Name:    www.foo.de

第二个：

C:>nslookup foo.de
Server:  dns2.colt1.inetserver.de
Address:  195.234.228.93

Nicht autorisierende Antwort:
Name:    foo.de
Address:  81.20.84.178

不同之处在于，没有“www”的请求显示的是“Nicht autorisierende Antwort:”（可能是“非授权答案”），但 IP 是正确的。

Answer 1

好的，我可以复制该行为（BIND 9.6），并相信我已经找出原因：

如果您有通配符A 记录和更具体的 TXT 记录，如下所示，A 记录会中断。

*.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

但如果你有一个特定的A 记录，它工作正常：

*.test.bsd-box.net.       IN        A        127.0.0.1
www.test.bsd-box.net.     IN        A        127.0.0.1
www.test.bsd-box.net.     IN        TXT      "This be a text record, mon!"

所以显然有一个更具体的记录（即使是不同类型的）掩盖了通配符 A 记录。

我不确定导致通配符A记录无法识别的底层逻辑是什么，如果有更具体的TXT记录，或者它是否是 RFC 授权的东西，但您可以仔细阅读 DNS RFC（和/或 BIND来源）了解更多详情。

Answer 2

因为它妨碍了您的通配符 (" *") 记录。如果您有某个项目的任何记录，则对于任何记录类型，通配符根本不再匹配。

来自RFC1034 §4.3.3：

通配符 RR 不适用…… [当] 查询名称或通配符域和查询名称之间的名称 [已知] 存在时。例如，如果通配符 RR 的所有者名称为“*.X”，并且该区域还包含附加到 BX 的 RR，则通配符将应用于名称 ZX 的查询（假设没有 ZX 的明确信息），但不适用到 BX、ABX 或 X。

请注意，该示例与 OP 的情况不匹配，但规则是相同的。