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管轄權和保留。