编辑于2017-10-25。 原来的问题是误导。
我们有一个网站在http://admin.gigantisch.nl/的子域上运行。 自从gigantisch.nl域名更改IP地址以来,我们一直无法访问各种设备和networking上的admin子域名。 实验和诊断工具似乎表明这是一个DNS问题。
过去几天我们已经成功访问了多次,但这似乎是由于我们各种设备(包括路由器)上的DNSloggingcaching。 这也可能是由于我们的ISP的DNS服务器和Google的公共DNS服务器的cachinglogging。
运行在线诊断工具时: http : //dnsviz.net/d/admin.gigantisch.nl/dnssec/ ,表示NSEC3logging存在问题。 我不知道这个logging是什么,或者如何pipe理它。 我们的域名注册商的DNS区域编辑器面板没有关于NSEClogging。
让所有这些变得更加莫名其妙的是,我们在子域上运行的另一个网站: http : //backoffice.gigantisch.nl/ ,没有这些问题。
原文问题:
在这个办公室里,我们在我们的主网站的子域上有一个网站,我们可以通过我们的无线连接访问,但不通过我们的有线networking。 我也可以使用蜂窝数据在手机上访问它。
该网站的地址是: http : //admin.gigantisch.nl/
整个域最近更改了IP地址,所以这里可能存在某种DNS问题。 如果使用Google的DNS工具( https://dns.google.com/query?name=admin.gigantisch.nl&type=CNAME&dnssec=true )进行validation,则会在“注释”中说明:“DNSSECvalidation失败,请检查http:// dnsviz.net/d/admin.gigantisch.nl/dnssec/“ 。
该工具,给我们以下错误:
“NSEC3certificate不存在admin.gigantisch.nl/A:NSEC3 RR覆盖通配符本身(* .gigantisch.nl),表明它不存在。
NSEC3certificate不存在admin.gigantisch.nl/A:NSEC3 RR覆盖通配符本身(* .gigantisch.nl),表明它不存在。
至less表明有DNS问题,我猜?
奇怪的是,我们的其他网站没有这些问题, http://backoffice.gigantisch.nl 。 DNSViz工具不指出这个子域的任何错误或警告。
我在想也许gigantisch.nl域的旧DNSlogging被有线路由器caching了,但是我没有用它来软重启。
有线networking作为无线networking的DNS服务器似乎设置为Google的服务器8.8.8.8和8.8.4.4。
对于* .gigantisch.nl有一个DNS Alogging设置,但对于这两个子域都没有。
另外,当我在客户端上运行Windows 10的networking诊断程序时,出现:“您的DNS服务器可能不可用”。 我似乎没有遇到任何其他连接问题,所以这可能与手头上的问题无关。
想法?
编辑:当我设置我的本地连接使用我的ISP的默认DNS服务器,62.179.104.196和213.46.228.196,我可以访问http://admin.gigantisch.nl/没有问题。 当我设置路由器使用这些DNS服务器,但我再次无法访问它,即Chrome给我错误ERR_NAME_RESOLUTION_FAILED 。
编辑2:我试过的无线networking上的设备似乎已经caching了(子)域名的旧DNSparsing。 在Chrome浏览器的隐身标签中,将其加载到其中一个积极testing过的移动设备上,会得到:“此站点无法到达”,同时附带DNS_PROBE_FINISHED_NXDOMAIN 。 (通过在有线networking上的Windows客户端上运行Chrome,可以实现: ERR_NAME_RESOLUTION_FAILED 。)
你修改后再次签署了该区域吗?
你是否等待caching的TTL过期?
当前的错误告诉我们有一个certificate主机名不存在的NSEC3logging:
描述:NSEC3logging(s)certificate不存在(
NXDOMAIN)admin.gigantisch.nlNSEC3:E8KJKO07GL57FJK7N58R9HEFDCO38OG8.gigantisch.nl. IN NSEC3 1 0 1 ab HM79JAC9O3DEMLPKUBMF4IUEV63450TB CNAME RRSIGE8KJKO07GL57FJK7N58R9HEFDCO38OG8.gigantisch.nl. IN NSEC3 1 0 1 ab HM79JAC9O3DEMLPKUBMF4IUEV63450TB CNAME RRSIGNSEC3 RR覆盖通配符本身(
*.gigantisch.nl),表明它不存在。
重新启动路由器不会清除Google Public DNS( 8.8.8.8和8.8.4.4 )上的caching。 这不是一个本地问题,而是存在于实现DNSSECvalidation的任何recursion名称服务器上的一个问题,直到在权威服务器上进行修复并在两者之间的任何caching上过期为止。
当然,你的本地有线networking是有问题的DNS和最有可能的是有问题的路由器。 显然,作为DNS转发器/caching服务器的路由器function是腐败或根本不工作。
尝试一个快速的解决scheme是将dns服务器的路由器dhcp选项从google dns更改为ISP名称服务器,以便每个客户端都能自动获取工作dns服务器ip。 每个客户端需要更新他们的DHCP租约才能使更改生效。
如果您想对路由器进行故障诊断,并且您有所有必要的信息,请尝试重新设置,然后重新configuration并查看。 如果它仍然有同样的问题,那么你别无select,只能和你的服务提供商交谈。
联系您的注册商的支持。 一个叫做rectify-zone东西需要由他们来执行,然后问题就消失了。
根据我们的注册服务商,每当DNSlogging发生变化时,这个rectify-zone应该从最后自动执行。 它通常不能从注册商的pipe理面板执行。 显而易见,整个问题都是由于最终的呃逆,导致rectify-zone没有被执行。