本指南教你如何把 DNS 解析速度从行业平均的两百毫秒降到三十毫秒以内，并通过 GeoDNS（基于地理位置的智能解析）把不同地区的用户解析到最近的源站。很多团队优化网站时把注意力放在 TLS 握手和 CDN 命中率上，却忽略了一个事实：浏览器在发起任何 HTTP 请求之前，都要先做一次 DNS 解析。这一步如果走的是境外权威服务器，等于在用户首屏前面凭空塞进一次跨洋往返。本文会从 TTL 设置、Anycast 部署、解析延迟监控到 GeoDNS 分流策略逐步展开，帮助你为全球用户提供稳定的首字节时间。
DNS 解析慢在哪里
一次完整的 DNS 查询要经过四级：浏览器缓存、操作系统缓存、本地递归（运营商或公共 DNS）、权威服务器。如果前三级都没命中，最后一步去查权威，耗时主要取决于：
- 权威服务器的物理位置：在美国西海岸的权威，国内用户解析要走两百毫秒以上
- 是否启用 Anycast：单点权威遇到节点故障会触发递归重试，雪上加霜
- 域名层级：每多一级子域，递归就多一次迭代查询
- DNSSEC：开启后响应体变大，UDP 截断回退到 TCP 还会再多一次握手
理解这条链路就知道，光把 TTL 调长是不够的——TTL 解决的是重复查询，不解决首次查询。
TTL 的取舍
很多人把 TTL 设成 60 秒以为”灵活切换”，结果递归服务器每分钟都要回源一次，权威负载暴涨且用户体验更差。合理的做法是分类处理：
- 主域 A 记录：300-600 秒，需要灰度切流时再临时降低
- CNAME 指向 CDN：跟随 CDN 厂商建议，一般 60-300 秒
- MX、TXT、SPF：3600 秒以上，几乎不变
- 临时验证用 TXT：低 TTL（60-120 秒），用完立刻删
切流前的操作建议：提前 24 小时把 TTL 从 600 降到 60，等递归缓存全部刷新后再做 DNS 切换，切完立刻把 TTL 调回去。这样既能快速回滚，又不会长期承担短 TTL 的负载代价。
Anycast 与多权威部署
单台权威服务器的延迟取决于物理距离，再优化也有下限。Anycast 是把同一个 IP 宣告到多个地理节点，让用户的递归请求被路由到最近的节点。常见的公共 DNS（Cloudflare 1.1.1.1、Google 8.8.8.8）都是基于 Anycast。
自己跑权威的话，要么用支持 Anycast 的托管服务（Cloudflare、AWS Route 53、NS1），要么在不同地区部署两到四台 BIND，通过 NS 记录分流。多权威要注意：
- 各权威之间用 AXFR/IXFR 同步，主备模型要明确
- NS 记录顺序对递归选择有微弱影响，但不能依赖
- 监控每个权威的解析成功率，一旦掉线立刻从 NS 列表里摘掉
- 同一个 zone 在不同权威上的版本要一致，序列号要同步
如果只服务国内用户，常见的简化做法是直接接入支持 BGP Anycast 的国内 DNS 厂商。涉及跨境分流时，建议参考 Cloudflare CDN 中国加速 中关于 Anycast 节点覆盖与境内回源的章节。
GeoDNS 智能解析
GeoDNS 的核心是同一个域名，针对不同来源 IP 返回不同的 A 记录。典型的分流策略有三种：
- 按大陆/国家：欧洲解析到法兰克福、北美解析到弗吉尼亚、亚洲解析到东京
- 按运营商：国内电信解析到电信源站、联通解析到联通源站
- 按延迟探测：实时测量每个候选源站到递归 DNS 的 RTT，挑最低的返回
第三种最准确但实现复杂，只有少数厂商（NS1、DNSPod 企业版）支持。前两种基于 GeoIP 数据库即可，需要注意 GeoIP 库的更新频率——一年不更新的库准确率会掉到 80% 以下。
落地时建议先用按大陆分流跑两周，对比每个地区的首字节时间，再决定是否细化到运营商。
监控解析延迟
没有数据就没办法优化。建议至少跑三层监控：
- 真实用户监控（RUM）：通过 navigation.timing API 收集 domainLookupEnd – domainLookupStart
- 主动探测：用 dig 在国内外多个节点定时查询，记录响应时间
- 权威侧日志：开启查询日志，统计每个 zone 的 QPS 与响应分布
把这三组数据对齐到同一时间轴，就能看出问题是出在权威、递归还是客户端。如果你的入口前面挂了反向代理，可以一并把 DNS 解析时间纳入 Nginx 的访问日志，配置方法可以看 Nginx 反向代理与负载均衡实战 中关于 $upstream_response_time 的扩展用法。
部署一台自建权威：BIND 简化示例
如果业务规模需要自建权威，最小可用配置就是一台 BIND9。zone 文件结构是：
$TTL 600
@ IN SOA ns1.example.com. admin.example.com. (
2026051701 ; serial
3600 ; refresh
600 ; retry
604800 ; expire
300 ) ; minimum
IN NS ns1.example.com.
IN NS ns2.example.com.
@ IN A 203.0.113.10
www IN A 203.0.113.10
每次改记录都要手动加 serial 号，否则从节点不会拉新版本。生产环境推荐用 PowerDNS + MySQL 后端，方便接 GeoDNS 插件与自动化。
服务器面向公网后，记得做 SSH 与防火墙加固，把 53 端口只对必要源开放。基础的 SSH 与 Fail2ban 加固 模板可以直接套用，再叠加一份 BIND 专属的 ACL 限制查询源。WordPress 等应用层的配置可以参考 WordPress 与 W3 Total Cache 调优 把页面缓存层一并打通。
常见踩坑
- TTL 长期设 60 秒，权威被打爆、递归命中率极低
- GeoIP 库一年不更新，国内 IP 段变化大，分流准确率掉到 70% 以下
- 自建权威没开 Anycast 也没做多地区部署，单点故障影响全站
- DNSSEC 开了但没在递归端测试过，UDP 截断导致部分用户解析失败
- 切流前没提前降 TTL，结果回滚要等几小时才生效
总结
DNS 优化不是某一个开关，而是 TTL 策略、权威部署和监控三件事的组合。建议先把现有解析延迟摸清楚，从 RUM 数据看 P95 与 P99 在不同地区的差异，再决定是上 Anycast、加 GeoDNS 还是只改 TTL。如果你需要给跨境业务做加速，可以考虑把权威托管到全球 Anycast 服务商，源站层面再用 GeoDNS 分流到最近的机房。整体下来你会发现，DNS 这层的优化收益往往被低估，但它是用户体验链路上最早的那一环——前面快一百毫秒，后面所有指标都会跟着好看。