亚马逊云支付验证 亚马逊云 AWS 账号 DNS 解析设置

别再让 DNS 成为你的深夜噩梦：AWS 账号 DNS 解析设置实战指南

凌晨两点，你盯着控制台里那个飘红的 www.example.com，心里默念三遍「它刚才还好好的」；运维同事甩来一句「DNS 没配对」，你翻出三个月前的工单记录，发现上次改 NS 记录时顺手把 TTL 设成了 86400——然后默默关掉浏览器，泡了杯速溶咖啡，心想：这玩意儿真比教猫用猫砂还难？

别慌。今天不画大饼、不堆术语、不甩官方文档截图。咱们就当坐在工位隔壁，一杯冰美式还没凉透，我边敲键盘边跟你唠：怎么在 AWS 里把 DNS 这摊事儿，理得像整理抽屉一样清爽。

第一步：先搞清你到底在管谁家的 DNS

AWS 里最常被踩坑的，就是分不清「域名在哪注册」和「DNS 在哪解析」。这两件事可以是同一家，也可以隔了八百里——比如你在 GoDaddy 买的域名，却想用 Route 53 来管解析；或者你在 Route 53 注册了域名，但把 DNS 托管给了 Cloudflare。别急着点控制台，先掏出纸笔（或新建个记事本）写下两行：

• 域名注册商：你交钱买下 myapp.dev 的地方（GoDaddy / Namecheap / AWS Route 53 自己）
• DNS 托管服务：真正负责把 api.myapp.dev → 192.0.2.42 翻译出来的服务（Route 53 / Cloudflare / 自建 BIND）

只有这两者对齐了，DNS 才算真正“上线”。举个反面例子：你在 Route 53 注册了域名，却没把它的 NS 记录填回 Route 53 自己的托管区——结果？全世界都查不到你，连你自己 ping 都超时。不是服务器挂了，是压根没人知道该去哪问。

第二步：Route 53 托管区 —— 你的 DNS 私人书房

进了 Route 53 控制台，第一眼看到的是「托管区域」（Hosted Zone）。别被名字唬住，它就是你给域名建的一间独立书房：书架（记录集）、借阅规则（TTL）、访客登记簿（查询日志可选）。创建时注意两个关键选项：

• 公有托管区域：对外提供解析，比如用户访问你的官网
• 私有托管区域：仅限 VPC 内部使用，比如 db.internal 只让 EC2 实例知道

新手常犯的错：建完托管区就以为万事大吉。其实这才刚把门框立好。下一步，你得亲手把 NS 记录抄到注册商后台——没错，就是那四行以 ns-xxx.awsdns-xx.net 开头的地址。漏掉任意一行？相当于只装了三颗螺丝就宣布门已安好。建议截图、存笔记、发钉钉置顶——别信记忆，信截图。

第三步：A 记录、CNAME、别名记录？别背概念，看场景

添加记录时，界面弹出一堆类型，头晕？记住三句话：

• A 记录：直接指向 IPv4 地址。适合你有固定公网 IP 的 EC2 或 NAT 网关（但不推荐长期用，IP 可能变）
• CNAME：指向另一个域名。比如 blog.myapp.dev → ghost-blog.s3-website-us-east-1.amazonaws.com。但注意：根域名（myapp.dev）不能设 CNAME！RFC 规定，根域必须用 A 或 AAAA
• 别名记录（Alias）：Route 53 特供，长得像 CNAME，但免费、支持根域、自动适配后端服务变更。比如指向 CloudFront 分发、ELB、S3 静态网站、API Gateway——这才是 AWS 生态里的“正确打开方式”

实操小技巧：想让 myapp.dev 和 www.myapp.dev 都生效？别傻傻建两个 A 记录。建一个别名指向 CloudFront，再建一个别名（或 301 重定向）把根域跳转到 www——干净利落，还能省下 HTTPS 证书重复申请的麻烦。

第四步：健康检查 + 故障转移？不是高可用，是“会呼吸”的 DNS

你以为加个负载均衡就高可用？错。真正的弹性，在于 DNS 层就能感知后端生死。Route 53 健康检查就像给每个终端装了个心跳探针：每 10–30 秒发一次 HTTP/HTTPS/TCP 请求，连续失败三次就自动剔除该记录。

搭配「故障转移路由策略」，你可以这样玩：

• 主站点（us-east-1）健康 → 全量流量走它
• 主站挂了 → 自动切到备用区（ap-northeast-1）的镜像站点
• 备用区也挂了？再 fallback 到 S3 静态维护页

注意：健康检查 URL 别写 /healthz 就完事。它得真实反映业务状态——比如调用数据库连接池、校验缓存命中率。否则，API 网关活着但下游 Redis 炸了，DNS 还傻乎乎导流过去，那就不是高可用，是精准投毒。

第五步：那些让你重启三次路由器的坑

最后，送你一份「血泪排错清单」，按优先级排列：

1. NS 记录没同步：注册商后台填错了、少填了一行、多加了空格——用 dig NS myapp.dev 对比返回的 NS 和 Route 53 托管区里列出的是否完全一致
2. TTL 设太高：改完记录等半天不生效？立刻去托管区把 TTL 改成 60 秒（测试期），验证无误再调回 300 或 3600
3. HTTPS 重定向打架
4. 私有托管区没关联 VPC：EC2 查不到 redis.local？进托管区看「关联的 VPC」列表，确保目标 VPC 已勾选且路由表允许 DNS 流量
5. CloudFront 分发状态不是 'Deployed'：别信控制台右上角的小绿点，点进去看「Distribution status」字段，必须是 Deployed 才能被别名记录引用