dns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DNS

DNS is the global front door: it turns a name (

api.example.com

) into an address before any request reaches your servers. It is also a routing layer — the same lookup can hand different clients different answers (by region, latency, health, or weight). Get it wrong and clients reach a dead region, fail over in minutes instead of seconds, or cache a bad answer for hours. It is not a load balancer and not a CDN; it decides which endpoint a client is told to use, not how bytes are balanced inside that endpoint.

DNS是全局入口：它会在请求到达服务器之前，将名称（如

api.example.com

）转换为地址。它同时也是一个路由层——同一查询可以根据区域、延迟、健康状态或权重，为不同客户端返回不同结果。如果配置错误，客户端可能会访问到失效区域，故障转移需要数分钟而非秒级完成，或者缓存错误结果长达数小时。它不是负载均衡器，也不是CDN；它决定的是客户端被引导至哪个端点，而非端点内部的流量均衡方式。

When to reach for this

适用场景

A service is reachable by a stable hostname; traffic must be steered to the closest or healthiest region/data center; or an endpoint's IP can change (a new load balancer, a failover site) and clients must follow without code changes. Multi-region or multi-data-center designs need DNS to pick the entry point; single-region designs still need it for a stable, movable name.

当服务通过稳定主机名访问、需要将流量引导至最近或最健康的区域/数据中心，或者端点IP可能发生变化（如新负载均衡器、故障转移站点）且客户端无需修改代码即可自动跟进时。多区域或多数据中心设计需要DNS来选择入口点；单区域设计同样需要它来提供稳定、可迁移的名称。

When NOT to

不适用场景

Routing inside one region — that is a load balancer's job (→

load-balancing

), which reacts in milliseconds, not TTL-bound minutes. Fine-grained per-request or session-aware steering — DNS answers per lookup, then the client caches it. Fast failover with sub-second recovery — DNS failover is gated by TTL and resolver caching; do not promise instant cutover from the name layer. And do not reach for exotic routing policies before a number shows users are spread across regions (YAGNI) — a single

ALIAS

record is the right default for one region.

单区域内的路由——这是负载均衡器的职责（→
```
load-balancing
```
），负载均衡器的响应时间以毫秒计，而非受TTL限制的分钟级。
细粒度的每请求或会话感知型引导——DNS针对每次查询返回结果，之后客户端会缓存该结果。
亚秒级恢复的快速故障转移——DNS故障转移受限于TTL和解析器缓存；不要承诺从名称层实现即时切换。
在数据显示用户分布于多个区域之前，不要使用复杂的路由策略（YAGNI原则）——单区域的默认选择应为单个
```
A
```
/
```
ALIAS
```
记录。

Clarify first

需先澄清的问题

Geographic spread — one region or many? Where are the users? (→
```
requirements-scoping
```
)
Failover target — recovery time objective for losing a region: seconds, or "a few minutes is fine"?
How dynamic is the endpoint — fixed IPs, or an LB hostname that changes? (drives
```
A
```
vs
```
CNAME
```
/
```
ALIAS
```
)
Steering goal — closest by latency, by user geography, by weight (canary/A-B), or just round-robin?
Staleness tolerance for the mapping — how long can a client keep a stale answer? (sets the TTL →
```
back-of-the-envelope
```
)

地理分布——单区域还是多区域？用户分布在哪些地区？（→
```
requirements-scoping
```
）
故障转移目标——区域失效后的恢复时间目标：秒级，还是“几分钟也可以接受”？
端点的动态性——固定IP，还是会变化的负载均衡器主机名？（决定使用
```
A
```
记录还是
```
CNAME
```
/
```
ALIAS
```
记录）
引导目标——基于延迟选择最近节点、基于用户地理位置、基于权重（金丝雀/A-B测试），还是仅轮询？
映射的陈旧容忍度——客户端可以保留陈旧结果多长时间？（设置TTL →
```
back-of-the-envelope
```
）

The options

可选方案

Record type (what the name returns)

A
/
AAAA
— name → IPv4 / IPv6. Use when the endpoint has a stable IP.
CNAME
— name → another name. Use to alias onto a provider hostname; never at the zone apex (
```
example.com
```
).
ALIAS
/
ANAME
(provider-specific) — apex alias to a hostname. Use to point
```
example.com
```
at an LB/CDN hostname.
NS
/
MX
/
TXT
— delegation, mail, verification. Use as the domain requires; not traffic steering.

Routing policy (which answer a client gets)

Simple — one answer for everyone. Use for a single endpoint.
Weighted — split by percentage. Use for canary, A/B, or shifting between clusters.
Latency-based — answer the region with lowest measured latency to the resolver. Use to minimize round-trip.
Geolocation / GeoDNS — answer by the client's location (data residency, localized content). Use when geography, not latency, must decide.
Failover — primary while healthy, else secondary. Use for active-passive DR.
Multivalue — return several healthy IPs; client picks. Use for cheap client-side spread with health pruning.

Reachability

Anycast — one IP advertised from many sites; the network routes to the nearest. Use for resolver/CDN front ends and DDoS resilience (concept lives in
```
content-delivery
```
).

记录类型（名称返回的内容）

A
/
AAAA
——名称→IPv4 / IPv6。当端点拥有稳定IP时使用。
CNAME
——名称→另一个名称。用于将别名指向服务商主机名；切勿在区域顶点（
```
example.com
```
）使用。
ALIAS
/
ANAME
（服务商特定）——区域顶点别名指向主机名。用于将
```
example.com
```
指向负载均衡器/CDN主机名。
NS
/
MX
/
TXT
——委托、邮件、验证。根据域名需求使用；不用于流量引导。

路由策略（客户端获得的结果）

简单路由——为所有客户端返回同一结果。用于单个端点。
加权路由——按百分比分配流量。用于金丝雀测试、A-B测试或集群间流量迁移。
基于延迟的路由——返回对解析器而言延迟最低的区域结果。用于最小化往返时间。
地理定位 / GeoDNS——根据客户端地理位置返回结果（数据驻留、本地化内容）。当地理位置而非延迟是决定因素时使用。
故障转移路由——主节点健康时返回主节点，否则返回备节点。用于主备灾备场景。
多值路由——返回多个健康IP；由客户端选择。用于低成本的客户端侧流量分散，并自动剔除不健康节点。

可达性

Anycast——单个IP从多个站点广播；网络将流量路由至最近站点。用于解析器/CDN前端和DDoS防护（该概念归属于
```
content-delivery
```
）。

Trade-offs

权衡对比

Option	What it solves	What it worsens	Change it when
Simple `A` / `ALIAS`	Trivial; one stable name	No steering, no failover; SPOF if the IP dies	Traffic spans regions or needs DR → weighted/latency/failover
Weighted	Gradual shifts, canary, cluster balancing	Manual/slow; not health-aware unless paired with checks	You need automatic closeness → latency; or automatic cutover → failover
Latency-based	Lowest RTT per user automatically	Routes to resolver location, not user; needs per-region endpoints	Data residency matters more than speed → geolocation
Geolocation	Compliance, localized answers	Misroutes via VPN/forwarding resolvers; coarse map	Speed matters more than geography → latency-based
Failover	Automatic active-passive cutover	Recovery bounded by TTL + caching; cold standby risk	RTO must be sub-second → in-region LB, not DNS
Anycast	Nearest entry + absorbs DDoS	Operationally heavy (BGP); flap on route changes	You only have one site → not worth it

选项	解决的问题	带来的弊端	何时更换
简单 `A` / `ALIAS` 记录	配置简单；提供单个稳定名称	无引导能力、无故障转移；IP失效时成为单点故障	流量跨区域或需要灾备→加权/延迟/故障转移路由
加权路由	渐进式流量迁移、金丝雀测试、集群均衡	手动配置/响应慢；除非搭配健康检查，否则不具备健康感知能力	需要自动选择最近节点→延迟路由；或自动切换→故障转移路由
基于延迟的路由	自动为每个用户提供最低RTT	基于解析器位置而非用户位置路由；需要多区域端点	数据驻留优先级高于速度→地理定位路由
地理定位	合规性、本地化结果	VPN/转发解析器可能导致路由错误；地图精度较粗	速度优先级高于地理位置→基于延迟的路由
故障转移路由	自动主备切换	恢复时间受TTL+缓存限制；存在冷备风险	RTO要求亚秒级→区域内负载均衡器，而非DNS
Anycast	最近入口+吸收DDoS攻击	运维复杂度高（BGP）；路由变更时可能出现波动	仅拥有单个站点→不值得使用

Behavior under stress

压力下的表现

DNS fails in slow, wide ways — a bad answer or an authoritative outage affects everyone who looks up next, and lingers as long as TTLs allow.

TTL caching delays recovery and propagation. Resolvers and OS/browser caches hold answers for the TTL; some ISPs over-cache. A failover or IP change only takes effect as old entries expire — the effective recovery time is TTL plus stragglers, not zero.
Authoritative DNS as a SPOF. If your authoritative servers (or a single managed zone) go down, nothing resolves, even though your servers are healthy. Use a provider on anycast across many sites; consider a secondary DNS provider.
Health-check stampede / flapping. Aggressive health checks across many endpoints can hammer targets, and a flapping check can oscillate answers, scattering clients. Tune interval, failure threshold, and require N consecutive failures (→
```
resilience-failure
```
owns health-check tuning).
Low-TTL load. Cutting TTL to seconds for fast failover multiplies lookup QPS against authoritative servers and removes the cache cushion during an attack.
DDoS on the resolver tier. DNS is a classic amplification/DDoS target; an overwhelmed resolver makes your whole property unreachable.

Monitor: resolution latency and error/SERVFAIL rate, query QPS per record, health-check status per endpoint, time-to-propagate after a change, and the share of traffic each region/answer actually receives.

DNS故障表现为缓慢且影响范围广的问题——错误结果或权威服务器中断会影响所有后续查询的用户，且持续时间与TTL允许的缓存时长一致。

TTL缓存延迟恢复和传播。解析器、操作系统/浏览器缓存会保留结果直至TTL过期；部分ISP会过度缓存。故障转移或IP变更仅在旧缓存条目过期后生效——实际恢复时间是TTL加上滞后时间，而非零延迟。
权威DNS作为单点故障。如果你的权威服务器（或单个托管区域）宕机，即使你的服务器正常运行，也无法解析任何域名。使用跨多站点Anycast部署的服务商；考虑使用备用DNS服务商。
健康检查踩踏/波动。针对多个端点的频繁健康检查可能会冲击目标，波动的检查结果可能导致返回结果振荡，分散客户端。调整检查间隔、故障阈值，并要求连续N次失败才触发切换（→
```
resilience-failure
```
负责健康检查调优）。
低TTL负载。将TTL降至秒级以实现快速故障转移，会大幅增加权威服务器的查询QPS，并在攻击期间失去缓存缓冲。
解析器层DDoS攻击。DNS是典型的放大/DDoS攻击目标；解析器过载会导致你的整个服务不可访问。

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

How to apply

实施步骤

Clarify the inputs — geographic spread, RTO for a region loss, endpoint stability, steering goal, and mapping staleness (see Clarify first). One region with a fixed entry point needs only a simple record — stop there.
Pick the policy from the trade-off table — choose a record type (
```
ALIAS
```
at the apex onto an LB/CDN hostname is the common default) and a routing policy keyed to the steering goal: weighted for canary, latency for speed, geo for residency, failover for active-passive DR.
Set the key knobs — TTL (balance fast failover against lookup load and propagation), health-check interval and failure threshold, and the failover target. Decide secondary-DNS / anycast posture up front.
Stress-test the choice — walk Behavior under stress: confirm the TTL gives an acceptable effective recovery time, the authoritative tier is not a SPOF, and health checks won't flap or stampede.
Size it with numbers — estimate lookup QPS at the chosen TTL and the propagation window a change implies (→ Numbers that matter).
Pick a provider — default to the generic recipe; open a provider file only if the user named a cloud (see Choosing a provider).

明确输入信息——地理分布、区域失效后的RTO、端点稳定性、引导目标和映射陈旧容忍度（见“需先澄清的问题”）。单区域且入口点固定的情况仅需简单记录——至此即可停止。
根据权衡表选择策略——选择记录类型（区域顶点使用
```
ALIAS
```
指向负载均衡器/CDN主机名是常见默认方案）和与引导目标匹配的路由策略：加权路由用于金丝雀测试，延迟路由用于速度优化，地理路由用于数据驻留，故障转移路由用于主备灾备。
设置关键参数——TTL（平衡快速故障转移与查询负载、传播时间）、健康检查间隔和故障阈值，以及故障转移目标。提前确定备用DNS/Anycast部署方案。
压力测试所选方案——对照“压力下的表现”进行验证：确认TTL提供可接受的实际恢复时间，权威层不是单点故障，健康检查不会出现波动或踩踏。
量化规模——估算所选TTL下的查询QPS，以及变更带来的传播窗口（→ 关键数值）。
选择服务商——默认使用通用方案；仅当用户指定云服务商时，阅读
```
references/providers/<provider>.md
```
获取托管服务映射、配额/限制和服务商特定的权衡点。如果该服务商没有对应文件，则通用方案即为答案。

Dos and don'ts

注意事项

Put steering at DNS for cross-region choice and let an LB balance within a region.
Use
```
ALIAS
```
/
```
ANAME
```
at the apex onto an LB/CDN hostname so IP changes need no edits.
Pair routing policies with health checks so dead regions stop being handed out.
Run authoritative DNS on anycast across many sites; consider a second provider.
Set TTL deliberately — short enough for your RTO, long enough to survive load.

Don't

Don't expect DNS failover to be instant; it is bounded by TTL plus resolver caching.
Don't put a
```
CNAME
```
at the zone apex — it is invalid; use
```
ALIAS
```
/
```
ANAME
```
.
Don't trust geolocation for security or precise placement (VPNs and forwarders lie).
Don't run a single authoritative zone as a SPOF for an otherwise multi-region design.
Don't drop TTL to seconds everywhere "just in case" — it multiplies query load.

建议

将跨区域引导放在DNS层，让负载均衡器负责单区域内的流量均衡。
在区域顶点使用
```
ALIAS
```
/
```
ANAME
```
指向负载均衡器/CDN主机名，这样IP变更无需修改记录。
路由策略搭配健康检查，避免将失效区域返回给客户端。
在跨多站点的Anycast上运行权威DNS；考虑使用第二服务商。
谨慎设置TTL——短到满足RTO要求，长到足以应对负载。

禁忌

不要期望DNS故障转移是即时的；它受限于TTL和解析器缓存。
不要在区域顶点使用
```
CNAME
```
——这是无效的；使用
```
ALIAS
```
/
```
ANAME
```
。
不要依赖地理定位进行安全防护或精准部署（VPN和转发器会提供虚假位置）。
不要将单个权威区域作为多区域设计中的单点故障。
不要为了“以防万一”将所有TTL降至秒级——这会大幅增加查询负载。

Numbers that matter

关键数值

The quantities to estimate: the TTL, which sets both the propagation window and the effective failover time (a 60 s TTL means up to ~60 s-plus of staleness, not instant); the lookup QPS the TTL implies against authoritative servers (shorter TTL → more queries); and a resolution latency budget (one extra round trip, largely hidden by caching). Anchor these with rules of thumb and peak-multiplier math in

back-of-the-envelope

— don't restate its tables here.

需要估算的数值：TTL，它同时决定了传播窗口和实际故障转移时间（60秒TTL意味着最长约60秒以上的陈旧时间，而非即时生效）；TTL对应的权威服务器查询QPS（TTL越短→查询越多）；以及解析延迟预算（额外一次往返，大部分被缓存掩盖）。参考

back-of-the-envelope

中的经验法则和峰值乘数计算——此处无需重复其表格内容。

Interface sketch

接口示例

A DNS record is a contract: name (

api.example.com

), type (

AAAA

CNAME

ALIAS

), value (IP or target hostname), TTL (seconds), and an optional routing policy + health check. Example as a zone line:

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

Decide per record: which policy selects it, what health check gates it, and the TTL that bounds its staleness.

DNS记录是一份契约：名称（

api.example.com

）、类型（

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。

Choosing a provider

选择服务商

Default to the generic recipe above. If the user names a cloud, read

references/providers/<provider>.md

for the managed-service mapping, quotas/limits, and provider-specific trade-offs. If no file exists for that provider, the generic recipe is the answer.

默认使用上述通用方案。如果用户指定云服务商，阅读

references/providers/{generic,aws,azure,gcp}.md

获取各环境下的服务映射、限制和陷阱。如果该服务商没有对应文件，则通用方案即为答案。

Diagram

示意图

To visualize the resolution path (client → recursive resolver → root/TLD/ authoritative → answer) or a geo/latency-steered multi-region front door, use the in-plugin

architecture-diagram

skill. A quick inline sketch:

client → resolver → authoritative (policy: latency) → region A | region B

要可视化解析路径（客户端→递归解析器→根/TLD/权威服务器→结果）或地理/延迟引导的多区域入口，使用插件内的

architecture-diagram

Skill。快速内联示意图：

client → resolver → authoritative (policy: latency) → region A | region B

。

Related building blocks

References

参考资料

references/deep-dive.md
— resolution hierarchy (recursive vs authoritative, root/TLD), the full record-type set, how TTL/propagation really behaves, anycast mechanics, and health-checked failover internals. Read when designing the DNS layer in detail.
references/providers/{generic,aws,azure,gcp}.md
— service mappings, limits, and pitfalls per environment.

references/deep-dive.md
——解析层级（递归vs权威、根/TLD）、完整记录类型集、TTL/传播的实际行为、Anycast机制，以及健康检查故障转移的内部原理。详细设计DNS层时阅读。
references/providers/{generic,aws,azure,gcp}.md
——各环境下的服务映射、限制和陷阱。

dns