☰

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

tag-icon • tag-icon domain-name-system google
在名称服务器的 TXT 条目中添加带有“www”的主机名会导致网站不可用 - 为什么？

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

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

发生的情况是：DNS 条目传播之后，使用带有“www”的主机名时网站不再可用。编辑：没有特定的错误消息，只是“未找到服务器”。

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

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

在此处输入图片描述

正是最后一条记录导致该网站不可用。

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

如果我不熟悉 nslookup，请原谅我，但我对其中一个仍然不起作用的域进行了一次带有 www 和一次不带有 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 正确。

答案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!"

但如果你有一个具体的记录一下它工作正常：

*.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 源）以了解更多详细信息。

答案2

因为它妨碍了通配符（“ *”）记录。如果您有某项的任何记录，则对于任何记录类型，通配符都不再匹配。

从RFC1034，第 4.3.3 节：

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

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

答案3

是否有可能您在编辑区域时意外删除了 CNAME 记录的 A 记录？

查看完整的区域文件并查看您期望的所有内容是否仍然在那里可能会有所帮助？

相关内容