使用Googles网站管理员工具验证网站的一种方法是使用主机名并添加提供的文本,将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.
解决方法
好的,我可以复制行为(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强制要求而导致通配符A记录被识别的基础逻辑,但是您可以仔细阅读DNS RFC(和/或BIND来源)了解更多细节.