Route53域名无法关联CloudFront静态站点的DNS解析问题

我将Next.js静态站点托管在S3上并通过CloudFront分发，CloudFront URL可正常访问，但关联Route53注册的域名（原在BlueHost创建后转入AWS）时出现DNS解析问题：

1. 执行dig NS <my-domain>返回SERVFAIL，无法获取域名服务器信息
2. 浏览器访问域名显示ERR_NAME_NOT_RESOLVED

当前配置 #

• CloudFront：已设置备用域名www.<my-domain>.com和<my-domain>.com，绑定已验证的ACM证书，开启IPv6
• Route53托管区域：配置了www和主域名的A/AAAA别名记录指向CloudFront；尝试修改NS记录匹配注册域名页面的域名服务器，但托管区域详情显示的域名服务器与NS记录、注册页面均不一致
• Route53注册域名：状态码为clientDeleteProhibited、clientTransferProhibited、clientUpdateProhibited
• ACM：已成功申请并通过邮件验证证书，包含<my-domain>.com和*.<my-domain>.com，已关联CloudFront，状态为“Issued”

已尝试操作 #

• 更新Route53托管区域的NS记录，使其匹配注册域名页面的域名服务器
• 尝试更新注册域名的域名服务器，使其匹配托管区域的域名服务器，但操作失败

请问还有哪些遗漏的配置导致DNS无法解析？

1. 修正域名服务器的关联逻辑 #

Route53的核心规则是：注册域名的域名服务器必须指向托管区域的NS地址，而非反向操作：

• 打开Route53托管区域，复制详情页顶部的4个（或更多）官方NS地址
• 进入Route53「注册域名」页面，找到目标域名，点击「管理域名服务器」，替换为托管区域的NS地址

若修改域名服务器操作失败，先解除clientUpdateProhibited限制：在注册域名的「域名状态」中，点击「编辑」，取消勾选该状态码，保存后再重试修改。

2. 恢复托管区域的默认NS记录 #

不要手动修改托管区域内的NS记录，若之前改动过：

• 进入托管区域页面，点击「恢复默认NS记录」，将其还原为托管区域详情页显示的官方NS地址，确保托管区域内的NS记录与自身NS地址完全一致。

3. 验证DNS传播状态 #

修改域名服务器后，DNS全球传播需要1-24小时，可通过以下方式验证：

• 执行dig NS <my-domain> @8.8.8.8（用公共DNS查询），确认是否返回托管区域的NS地址
• 用nslookup -type=NS <my-domain>检查本地解析结果
• 查看全球DNS节点的解析状态，确认传播进度

4. 检查托管区域基础配置 #

• 确认创建的是公共托管区域，而非私有托管区域
• 托管区域的域名必须与注册域名完全匹配（比如<my-domain>.com不能多/少后缀）

5. 排查SERVFAIL的深层原因 #

SERVFAIL通常指向权威DNS响应异常，需额外检查：

• 核对托管区域NS地址的拼写，确保无输入错误
• 检查域名是否过期，过期会直接导致解析失败
• 若原BlueHost配置过DNSSEC，转入AWS后需在Route53中重新配置或关闭，否则会引发解析冲突

内容的提问来源于stack exchange，提问作者Brock L