01 · 递归缓存：中断时的第一缓冲带
递归解析器天然是权威与终端之间的容量缓冲与故障缓冲。权威短时失效时，缓存中的记录仍可应答；其缓冲深度由四要素决定：
| 机制 | 规范 | 韧性作用 |
|---|---|---|
| 正缓存 | RFC 1034/1035 | 权威不可达时以缓存记录继续服务至TTL届满 |
| 负缓存 | RFC 2308（1998） | NXDOMAIN/无数据按SOA MINIMUM缓存，避免无效重试压垮上游 |
| Serve Stale | RFC 8767（2020） | TTL届满后上游失效，仍返回过期数据并后台重试——将"硬失败"转为"陈旧但可用" |
| 缓存预取 | BIND/商业实现特性 | 临近过期的热点记录提前刷新，消除TTL到期引发的解析尖峰与上游依赖脉冲 |
1.1 Serve Stale的双刃剑
RFC 8767规定递归器在"解析失败（超时/SERVFAIL）且缓存中存在过期数据"时，可返回过期应答并将TTL标注为0。BIND自9.12起支持、9.16起机制成熟：是否默认启用因组件与版本而异——过期记录保留缓存（stale-cache-enable）在受支持版本中默认关闭、需显式启用；陈旧期上限 max-stale-ttl 的默认值随版本演进（早期为1周，2020年6月起ISC调整为12小时量级）；过期应答TTL（stale-answer-ttl）默认30秒。Unbound则需显式配置 serve-expired: yes。具体参数以所部署版本的ARM（管理员参考手册）为准。其韧性收益在Facebook 2021类事件中已经体现：缓存+stale可让用户侧在权威长时间不可达时维持基本访问。但代价必须被治理：
- 数据陈旧风险：迁移/ failover期间返回旧IP可能把流量导向已下线节点；权威侧恢复后必须依赖后台重试快速收敛。
- 缓存击穿叠加：若权威失效源于容量耗尽，stale期间递归器的后台重试（建议退避）应与权威容量评估联动，避免恢复时刻的"重试雪崩"。
- 与TTL策略的耦合：低TTL记录几乎无法受益于stale（过期数据本身很快到期），再次印证第4页"分级TTL"设计的必要性。
1.2 递归器自身的高可用
递归器本身是新的集中点。企业级部署的通行做法：递归器集群（anycast VIP或负载均衡）+ 共享缓存层（如dnscache/memcached式缓存分层，或商业递归器的集群特性）+ 多上游（下文）。须避免"递归器单实例+serve-stale"的组合被误认为高可用——stale只是延长降级容忍时间，不消除SPOF。
02 · 多解析器与竞速：Happy Eyeballs思想在DNS的应用
RFC 8305（2017）为TCP建立的多路径竞速（Happy Eyeballs v2）思想同样适用于解析路径选择：当终端或递归器配置多个上游（如ISP递归+公共递归，或双数据中心递归）时，并发竞速查询并采用最先有效应答，可将单解析器故障的感知时间从"超时重试串行链"压缩到"竞速窗口"内（数百毫秒级）。
2.1 多解析器配置的坑
- "主备"≠多活：操作系统stub通常按序尝试解析器（先A超时再B），切换感知取决于超时计时器（秒级到十秒级）；只有竞速型实现才是真正的亚秒级容错。
- 视图分裂（Split-horizon）：企业内网依赖私有视图时，混入公共解析器会导致内外视图混淆——多解析器策略必须与视图设计协同。
- 不一致应答的处置：两解析器应答不一致（配置漂移/缓存差异）时，缺乏策略的客户端可能随机采用，掩盖故障根因；竞速实现应记录不一致事件供运维溯源。
03 · 加密DNS：协议收益与故障域收敛
3.1 协议对比
| 协议 | 规范 | 传输 | 韧性特性 |
|---|---|---|---|
| DoT | RFC 7858/8310 | TCP/853 | 连接可复用；会话恢复降低握手成本；端口独立易被策略管控 |
| DoH | RFC 8484 | HTTPS/443 | 复用Web基础设施与CDN韧性；与Web流量共用故障域 |
| DoQ | RFC 9250（2022） | QUIC/853 | 0-RTT与连接迁移；丢包环境下的时延韧性优于TCP系 |
3.2 服务发现机制：从手工配置到自动协商
- DDR（RFC 9462）与SVCB/HTTPS（RFC 9460，2023）：解析器在普通53端口应答中携带HTTPS记录，客户端据此自动升级至加密连接——升级路径无需人工配置，失败可回退明文。
- DNS服务器SVCB映射（RFC 9461）：_dns.resolver.arpa 查询使客户端发现"指定解析器的加密端点参数"，为DDR提供参数载体。
- DHCP/RA发现（RFC 9463）：网络通过DHCP/路由器通告直接下发网络指定加密解析器（DNR），企业内网可借此下发自有DoT/DoH服务，实现"加密+可审计"兼得。
- 客户端演进：Android自9.0（2018）支持"私人DNS"（DoT）；Apple自iOS 14/macOS 11（2020）支持加密DNS描述文件；Windows 11支持DoH自动升级。企业可通过组策略/MDM统一下发策略。
故障域收敛风险：加密DNS使终端解析依赖收敛到少数超级提供商（公共DoH端点）。这些端点天然具备全球anycast与海量冗余，单点故障概率低；但全球性配置事故或策略封锁的爆炸半径也同比放大（全部依赖客户端同时失效）。治理要点：企业应下发自有加密解析器而非裸禁853/443；运营商级故障演练应包含"公共DoH端点全局不可达"场景（第8页）。
04 · IPv6与过渡技术的解析面
- 双栈解析行为：双栈终端会同时查询A与AAAA记录；地址选择遵循RFC 6724。AAAA查询失败（如AAAA记录存在但网络不可达）造成的"解析成功、连接失败"类问题，要求解析面与应用连接测试协同排障。
- DNS64/NAT64：RFC 6147（DNS64）+RFC 6146（NAT64）为纯IPv6网络合成A记录；合成依赖递归器特性，故障时表现与普通解析不同（IPv6-only用户看不到A记录）。发现机制遵循RFC 7050。
- 464XLAT（RFC 6877）：运营商级IPv6-only部署（如T-Mobile美国网络的公开实践）在客户端做464翻译，使纯IPv4应用可用——解析面仍由DNS64合成，验证了解析韧性与网络架构的紧耦合。
- 企业启示：IPv6解析记录（AAAA）必须与A记录同等级运维，包括TTL策略、监控探针与故障切换预案；只监控A记录的双栈服务等于半个监控。
05 · 终端解析栈差异速览
| 平台组件 | 默认行为与韧性要点 |
|---|---|
| Windows | DNS Client服务缓存；NRPT策略路由；DoH可经组策略配置 |
| systemd-resolved | 按链路分流与竞速；LLMNR/mDNS可关闭；企业应锁定上游 |
| Android Private DNS | DoT严格/自动模式；严格模式下明文回退被禁止——解析器故障即应用级断网 |
| Apple平台 | 加密DNS描述文件（系统级/按网络）；对企业下发友好 |
| 容器/K8s | CoreDNS（插件链）；ndots与search域放大查询量；须防解析风暴 |
终端侧韧性清单（可直接采用）：①配置≥2个解析器（企业场景：双递归+公共应急）；②启用竞速型stub或接受秒级主备切换；③加密DNS下发自有解析器（RFC 9463）而非封端口；④stale与prefetch开启；⑤AAAA/A监控对等；⑥客户端DNS缓存纳入故障排查手册（浏览器/运行时独立缓存是"改了TTL不生效"投诉的主要来源）。
本节参考来源（第5页）
RFC 8767（2020）：Serving Stale DNS Data。rfc-editor.org/rfc/rfc8767
RFC 2308（1998）：Negative Caching of DNS Queries。rfc-editor.org/rfc/rfc2308
RFC 8305（2017）：Happy Eyeballs Version 2。rfc-editor.org/rfc/rfc8305
RFC 7858（2016）：DNS over TLS；RFC 8484（2018）：DNS over HTTPS；RFC 9250（2022）：DNS over QUIC。rfc-editor.org
RFC 9460（2023）：SVCB/HTTPS RR；RFC 9461：Service Binding Mapping for DNS Servers；RFC 9462：Discovery of Designated Resolvers；RFC 9463：DNR via DHCP/RA。rfc-editor.org
RFC 6147（2011）：DNS64；RFC 6146（2011）：NAT64；RFC 7050（2013）：Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis。rfc-editor.org
RFC 6724（2012）：Default Address Selection for IPv6。rfc-editor.org/rfc/rfc6724
Android开发者文档：私人DNS（Private DNS, DoT）；Apple平台加密DNS描述文件文档。developer.android.com