在过去 15 多个小时内,我们的一个域出现了一个奇怪的问题。该域在该国许多地区无法解析。我尝试在几个不同的 Linux 服务器上 ping 它并得到:
example.com: Temporary failure in name resolution
不过,这个问题不受地域限制。现在全国各地的人都告诉我他们也无法ping通该域。但是,有些人可以ping该域并正常访问它。
最后,有人把我指向这个网站:https ://dnschecker.org/ip-blacklist-checker.php
当我尝试解析域时,“列入黑名单?” 除了这个之外,所有这些都不是:dnsbl.spfbl.net
当我单击错误时,它会说:
没有找到 rDNS。
此 IP 已被标记,因为没有有效的 FCrDNS。
为这个 IP 注册一个有效的 rDNS,它指向同一个 IP。
rDNS 必须在您自己的域下注册,您才能将其删除。
我想不出是什么导致了这个或如何解决它。据我所知,域的 A 记录并不指向静态 IP,因为它通过 Cloudflare 负载均衡器。我认为这可能是我们用于名称服务器的 Cloudflare 的问题。然而,他们的门户昨天根本没有显示任何内容,或者今天早上没有显示任何相关内容。
我们发现的唯一解决方法是手动更改首选 DNS 服务器。例如,Google 和 OpenDNS 不解析域。在 dnsblacklist.org 上,12 个 DNS 解析器中有 7 个无法解析它。Cloudflare 和其他 4 个解析器可以成功解决它。如果我们将首选 DNS 服务器更改为1.1.1.1
手动在服务器上,现在他们可以 ping 域。
问题是我们所有的公共用户显然不会这样做。关于到底发生了什么的任何想法?我最近根本没有对域记录进行任何更改,这不会影响我也使用 Cloudflare 作为名称服务器的任何其他域。该问题会影响该域上的所有子域以及主域,无论该地址上的流量是否通过 Cloudflare 代理。
更新:
另一个域:
有问题的域:
如果您访问https://dnsviz.net/d/phreaknet.org/X44olg/dnssec/,您现在会发现您的域中不少于 6 个虚假错误和 3 个错误。换一种说法:它在 DNS 层被严重破坏:
我不知道您曾经检查过哪些服务,但显然他们没有注意到 DNSSEC 问题,因此它们并不好。使用
dnsviz.net
,它是经过尝试和信任的。正如评论中所说,DNSSEC 通常是“它在那里工作但不在那里”的来源,因为如果它被破坏,只有通过验证解析器才会被视为破坏,而解析器并不是所有的解析器。此外,DNSSEC 中有许多边缘案例可以使一个解析器接受答案,而不是另一个。
您将需要解决所有这些问题。
首先从完全删除 DNSSEC 开始,除非您确定掌握它。这意味着去其当前的赞助注册商(如 whois 中所见的 Namecheap),并找到在
DS
您的域的注册中心删除记录的方法。完成此操作后,您将需要等待。多少钱?
.ORG 权威域名服务器
DS
以一天的 TTL 发布您的记录:因此,您需要在此记录消失后至少等待一天(这可能会在您要求注册商将其删除后的一段时间内发生)。
DS
记录消失至少 1 天后,再次进行 DNSviz 检查,看看是否还有其他问题。但是,您可能已经解决了所有问题。或者,您应该请您的 DNS 提供商帮助您解决域中与 DNS 相关的问题。特别是因为核心问题是:
"RRSIG phreaknet.org/DNSKEY alg 13, id 2371: The Signature Expiration field of the RRSIG RR (2020-10-18 21:55:18+00:00) is 1 day in the past."
这意味着您的 DNS 提供商的错误没有更新您域上的签名,或者如果您被指示更改DS
注册表中的记录以使用您的 DNS 提供商的另一个密钥并且您没有这样做,那么您自己的错误. 此签名的到期最近解释了为什么您在一天前开始收到有关问题的报告。如果您的 DNS 提供商可以使用当前密钥在所有记录上重新生成有效签名,因为无需删除
DS
at 注册表,事情将再次起作用。但是您还需要等待,尽管签名的 TTL 似乎是 1 小时或 5 分钟,但要等待的时间要少得多:除了关于上述内容的有用说明:
+dnssec
查看RRSIG
记录以及它们的 TTL(否则默认情况下不会显示它们,因为它们本身从来没有用......除了解决 DNSSEC 相关问题)+cd
哪个是请求不进行 DNSSEC 验证的标志,否则这些查询可能会SERVFAIL
因为 DNSSEC 配置被破坏而返回。+cd
是dig
DNSSEC 最重要的标志:“在没有它的情况下进行查询,SERVFAIL
然后用它重做相同的查询并获得回复”意味着在 99.999% 的情况下,您的问题仅与您域上的 DNSSEC 配置有关。