DNS管理和路由
簡短的摘要
DNS是「名稱級別路由器」。有能力的TTL，區域和策略取決於用戶到達所需前端/網關的速度和可預測性。最小集合：Anycast提供商，健康的TTL，具有自動失敗的健康檢查，DNSSEC+CAA，IaC控制和可觀察性（響應和故障時間的SLO）。
基本體系結構
權威服務器（zones）-負責公司的域。
遞歸反義詞（clients/ISP/本身）-詢問詞根→ TLD →權威性。
Anycast是PoP集合上的相同IP尋址：Near PoP響應更快，並且在事故中幸存下來。
區域和委托
域的根區域→權威服務器提供商的「NS」。
子域（例如「api」。example.可以將獨立性委托給單獨的「NS」/提供商。
記錄類型（最小值）
'A'/' AAAA'是IPv4/IPv6地址。
「CNAME」是名稱的別名；不要從根本上使用區域（取而代之的是提供程序中的ALIAS/ANAME）。
'TXT'-驗證，SPF，定制標簽。
「MX」是郵件（如果使用）。
「SRV」-服務（SIP，LDAP等）。
「CAA」-誰可以為域發布證書。
「NS」/「SOA」-區域委托/設置。
「DS」是父級TLD的DNSSEC密鑰。
示例區域（片段）
$TTL 300
@ IN SOA ns1.dns.example. noc.example. (2025110501 3600 600 604800 300)
IN NS ns1.dns.example.
IN NS ns2.dns.example.
@ IN A 203.0.113.10
@ IN AAAA 2001:db8::10 api IN CNAME api-prod.global.example.
_www IN CNAME cdn.example.net.
_caa IN CAA 0 issue "letsencrypt.org"TTL和緩存
短的TTL （30-300 c）-用於揚聲器（API, failover）。
CDN/靜電的平均 TTL（300-3600 c）。
長的TTL（≥ 1天）-用於罕見的更改（MX/NS/DS）。
計劃遷移,提前24-72小時降低TTL。
考慮不可靠的緩存TTL （NXDOMAIN）：由「SOA MINIMUM」管理。
路由策略（GSLB級別）
Failover （active/passive）-將主IP交給假健康檢查,然後是儲備。
重量（traffic-split）-流量分配（例如,canary 5/95）。
基於Latency的RoR/區域網絡延遲最接近。
Geo-routing-在國家/大陸；適用於本地法律/PCI/PII。
Multivalue是一些「A/AAAA」，每個都有健康檢查。
小貼士
對於關鍵的API，連接基於latency+health-checks+短的TTL。
對於平穩的發布-加權且逐漸增加份額。
對於區域限制-geo和允許的提供商列表。
健康與自動切換
健康檢查：HTTP（S）（200 OK，正面/標頭），TCP（端口），ICMP。
聲譽/fingerprint：不僅要檢查端口，還要檢查後端的正確性（版本，build id）。
靈敏度閾值：「N」連續成功/未成功檢查，以避免翻轉。
讓我們吃一個指標：healthy-endpoint的比例，反應時間，切換次數。
私人區域和split-horizon
私有DNS： VPC/VNet/On-prem中的內部區域（例如,'svc.local.example`).
Split-horizon：針對內部和外部客戶的不同響應（內部IP與公共）。
泄漏保護：不要在外部使用「內部」名稱；檢查私人區域是否不會通過公共提供商發出聲音。
DNS安全性
DNSSEC：區域簽名（ZSK/KSK），父區域中的「DS」出版，密鑰滾動。
CAA：將TLS serts的發布限制為可信的CA。
DoT/DoH for Recourcers-客戶請求加密。
ACL/Rate-limit在威權主義：保護DDoS/ANY反射查詢。
Subdomain Takeover：定期掃描「掛起」CNAME/ALIAS到遠程服務（刪除資源-CNAME仍然存在）。
NS/Glue記錄：註冊商和DNS提供商之間的一致性。
SLO和可觀察性
SLO（示例）
權威性答案的可用性：≥ 99。99%/30天。
回復時間（p95）：全局≤ 50毫秒/≤ 150毫秒。
健康檢查成功： ≥ 99。9％，假陽性-≤ 0。1%.
更改後收斂時間（propagation）： TTL 60 s時≤ 5分鐘。
度量標準
RCODE（NOERROR/NXDOMAIN/SERVFAIL），QPS，p50/p95響應時間。
IPv6/IPv4份額，EDNS大小，Truncated（TC）響應。
在健康檢查，翻轉，DNSSEC簽名錯誤方面的轉換。
請求的DoH/DoT份額（如果由資源管理器控制）。
Logi
查詢（qname，qtype，rcode，client ASN/geo），異常（ANY風暴，每個前綴頻繁出現NXDOMAIN）。
IaC和自動化
Terraform/DNS提供程序：將區域保留在存儲庫、PR評論、計劃/應用程序中。
ExternalDNS （K8s）：從Ingress/Service自動創建/刪除記錄。
中間環境：「dev.」/「stg.」前綴和單獨的DNS提供商帳戶。
Terraform（簡化示例）
hcl resource "dns_a_record_set" "api" {
zone = "example.com."
name = "api"
addresses = ["203.0.113.10","203.0.113.20"]
ttl = 60
}
resource "dns_caa_record" "caa" {
zone = "example.com."
name = "@"
ttl = 3600 record {
flags = 0 tag = "issue"
value = "letsencrypt.org"
}
}Resolvers、緩存和性能
本機學習器（Unbound/Knot/Bind）更靠近應用程序，→小於p95。
啟用熱記錄預報,當權威不可用時,serve-stale。
EDNS （0）和正確的緩沖區大小,DNS Cookies,最小響應。
分開resolve流和應用程序流量（QoS）。
考慮Negative TTL：來自「bit」客戶機的許多NXDOMAIN可以獲得緩存。
DDoS和可持續性
具有全局PoP和機器人流量聚合的Anycast提供商。
響應率限制（RRL）至專制，防擴增。
禁止「ANY」，限制EDNS緩沖區，將過濾器設置為「重型」類型。
區域細分：關鍵是具有最佳DDoS屏蔽的提供商；不那麼重要-單獨。
備用提供商（secondaries）具有「AXFR/IXFR」和記錄器級別的自動NS收貨機。
操作和流程
更改：公關評論，金絲雀記錄，緩存加熱（低TTL → deploy →返回TTL）。
Rollover DNSSEC：法規，窗口，有效性監控（RFC 8901 KSK/ZSK）。
運行手冊：PoP的下降，不正確的NS代表團，掉落的健康檢查，大量的SERVFAIL。
DR計劃：備用DNS提供商,現成的區域模板,登錄器訪問,SLA取代NS。
實施支票清單
- 兩個獨立的權威提供商/RoR（Anycast），正確的「NS」記錄器。
- TTL策略：揚聲器短，穩定記錄長；negative TTL受到控制。
- 健康檢查和策略：failover/weighted/latency/geo按服務配置文件。
- DNSSEC（KSK/ZSK/DS），「CAA」限制了硫磺的產量。
- 區域的IaC，K8s的ExternalDNS，個別環境/帳戶。
- 監測：rcode/QPS/latency/propagation, SERVFAIL/簽名差。
- DDoS： Anycast, RRL, EDNS限制,單元/ACL。
- 48-72小時域遷移和TTL降級法規。
- 定期審計「掛起」CNAME/ALIAS，MX/SPF/DKIM/DMARC（如果使用郵件）。
典型的錯誤
在關鍵的「A/AAAA」上過大的TTL是長期遷移/操縱器。
單個DNS/單個 PoP提供程序是SPOF。
缺乏DNSSEC/CAA-替代風險/不受控制的硫磺。
不一致的分裂地平線→內部名稱向外泄漏。
GSLB上沒有健康檢查-手臂切換和延遲。
被遺忘的外部服務CNAME →了外包的風險。
缺少IaC →「雪花」和手動編輯錯誤。
iGaming/fintech的細節
區域版本和PSP： geo/latency-routing,白色IP/ASN合作夥伴列表,快速鎖定故障。
高峰（比賽/錦標賽）：短TTL，加熱CDN，活動名稱的單獨名稱（'event-N.example.com'）具有托管策略。
法律正確性：在發生重大變化（審計日誌）時捕獲區域的時間和版本。
Antifrod/BOT保護：tiebreakers/kapchi/check-endpoint的單獨名稱；在攻擊時迅速撤回「黑洞」（sinkhole）。
迷你花花公子
金絲雀前排發行（重量）：1. `api-canary.example.com '→流量的5％；2）監視p95/p99/錯誤；3）提高到25/50/100％；4）降解時折叠。
緊急失敗者：1.TTL 60 s；2）健康檢查標記了下降區域→ GSLB從響應中刪除；3）檢查外部解析器；4）狀態溝通。
DNS提供程序遷移：1.將區域導入到新的提供商；2）在舊版本中包括同步二級；3）在「安靜」的窗口中更改錄音機的「NS」；4）觀察SERVFAIL/val錯誤。
結果
可靠的DNS回路是Anycast權威機構+合理的TTL+健康/延遲+DNSSEC/CAA+IaC路由和可觀察性。記錄遷移和滾動過程，保留備用提供商，定期檢查「懸掛」記錄的區域以及您的用戶即使在最熱的時刻也會穩定地到達正確的前沿。