我们有一个小型networking，主服务器（托pipe我们自己的网站，作为名称服务器）和一些networking托pipe服务器。 从昨天开始，我们在我们的networking上托pipe一个我们客户的域名。
networking服务器设置正确，名称服务器（以及其他域都可以正常工作），但由于主机名查找失败，域无法访问。 Chrome说主机名无法parsing，一些DNS检查工具说，域名找不到，甚至只是崩溃。
当我运行dig directgeslaagd.com命令时，我只能得到一个权限部分，表示为TLD提供的com 600 IN SOA a.gtld-... 当我运行dig @ns1.webwhales.nl directgeslaagd.com命令时，得到正确的结果（ directgeslaagd.com. 86400 IN A 149.210.185.13 ）。 这发生在我们的服务器networking内部和外部。 所以，我的结论是，我的名字服务器工作正常，对吧？
当我调整我的Windows PC的主机文件，直接从149.210.185.13加载这个域，网站的工作，结论是，也是Web服务器正常工作。 当我查找WHOIS数据时，所有名称服务器和数据都是正确的。 昨天我通过我们的注册商更新了名称服务器的详细信息，但是没有帮助。
你知道这里可能是什么问题吗？ 我从来没有见过这样的事情。 这里使用的领域是实际的领域，所以你可以看看自己。
得到了我的注册商的答复。 事实certificate，当域名持有者的电子邮件地址发生变化时，ICANN会发送一封validation邮件。 他们现在为他们所有的顶级域名（TLD）做了几个月的工作。 他们给你一两个星期的时间来点击该电子邮件中的链接，否则你的域名将被封锁。
在这种情况下，WHOIS数据中的注册服务机构地位应由客户负责 。 具有讽刺意味的是，这封电子邮件通常在收件人的垃圾邮件箱中消失 如果他们先向技术联系人发送警报（或者至less另一个在该域中注册的电子邮件地址），那将会很好。
希望这会帮助别人。
最好将WHOIS视为人类“尽力而为”的信息工具。 它提供的信息并不总是现在或准确，在任何情况下，它都不是DNS曾经咨询过的。
dig +trace +additional example.com是你的朋友; 它可以帮助您将问题形象化，并向您展示WHOIS永远不会做的事情。 这会在根名称服务器上启动一个跟踪，并跟随名称服务器委派。
在你的具体情况下，这是跟踪得到：
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1425204658 1800 900 604800 86400 ;; Received 112 bytes from 192.33.14.30#53(192.33.14.30) in 11 ms
这应该是一个钟声：这和你之前的挖掘所看到的非常相似。 （ com.和它的SOAlogging的权威部分）问题是com.的TLD名称服务器com. 没有为其他域名服务器提供代理服务。
这是来自WHOIS的信息最终变得有用的地方： directgeslaagd.com. 尚未过期（有效期至2016年12月），并假定有三个名称服务器configuration…但这不是TLD名称服务器在查询时实际提供的有效反映。
问题出在您的注册商的networking界面和TLD域名服务器之间。 尝试在注册商的networking界面中find一些可能提示为什么会发生这种情况的提示。 否则，您需要直接与您的注册商联系，因为他们是唯一能为您提供直接问题的人。