AWS Route 53下DNS验证SSL证书失败求助

针对你遇到的www.congresscritters.org DNS验证失败问题，结合ACM和CloudFormation的常见坑，按以下步骤排查：

1. 核对DNS验证记录的准确性 #

• 登录ACM控制台，查看该证书的域名验证详情，复制要求的CNAME记录（主机名、目标值）
• 登录Route53控制台，找到对应托管区，检查自动创建的CNAME记录是否与ACM要求完全一致：
  • 主机名必须包含前缀（如_abc123.www.congresscritters.org），不能遗漏下划线或拼写错误
  • 目标值必须是ACM提供的完整域名（如_def456.acm-validations.aws.），注意末尾的点号
• 用dig或nslookup工具在公网环境查询该CNAME记录，确认已正确解析到目标值（避免Route53内部同步但公网未生效的情况）

2. 确认域名托管归属 #

• 如果www.congresscritters.org的DNS托管不在AWS Route53，CloudFormation无法自动添加验证记录，需手动将ACM提供的CNAME记录添加到第三方DNS服务商的管理后台
• 手动添加后需等待DNS缓存过期（根据记录TTL设置，通常1-10分钟），再刷新ACM验证状态

3. 检查CloudFormation资源依赖与引用 #

• 确保Certificate资源在Route53 RecordSet资源之前创建，可通过DependsOn属性明确依赖关系
• 验证RecordSet的属性引用是否正确：
  • 若证书包含多个域名，确认!GetAtt Certificate.DomainValidationOptions[N].ResourceRecordValue中的索引N对应www.congresscritters.org的条目
  • 检查HostedZoneId是否为www.congresscritters.org对应的托管区ID（而非根域的托管区）

4. 排查通配符证书的验证逻辑 #

• 如果你的证书包含通配符*.congresscritters.org，注意通配符域名的验证记录是针对根域的（如_abc123.congresscritters.org），而非www子域
• 若你错误地为www子域单独创建了验证记录，会导致验证失败，需删除多余记录并等待ACM重新验证

5. 检查IAM权限与资源状态 #

• 确认执行CloudFormation的IAM角色拥有route53:ChangeResourceRecordSets权限，否则验证记录可能未实际创建
• 在CloudFormation控制台查看Certificate和RecordSet资源的事件日志，排查是否有创建失败或警告信息

6. 等待DNS传播与重试验证 #

• DNS记录的公网传播可能存在延迟，即使Route53显示记录已部署，部分地区的DNS缓存仍可能保留旧数据
• 可在ACM控制台手动触发重新验证（选择证书 -> 操作 -> 重新验证域名），等待15-30分钟后查看状态

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