我们公司将 .com 域名转移到其他域名提供商。这 14 天运行良好，但今天我们的域名被暂停了，因为我们的邮件提供商出了问题，没有收到验证所有者地址的邮件。
经过一段时间，我们设法修复了邮件问题并验证了域名。在使用 Google/Cloudflare/… DNS 时，我们的应用程序也能按预期运行。然而，我们的许多客户在近 12 小时后仍然无法访问我们的应用程序。
与此同时，我们可以找出一个可能的原因。我们怀疑是某些互联网提供商的 DNS 缓存。请参阅nslookup请求应用程序子域的 SOA 条目的输出。
使用 Google DNS（8.8.8.8），app.EXAMPLE.com 的 SOA 条目来自我们的域 EXAMPLE.com。
> server 8.8.8.8
Default Server: dns.google
Address: 8.8.8.8
> set type=soa
> set d2
> app.EXAMPLE.com
Server: dns.google
Address: 8.8.8.8
------------
SendRequest(), len 34
HEADER:
opcode = QUERY, id = 25, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
app.EXAMPLE.com, type = SOA, class = IN
------------
------------
Got answer (99 bytes):
HEADER:
opcode = QUERY, id = 25, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
app.EXAMPLE.com, type = SOA, class = IN
AUTHORITY RECORDS:
-> EXAMPLE.com
type = SOA, class = IN, dlen = 53
ttl = 1800 (30 mins)
primary name server = ns1.DOMAINPROVIDER.de
responsible mail addr = postmaster.DOMAINPROVIDER.de
serial = 2024091603
refresh = 86400 (1 day)
retry = 10800 (3 hours)
expire = 3600000 (41 days 16 hours)
default TTL = 3600 (1 hour)
------------
EXAMPLE.com
type = SOA, class = IN, dlen = 53
ttl = 1800 (30 mins)
primary name server = ns1.DOMAINPROVIDER.de
responsible mail addr = postmaster.DOMAINPROVIDER.de
serial = 2024091603
refresh = 86400 (1 day)
retry = 10800 (3 hours)
expire = 3600000 (41 days 16 hours)
default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server: dns.google
Address: 8.8.8.8
------------
[...]
------------
Non-authoritative answer:
Name: app.EXAMPLE.com
Address: <IP ADDRESS OF OUR SERVER>
当使用我们的互联网提供商的 DNS 服务器时，我们会得到完全不同的子域名结果。
> set type=soa
> set d2
> app.EXAMPLE.com
Server: <DNS OF INTERNET PROVIDER>
Address: <DNS OF INTERNET PROVIDER>
------------
SendRequest(), len 34
HEADER:
opcode = QUERY, id = 28, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
app.EXAMPLE.com, type = SOA, class = IN
------------
------------
Got answer (107 bytes):
HEADER:
opcode = QUERY, id = 28, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
app.EXAMPLE.com, type = SOA, class = IN
ANSWERS:
-> app.EXAMPLE.com
type = SOA, class = IN, dlen = 61
ttl = 2335 (38 mins 55 secs)
primary name server = ns1.emailverification.info
responsible mail addr = hostmaster.emailverification.info
serial = 2024090700
refresh = 7200 (2 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
------------
Non-authoritative answer:
app.EXAMPLE.com
type = SOA, class = IN, dlen = 61
ttl = 2335 (38 mins 55 secs)
primary name server = ns1.emailverification.info
responsible mail addr = hostmaster.emailverification.info
serial = 2024090700
refresh = 7200 (2 hours)
retry = 3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
> set type=A
> app.EXAMPLE.com
Server: <DNS OF INTERNET PROVIDER>
Address: <DNS OF INTERNET PROVIDER>
------------
[...]
------------
Non-authoritative answer:
Name: app.EXAMPLE.com
Address: <WRONG IP ADDRESS>
我的问题是：一段时间后这个问题会自动解决吗？还是我们需要采取一些措施？是否可以加快这一进程？
最佳答案
1
运行dnstracer -s . app.example.com以验证（未缓存的）委派信息是否正确。这将检查域注册表是否具有您域的正确 NS 记录，以及您的域是否具有“app”子域的正确 NS 记录。（由于它有自己的 SOA，这意味着它是从主域委派的单独区域。）
或者使用nslookup -d -q=NS example.com a.gtld-servers.net（这是 .com 名称服务器之一），然后针对主域的名称服务器对 app.example.com 执行类似的查询。
TLD 的 NS 委派记录缓存 TTL 通常稍长一些，有时长达 24 小时（“24-48 小时传播”可能由此而来），因此您的 ISP 解析器可能不仅缓存了错误的 A 和 SOA 记录，还缓存了错误的 NS 委派记录，并且将继续查询错误的名称服务器，直到这些记录过期。
您唯一能做的就是验证所有名称服务器中的权威数据是否正确。
3
-
谢谢。使用 dnstracer 时，我得到了
A.ROOT-SERVERS.NET [.] (2001:0503:ba3e:0000:0000:0000:0002:0030) send_data/sendto: Network is unreachable。使用 nslookup 时，答案对我来说看起来不错。需要澄清的是，我们通常不会为子域设置单独的 SOA。这是我们在验证过程中遇到问题后出现的意外行为。
– -
然后重新运行 dnstracer
-4。如果权威服务器具有从 .com 到 .example.com 的正确委派，则剩下要做的就是等待。（在 nslookup -q=NS 输出中找到 TTL 以获取有关您可能需要等待多长时间的提示。）
–
-
看来传播已经发挥了魔力，我们的大多数用户都可以再次访问。感谢您的帮助。
–
|
|