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路由和可观察性。记录迁移和滚动过程，保留备用提供商，定期检查"悬挂"记录的区域以及您的用户即使在最热的时刻也会稳定地到达正确的前沿。