DNS路由和故障转移

1） DNS在容错中的作用

• 可用性（快速/可靠的失败者）；
• 性能（地理/后坐力）；
• 成本（最大限度地减少跨区域的egress和3rd派对呼叫）；
• 安全（DNSSEC，反hijack，CAA/DMARC/SPF控制）。

关键：简短的TTL（动态重要）和稳定的区域架构（公共+私有、分裂地平线）。

2）记录和实践的类型

A/AAAA-主要地址；始终尽可能发布IPv6。
CNAME vs ALIAS/ANAME：在域根上使用ALIAS/ANAME（或apex-flattening提供程序）。
TXT-SPF/DMARC/DKIM，验证；CAA是证书毕业生的限制。
SRV/NS-服务发现和委托。
SVCB/HTTPS是具有优先级和参数（ALPN，端口）的现代替代机制。

建议：按类捕获TTL标准（边缘/API/静态）。

3）路由策略

加权（加权）-受控流量份额（金丝雀/蓝绿色）。
基于Latency-选择最接近的延迟池。
Geo-routing-在国家/大陆/地区；对数据驻留很重要。
失败者（primary/secondary）-主动监视和切换。
多价值-多个A/AAAA；客户端自己选择（不能取代健康检查）。
Proximity/ASN路由-在某些提供商中：通过客户端网络。

组合：geo → latency → weight → health。

4）TTL，缓存和宣传

TTL API/扬声器：30-120 s（传感器速度与负载之间的平衡）。

Static/CDN: 1–24 ч.

负面TTL（SOA 'Minimum'）是60-300 s的≤，否则NXDOMAIN将"粘性"。
记住：Resolvers不需要立即丢弃缓存；考虑到"肮脏的尾巴"。

5）健康和残局检查

来自多个地区的健康检查：TCP/443+HTTP 2xx/3xx和lambda业务标准（例如，成功的'/健康？deep=true'与依赖性检查）。
合成（RUM/active）：主要路由上的API样本，TLS/OCSP验证，DNSSEC验证。
展出'/ready'（深）和'/live'（表面）；将DNS 池绑定到/ready。

6）公共vs私有DNS（分裂地平线）

公共区域-客户端访问。
Private zone是针对private endpoints的内部解决方案（VPC/VNet，上图）。

Conditional forwarding между on-prem ↔ cloud, region ↔ region.

命名： 'api...internal.corp` и `api..com`.

7）安全性： DNSSEC和域策略

DNSSEC：启用区域签名（KSK/ZSK）,关注密钥轮换和信任链。
CAA：列出有效的CA；为Alertes启用"iodef"。
SPF/DMARC/DKIM：邮件声誉和网络钓鱼保护。
DNS提供商帐户上的Registrar lock和MFA；更改日志（WORM存储）。

8） failover设计

8.1个型号

Active-Active：两个+健康池；通过latency/weight的平衡，健康检查排除不健康。
Active-Passive：主池+备份（事故发生前0%重量）。
区域环：本地事故中流向"邻近"地区的流量。
降级模式：如果后端不可用,则写入"轻量级"站点/登陆。

8.2回合制场景

1.监控记录降解"/ready"。
2.DNS更改响应（消除池或更改权重）。
3.交通进入健康地区，TTL决定速度。
4.稳定后-宽限期（15-30分钟），然后只有重量返回。

9）配置示例

9.1 AWS Route 53 — latency + health + weighted

hcl
Two latency aliases for different regions resource "aws_route53_record" "api_latency_eu" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1"
latency_routing_policy { region = "eu-central-1" }
alias { name = aws_lb. api_eu. dns_name zone_id = aws_lb. api_eu. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_eu. id ttl = 60
}

resource "aws_route53_record" "api_latency_us" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "us1"
latency_routing_policy { region = "us-east-1" }
alias { name = aws_lb. api_us. dns_name zone_id = aws_lb. api_us. zone_id evaluate_target_health = true }
health_check_id = aws_route53_health_check. api_us. id ttl = 60
}

Canary in EU: 10% of the weight of the resource "aws_route53_record" "api_weighted_canary" {
zone_id = var. zone_id name  = "api. example. com"
type  = "A"
set_identifier = "eu1-canary"
weighted_routing_policy { weight = 10 }
alias { name = aws_lb. api_eu_canary. dns_name zone_id = aws_lb. api_eu_canary. zone_id evaluate_target_health = true }
ttl = 30
}

9.2 Cloudflare-地理/ASN和失败池（想法）

Load Balancer Pools与健康检查（HTTP/TCP），带有Geo Steering（大洲/国家）和Session affinity的Load Balancer。
Fallback： Page Rule/Transform Rule到5xx的简化后端。

9.3 Azure/GCP

Azure Traffic Manager: Priority/Weighted/Performance/Geographic.

Google Cloud Load Balancing + Cloud DNS policy: geo-policy + health-checks через External HTTP(S) LB.

10）DNS的可观察性和SLO

SLI：成功率resolva，第95次resolva时间percentile，TTL中新鲜（非水平）响应的比例。
SLO：例如'99。95%的成功答桉≤ 100毫秒。
度量：NXDOMAIN-rate，SERVFAIL-rate，健康状态池，按地区划分的流量份额，加那利群岛份额。
Exemplars：通过合成中的"trace_id"将SLI链接到HTTP跟踪。

11）测试和操作

来自不同ASN/地区的合成材料（RIPE Atlas，Catchpoint，k6-DNS）。
dnsviz /'delv'检查DNSSEC； "dig+trace"异常。
Staging区域（'stg。example.（com'）为feilover排练；rehearsal脚本更改权重/优先级并返回。
Runbook：谁以及如何手动提升/降低重量，如何关闭池，如何执行"冻结"。

12）反模式

TTL=3000+在关键A/AAAA →缓慢/混乱的捕获器上。
没有健康检查或仅检查没有业务不变量的TCP端口。
一堆CNAME链条→缓慢的故障，缓存混乱。
唯一没有secondary/axfr备份的DNS提供程序。
需要DNSSEC的未签名区域；无关的CAA。
指示私有后端/DB的公共IP的记录。

13） iGaming/财务细节

司法管辖区：geo/country-routing以符合要求（重定向到本地域/前端）。
PSP/KYC：具有单个TTL和feilover策略的专用子域；快速转移至备用PSP。
负责任的游戏：具有法律页面的子域始终可用（备用静态/CDN）。
审核：WORM存储中的区域更改日志、更改签名和定期评论。
流程表：按区域划分的DNS编译规则（边缘过滤+DNS路由）。

14）准备就绪支票清单

• 按类别划分的TTL配置文件；负面TTL ≤ 300 s。
• 两个独立的DNS anycast网络（小学/中学），MFA/注册商锁。
• 政策：来自多个地区的geo/latency/weight+health-checks。
• DNSSEC已启用，CAA/DMARC/DKIM/SPF相关。
• Split-horizo​​n（公共/私人），用于内部通信的专用区域。
• Runbook feilover/Return，rehearsal脚本，金丝雀域。
• 监视SLI/SLO，NXDOMAIN/SERVFAIL 上的变量/RTT增长。
• Stadging zone和定期的"演习"failover。
• 对于iGaming：跨司法管辖区路由,PSP/KYC的单独域,不变审核。

15) TL;DR

构建组合策略：geo/latency+health-checks+重量,TTL 30-120与动态。共享public/private （split-horizon）,包括DNSSEC和CAA,保持第二DNS。制作rehearsal-failover并观察SLI/SLO DNS。对于iGaming,请考虑具有单独规则和对WORM进行更改的域的PSP/KYC管辖权和保留。