每次海外业务拓展，前端团队总会收到北美和欧洲用户的吐槽，说我们的 H5 页面首次加载慢如乌龟，经常卡在白屏转圈 2 秒以上。一开始以为是 CDN 或者源站性能差，结果用拨测工具做网络链路分析，发现域名解析（DNS Lookup）这一步居然就耗费了整整 1.8 秒。原来，我们把域名的权威解析服务器（NS）直接留在了国内某家单点 DNS 厂商。海外用户解析个域名，查询请求居然得跨洋跑回国内来拿结果，这不卡死才怪。

要搞定这个瓶颈，必须要引入 DNS Anycast（任播）路由和全球分区解析（GeoDNS）。Anycast 技术能让全球数以百计的 DNS 边缘节点共享同一个 IP 地址。当北美用户查询我们的域名时，BGP 路由会自动将请求导向距离该用户最近的北美 Anycast 节点（比如洛杉矶或西雅图），直接将解析延迟压缩到 30ms 以内。

为了在保留国内原有解析链路的同时最大化提升海外速度，我们采取了“分流解析”方案：国内用户继续走阿里云 DNS/DNSPod，海外用户全量切到 AWS Route 53，并结合 Terraform 进行多区域延迟路由配置。

下面是我们的 Route 53 延迟路由（Latency-based Routing）核心 Terraform 配置文件：

# 定义 AWS Route 53 托管区
resource "aws_route53_zone" "primary" {
  name = "example.com"
}

# 针对北美东部（弗吉尼亚）用户的延迟路由记录
resource "aws_route53_record" "api_us_east" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "api.example.com"
  type    = "CNAME"
  ttl     = "300"

  # 延迟路由特有配置
  latency_routing_policy {
    region = "us-east-1"
  }

  set_identifier = "us-east-cdn"
  records        = ["us-east-cdn.example-cdn.com"]
}

# 针对欧洲（爱尔兰）用户的延迟路由记录
resource "aws_route53_record" "api_eu_west" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "api.example.com"
  type    = "CNAME"
  ttl     = "300"

  latency_routing_policy {
    region = "eu-west-1"
  }

  set_identifier = "eu-west-cdn"
  records        = ["eu-west-cdn.example-cdn.com"]
}

# 针对亚太（新加坡）用户的延迟路由记录
resource "aws_route53_record" "api_ap_southeast" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "api.example.com"
  type    = "CNAME"
  ttl     = "300"

  latency_routing_policy {
    region = "ap-southeast-1"
  }

  set_identifier = "ap-southeast-cdn"
  records        = ["ap-southeast-cdn.example-cdn.com"]
}

配置完毕后，我们可以在终端使用 dig 命令指定海外的 DNS 节点进行追踪和压测，确认 Anycast 是否生效：

# 模拟海外本地 DNS 递归服务器，直接向 AWS 权威 NS 发送查询
dig @ns-2048.awsdns-64.com api.example.com +trace

# 使用 WebPageTest 拨测工具检查全球各地解析耗时
# 优化前：伦敦（1920ms）、纽约（1740ms）、新加坡（1210ms）
# 优化后：伦敦（22ms）、纽约（18ms）、新加坡（15ms）

另一个常踩的坑是 TTL（Time-To-Live，生存时间）的设置。很多运维为了省事把 TTL 设得极大（比如 86400 秒，即整整 1 天）。这虽然能减少解析请求数，但是一旦 CDN 节点被 DDoS 攻击需要紧急切 CNAME 或者 IP 漂移，你就得干等 24 小时才能生效，直接造成毁灭性故障。

我们目前的推荐实践是：对于极少变动的 A/CNAME 记录，TTL 设为 300 秒（5分钟）；而对于临时切换或者灰度中的 API 域名，干脆直接压到 60 秒。这样既享受到了 Anycast 带来的超低首包建连耗时，又保留了灾备兜底的快速响应能力。

各位在做全球多机房容灾时，如果遇到权威 DNS 宕机（如几年前 DynDNS 被 DDoS 导致半个互联网瘫痪），除了双 NS 厂商混用，还有什么更优雅的自动切换方案吗？