如何解决将域转移到 Route 53 或其他 DNS 托管提供商后遇到的 DNS 传播问题？

简短描述

当您将域转移到 Amazon Route 53 时，以下问题可能会导致域解析暂时中断：

• 名称服务器更新延迟
• 缓存的 DNS 记录
• DNS 记录配置不正确
• 域名系统安全扩展 (DNSSEC) 配置不正确
• 注册商级别的块

解决方法

**重要事项：**转移域时请遵循以下最佳实践：

• 在低流量时段规划您的域转移。
• 在转移域前几天，将生存时间 (TTL) 值降低到 60 秒或更短。
• 在过渡期间，保持新旧 DNS 记录处于活动状态。
• 在转移域之前，请先停用 DNSSEC。然后，在成功转移域后重新启用 DNSSEC。

解决由于名称服务器更新延迟而导致的域解析故障

如果您的域无法解析并显示来自旧 DNS 区域的授权起始记录，则说明出现以下问题之一：

• 您尚未在注册商级别更新名称服务器。
• 本地解析器缓存过时的名称服务器。

运行 dig 命令以查看您的域名服务器、DNS 解析和记录配置：

dig web.example-url.com

**注意：**将 example-url 替换为您的 URL。

在以下输出示例中，由于域名信息不存在于正确的名称服务器中，域出现解析失败：

; <<>> DiG 9.18.33 <<>> web.example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59604  
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;web.example.com.               IN      A  

;; AUTHORITY SECTION:  
example.com.            900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

确认您的域注册商的名称服务器与新 DNS 提供商或 Route 53 的名称服务器相匹配。然后，等到旧名称服务器的 TTL 值到期，更改才会生效。如果问题仍然存在，请刷新本地 DNS 解析器上的 DNS。

**注意：**要检查域名的 DNS 解析和记录配置，您还可以使用 nslookup 命令。

解决 DNS 记录缓存域解析不一致的问题

如果您的本地计算机或互联网服务提供商的 DNS 解析器缓存过期的 DNS 信息，则用户在不同的网络和位置对您的域的访问权限不一致。

运行 dig 命令以查看您的域名服务器，然后查看本地级别或本地解析器级别的缓存输出。以下输出示例包含过时的 DNS 信息：

; <<>> DiG 9.18.33 <<>> example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56173  
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;example.com.                   IN      A  

;; ANSWER SECTION:  
example.com.            300     IN      A       1.1.1.1  
example.com.            300     IN      A       2.2.2.2

如果您发现过时的 DNS 信息，请清除本地 DNS 缓存。然后，测试来自不同网络的域访问权限，以验证更改是否生效。

**注意：**最佳做法是在转移 DNS 服务之前将名称服务器的 TTL 值降低到 60 秒。

对由于 DNS 记录配置不正确导致的域功能不全问题进行故障排除

如果您的 DNS 记录转移不完整或不正确，则会遇到域功能不全的情况，例如网站加载但电子邮件服务出现故障。

运行 dig 命令以对您的 DNS 记录配置进行故障排除。

记录类型 A

命令示例：

dig example.com A

输出示例：

; <<>> DiG 9.18.33 <<>> example.com  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56173  
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;example.com.                   IN      A  

;; ANSWER SECTION:  
example.com.            300     IN      A       1.1.1.1  
example.com.            300     IN      A       2.2.2.2

记录类型 MX

命令示例：

dig web.example.com MX

输出示例：

; <<>> DiG 9.18.33 <<>> web.example.com MX  
;; global options: +cmd  
;; Got answer:  
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59604  
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1  

;; OPT PSEUDOSECTION:  
; EDNS: version: 0, flags:; udp: 4096  
;; QUESTION SECTION:  
;web.example.com.               IN      MX  

;; AUTHORITY SECTION:  
example.com.            900     IN      SOA     ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

前面的示例输出显示类型 A 记录已配置但缺少 MX 记录。缺失的 MX 记录显示 DNS 迁移期间发生了 DNS 记录配置错误。

查看您之前的 DNS 配置和在 Route 53 中的设置。验证您是否已在新 DNS 提供商的系统中正确配置以下记录：

• A
• CNAME
• MX
• TXT

然后，等待 24 到 48 小时，让 DNS 更改生效。

排查由于 DNSSEC 设置不正确导致的完全解析故障

当您将域转移出使用 DNSSEC 的环境时，可能会遇到域解析失败的情况。验证您是否已在新环境中正确配置 DNSSEC。

如果问题仍然存在，请通过您的注册商和在 DNS 提供商级别停用 DNSSEC。然后，确保您的新域注册商支持 DNSSEC，然后在新环境中启用 DNSSEC。

对被阻止的域进行故障排除

运行 whois 命令以检查域的注册状态：

whois example-url.com

**注意：**将 example-url.com 替换为您的 URL。

如果输出显示您的域的状态为 clientHold 或 serverHold，则管理员已在注册商级别阻止您的域。

输出示例：

   Domain Name: EXAMPLE-URL.COM  
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited  
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited  
   Domain Status: clientHold https://icann.org/epp#clientHold  
   Domain Status: serverHold https://icann.org/epp#serverHold

要解除阻止您的域，请联系您的管理员。

相关信息

将 Amazon Route 53 设置为现有域的 DNS 服务