dns

DNS

DNS 是全球服务的入口：它会将名称（api.example.com）转换为地址，而且发生在任何请求到达你的服务器之前。它也是一个路由层——同一次查询可以向不同客户端返回不同答案（按区域、延迟、健康状况或权重）。如果配置有误，客户端可能会到达不可用的区域，故障转移可能要几分钟而不是几秒，或者错误答案可能被缓存数小时。DNS 既不是负载均衡器，也不是 CDN；它决定告知客户端使用哪个端点，而不是如何在该端点内部均衡流量。

适用场景

服务可通过稳定的主机名访问；流量必须导向最近或最健康的区域／数据中心；或者端点的 IP 可能会变化（例如更换负载均衡器或切换到故障转移站点），且客户端必须无需修改代码即可跟随变化。多区域或多数据中心设计需要 DNS 来选择入口点；单区域设计仍需要 DNS 来提供稳定且可迁移的名称。

不适用场景

单一区域内的路由——这是负载均衡器的工作（→ load-balancing），它能在毫秒内响应，而不是受 TTL 限制、需要几分钟。精细到每个请求或感知会话的流量调度——DNS 按查询返回答案，之后由客户端缓存。需要亚秒级恢复的快速故障转移——DNS 故障转移受 TTL 和解析器缓存限制；不要承诺仅通过名称层实现即时切换。而且，在数据表明用户分布在多个区域之前，不要急于采用复杂的路由策略（YAGNI）——单区域的默认正确选择是单条 A/ALIAS 记录。

先明确需求

• 地理分布——一个区域还是多个区域？用户在哪里？（→ requirements-scoping）
• 故障转移目标——失去某个区域时的恢复时间目标是多少：几秒，还是“几分钟也可以”？
• 端点的动态程度——IP 固定，还是会变化的 LB 主机名？（决定使用 A 还是 CNAME/ALIAS）
• 流量调度目标——按延迟就近、按用户地理位置、按权重（金丝雀/A-B），还是仅轮询？
• 对映射陈旧的容忍度——客户端可以保留过期答案多久？（决定 TTL → back-of-the-envelope）

可选方案

记录类型（名称返回什么）

• A / AAAA——名称 → IPv4 / IPv6。端点具有稳定 IP 时使用。
• CNAME——名称 → 另一个名称。用于别名指向服务提供商的主机名；不能用于区域顶点（example.com）。
• ALIAS / ANAME（因服务提供商而异）——区域顶点别名指向主机名。用于让 example.com 指向 LB/CDN 主机名。
• NS / MX / TXT——用于委派、邮件和验证。按域名需要使用；不用于流量调度。

路由策略（客户端会获得哪个答案）

• 简单——所有人都获得同一个答案。适用于单个端点。
• 加权——按百分比分流。适用于金丝雀发布、A/B 测试，或在集群之间迁移流量。
• 基于延迟——返回到解析器测得延迟最低的区域。用于尽量缩短往返时间。
• 地理位置 / GeoDNS——根据客户端的位置返回答案（数据驻留、本地化内容）。必须由地理位置而非延迟决定时使用。
• 故障转移——主端点健康时使用主端点，否则使用备用端点。适用于主备模式的灾难恢复。
• 多值——返回多个健康 IP，由客户端选择。适用于以低成本在客户端侧分散流量，并通过健康检查剔除异常端点。

可达性

• Anycast——从多个站点广播同一个 IP；网络会将流量路由到最近的站点。适用于解析器/CDN 前端和 DDoS 防护（相关概念见 content-delivery）。

权衡

选项	解决的问题	带来的问题	适用场景
简单的 A/ALIAS	简单直接；名称稳定	无法引导流量，也无法故障转移；如果 IP 不可用，就会形成单点故障（SPOF）	流量覆盖多个区域或需要灾难恢复时 → 加权/延迟/故障转移
加权	逐步调整流量、金丝雀发布、集群负载均衡	需要手动操作且速度较慢；除非配合检查，否则无法感知运行状况	需要自动选择较近的目标时 → 延迟路由；需要自动切换时 → 故障转移
基于延迟	自动为每位用户选择 RTT 最低的目标	路由依据是 解析器 所在位置，而非用户位置；需要设置每个区域的端点	数据驻留比速度更重要时 → 地理位置路由
地理位置	满足合规要求，返回本地化结果	VPN/转发解析器可能导致路由错误；地图划分较粗略	速度比地理位置更重要时 → 基于延迟的路由
故障转移	自动从主用端切换到备用端	恢复时间受 TTL 和缓存限制；冷备用存在风险	RTO 必须低于 1 秒时 → 使用区域内负载均衡器，而非 DNS
Anycast	接入最近的节点，并吸收 DDoS 攻击	运维复杂（BGP）；路由变更时可能发生抖动	只有一个站点时 → 不值得采用

压力下的行为

DNS 故障的影响会缓慢而广泛地扩散——错误的应答或权威服务器故障会影响 所有接下来进行查询的用户，并持续到 TTL 允许缓存过期为止。

• TTL 缓存会延缓恢复和传播。 解析器以及操作系统/浏览器 缓存会按 TTL 保存应答；有些 ISP 会过度缓存。故障转移或 IP 变更 只有在旧条目过期后才会生效——实际恢复时间是 TTL 加上未及时刷新的缓存，而非零。
• 权威 DNS 成为单点故障（SPOF）。 如果你的权威服务器（或单个 托管区域）宕机，即使服务器运行正常，也无法解析任何内容。 使用覆盖多个站点的 Anycast 服务提供商；也可以考虑备用 DNS 提供商。
• 健康检查风暴/抖动。 对多个端点进行激进的健康检查可能会给目标带来 过大负载；检查结果抖动则会导致应答反复变化，使客户端分散到不同目标。调整 检查间隔和失败阈值，并要求连续发生 N 次失败（→ resilience-failure 负责健康检查调优）。
• 低 TTL 带来的负载。 将 TTL 降至几秒以实现快速故障转移，会使发往权威服务器的查询 QPS 成倍增加，并在攻击期间失去缓存缓冲。
• 解析器层遭受 DDoS。 DNS 是常见的放大攻击/DDoS 目标；解析器过载会导致整个服务无法访问。

监控： 解析延迟和错误/SERVFAIL 率、每条记录的查询 QPS、 每个端点的健康检查状态、变更后的传播时间，以及各区域/应答实际接收的流量占比。

如何应用

1. 明确输入条件 — 地理分布、区域故障时的 RTO、端点稳定性、流量引导目标和映射陈旧度（参见 先明确条件）。如果只有一个区域且入口固定，只需简单记录即可——到此为止。
2. 根据权衡表选择策略 — 选择记录类型（在区域顶点使用指向 LB/CDN 主机名的 ALIAS 是常见默认方案），并根据流量引导目标选择路由策略：灰度发布用加权策略，追求速度用延迟策略，满足驻留要求用地理位置策略，主动-被动 DR 用故障转移策略。
3. 设置关键参数 — TTL（在快速故障转移与查询负载及传播之间取得平衡）、健康检查间隔和故障阈值，以及故障转移目标。提前决定辅助 DNS / anycast 方案。
4. 对选择进行压力测试 — 按照 压力下的行为 逐项检查：确认 TTL 对应的实际恢复时间可以接受、权威层不是 SPOF，并且健康检查不会抖动或引发请求风暴。
5. 用数字估算规模 — 根据选定的 TTL 估算查询 QPS，以及变更所产生的传播窗口（→ 重要数字）。
6. 选择提供商 — 默认采用通用方案；只有在用户指定云服务时才打开对应的提供商文件（参见 选择提供商）。
7. 在回答中展示权衡 — 提供 决策 | 解决的问题 | 加剧的问题 | 在……情况下更改 表格，每项选择一行（例如所选方案、存储和故障策略）；最后一列填写具体触发条件（数字或可观察信号）。然后指出最先出问题的环节。

注意事项

应该

• 将跨区域选择的流量引导放在 DNS 层，并让 LB 负责区域内的负载均衡。
• 在区域顶点使用 ALIAS/ANAME 指向 LB/CDN 主机名，这样 IP 变更时无需修改记录。
• 将路由策略与健康检查配合使用，确保故障区域不再被返回。
• 在多个站点通过 anycast 运行权威 DNS；考虑使用第二家提供商。
• 审慎设置 TTL——既要足够短以满足 RTO，也要足够长以应对负载。

不应该

• 不要指望 DNS 故障转移立即生效；其速度受 TTL 和解析器缓存限制。
• 不要在区域顶点设置 CNAME——这是无效的；应使用 ALIAS/ANAME。
• 不要依赖地理定位实现安全保护或精确定位（VPN 和转发器可能提供错误信息）。
• 不要让单个权威区域成为其他多区域设计中的 SPOF。
• 不要为了“以防万一”将所有 TTL 都降到几秒——这会成倍增加查询负载。

重要数字

需要估算的量包括：TTL，它既决定传播窗口，也决定实际故障转移时间（TTL 为 60 s 意味着最多约 60 s 以上的陈旧时间，而非立即生效）；TTL 对权威服务器产生的查询 QPS（TTL 越短 → 查询越多）；以及解析的延迟预算（增加一次往返，但大部分会被缓存隐藏）。在 back-of-the-envelope 中使用经验法则和峰值倍数计算作为依据——此处不要重复其中的表格。

接口示意

DNS 记录是一种约定：名称（api.example.com）、类型（A/AAAA/ CNAME/ALIAS）、值（IP 或目标主机名）、TTL（秒），以及可选的路由策略 + 健康检查。区域文件行示例：

api.example.com.   60   IN   A   203.0.113.10     ; latency-policy, region us-east, health-check id hc-1

对每条记录都要确定：由哪种策略来选择它、由什么健康检查来控制它，以及用什么 TTL 来限制其陈旧时间。

选择提供商

默认采用上述通用方案。如果用户指定了云服务，请阅读 references/providers/<provider>.md，了解托管服务的对应关系、 配额/限制和特定于提供商的权衡。如果该提供商没有对应文件，则采用通用方案。

图示

若要展示解析路径（客户端 → 递归解析器 → 根/TLD/ 权威服务器 → 答案），或按地理位置/延迟引导的多区域前端，请使用插件内的 architecture-diagram 技能。快速内联示意： 客户端 → 解析器 → 权威服务器（策略：延迟）→ 区域 A | 区域 B。

相关构建模块

• load-balancing — 与此互补：DNS 将流量分散到不同区域／端点，而负载均衡器（LB）则在区域内分散请求，并在毫秒级做出响应。
• content-delivery — 与此配合：CDN 通过任播和 DNS 将用户路由到边缘 POP，任播／边缘缓存的概念则归属于此。
• resilience-failure — 为此提供支持：健康检查调优、故障转移、降级模式（以及速率限制）归属于此，并且是 DNS 故障转移的前置条件。
• back-of-the-envelope — 为此提供支持：它提供 TTL／QPS／延迟计算，用于确定记录集和传播窗口的规模。
• system-design — 概念归属在编排器中：推理循环、权衡方法和十种故障模式。

参考资料

• references/deep-dive.md — 解析层级（递归与权威、根域／TLD）、完整的记录类型集合、TTL／传播的实际表现、任播机制，以及健康检查故障转移的内部机制。设计 DNS 层时请阅读此文档。
• references/providers/{generic,aws,azure,gcp}.md — 各环境的服务映射、限制和注意事项。