添加一个主机名'www'到名称服务器中的TXT条目使网站不可用 – 为什么？

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

不小心（因为我根本不知道），我添加了两个TXT条目，一个是 “www”，一个是没有的，只是为了确保Google会接受这个代码（因为在网站pipe理员工具中该网站是用“www”input的）。

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

为什么？ 认为TXTinput格式有些武断可能是天真的，但是有人可以向震惊的开发人员（非pipe理员）解释TXTlogging为什么能够破坏性地影响Alogging应该处理的事情？

编辑：这是例子（但当然不再是在线）。该网站托pipe在domainfactory，一个可以编辑DNS设置的共享主机（或者domainfactorypipe理它们 – 在这种情况下，“Ziel”列显示他们的名字;通常混合条目没有问题）：

在这里输入图像描述

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

但是，告诉我，这不应该发生也是一个很好的答案 – 那么我可以问托pipe服务提供商。

原谅我，如果我不熟悉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。

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

如果你有一个通配符 Alogging和一个更具体的TXTlogging如下Alogging中断。

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

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

 *.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!"

所以显然有一个更具体的logging（即使是不同types）掩盖通配符Alogging。

我不确定底层逻辑是什么导致通配符如果有更具体的TXTlogging，或者它是RFC规定的东西，但是您可以仔细阅读DNS RFC（和/或BIND源）获取更多细节。

因为它阻碍了你的通配符（“ * ”）logging。如果您有一个项目的任何logging，通配符不再匹配任何loggingtypes。

从RFC1034 ，§4.3.3：

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

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

是否可能在您编辑区域时意外删除了logging的CNAMElogging？

查看完整的区域文件可能会有所帮助，看看您希望在那里的所有内容是否真的存在？