名称: 管理DNS 描述: 管理DNS记录、TTL策略和DNS即代码自动化，用于基础设施。当配置域名解析、从Kubernetes使用external-dns自动化DNS、设置基于DNS的负载均衡或在云提供商（Route53、Cloud DNS、Azure DNS、Cloudflare）之间故障排除传播问题时使用。

DNS管理

配置和自动化DNS记录，采用适当的TTL策略、DNS即代码模式和故障排除技术。

目的

为应用程序、基础设施和服务指导DNS配置，重点关注：

记录类型选择（A、AAAA、CNAME、MX、TXT、SRV、CAA）
TTL策略用于传播和缓存
DNS即代码自动化（external-dns、OctoDNS、DNSControl）
云DNS服务比较和选择
基于DNS的负载均衡模式
故障排除工具和技术

何时使用此技能

在以下情况应用DNS管理模式：

为新应用程序或服务设置DNS
从Kubernetes工作负载自动化DNS更新
配置基于DNS的故障转移或负载均衡
故障排除DNS传播或解析问题
在提供商之间迁移DNS
以最小停机时间规划DNS变更
为全球用户实现GeoDNS

记录类型选择

快速参考

地址解析：

A记录：将主机名映射到IPv4地址（example.com → 192.0.2.1）
AAAA记录：将主机名映射到IPv6地址（example.com → 2001:db8::1）
CNAME记录：别名到另一个域名（www.example.com → example.com）
- 不能在区域顶点（@）使用
- 不能在同一名称处与其他记录共存

电子邮件配置：

MX记录：将电子邮件定向到邮件服务器，带优先级
TXT记录：电子邮件认证（SPF、DKIM、DMARC）和验证

服务发现：

SRV记录：指定服务位置（协议、优先级、权重、端口、目标）

委派和安全：

NS记录：将子域名委派给不同的名称服务器
CAA记录：限制哪些证书颁发机构可以颁发证书

云特定：

ALIAS记录：类似CNAME，但可在区域顶点工作（Route53、Cloudflare）

决策树

需要指向：
├─ IPv4地址？ → A记录
├─ IPv6地址？ → AAAA记录
├─ 另一个域名？
│  ├─ 区域顶点（@） → ALIAS/ANAME或A记录
│  └─ 子域名 → CNAME
├─ 邮件服务器？ → MX记录（带优先级）
├─ 电子邮件认证？ → TXT记录（SPF/DKIM/DMARC）
├─ 服务发现？ → SRV记录
├─ 域名验证？ → TXT记录
├─ 证书控制？ → CAA记录
└─ 子域名委派？ → NS记录

有关详细记录类型示例和模式，请参阅references/record-types.md。

TTL策略

标准TTL值

按变更频率：

稳定记录：3600-86400秒（1-24小时）- NS、稳定A/AAAA
正常操作：3600秒（1小时）- 标准网站、MX
中等变更：300-1800秒（5-30分钟）- 开发、A/B测试
故障转移场景：60-300秒（1-5分钟）- 需要快速更新的关键记录

**关键原则：**较低TTL = 更快传播但更高DNS查询负载

变更前流程

规划DNS变更时：

T-48小时：将TTL降低到300秒
T-24小时：验证TTL在全球传播
T-0小时：进行DNS变更
T+1小时：验证新记录传播
T+6小时：确认全球传播
T+24小时：将TTL提升回正常值（3600秒）

传播公式： 最大时间 = 旧TTL + 新TTL + 查询时间

示例：变更一个TTL为3600秒的记录，最多需要2小时完全传播。

按用例的TTL

用例	TTL	理由
生产（稳定）	3600秒	平衡速度和负载
计划变更前	300秒	快速传播
开发/暂存	300-600秒	频繁变更
基于DNS的故障转移	60-300秒	快速恢复
邮件服务器	3600秒	很少变更
NS记录	86400秒	非常稳定

有关详细TTL场景和计算，请参阅references/ttl-strategies.md。

DNS即代码工具

按用例的工具选择

Kubernetes DNS自动化 → external-dns

基于注释的配置在服务/Ingress上
自动同步到DNS提供商（支持20+）
无需手动DNS更新
参见examples/external-dns/

多提供商DNS管理 → OctoDNS或DNSControl

DNS记录的版本控制
跨多个提供商同步配置
应用前预览变更
OctoDNS（Python/YAML）- 参见examples/octodns/
DNSControl（JavaScript）- 参见examples/dnscontrol/

基础设施即代码 → Terraform

与云资源一起管理DNS
提供商特定资源（aws_route53_record等）
参见examples/terraform/

工具比较

工具	语言	最适合	Kubernetes	多提供商
external-dns	Go	K8s自动化	★★★★★	★★★★
OctoDNS	Python/YAML	版本控制	★★★	★★★★★
DNSControl	JavaScript	复杂逻辑	★★	★★★★★
Terraform	HCL	IaC集成	★★★	★★★★

快速开始：external-dns

# 带DNS注释的Kubernetes服务
apiVersion: v1
kind: Service
metadata:
  name: app
  annotations:
    external-dns.alpha.kubernetes.io/hostname: app.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  type: LoadBalancer
  ports:
    - port: 80

部署external-dns控制器一次，然后所有带注释的服务/Ingress自动创建DNS记录。

有关完整示例，请参阅examples/external-dns/和references/dns-as-code-comparison.md。

云DNS提供商选择

提供商特性

AWS Route53

最适合AWS密集型基础设施
高级路由策略（加权、延迟、地理位置、故障转移）
带自动故障转移的健康检查
AWS资源的ALIAS记录（ELB、CloudFront、S3）
定价：$0.50/月每区域 + $0.40每百万查询

Google Cloud DNS

最适合GCP原生应用程序
带自动密钥轮换的强DNSSEC支持
VPC内部DNS的私有区域
拆分视野DNS（不同内部/外部记录）
定价：$0.20/月每区域 + $0.40每百万查询

Azure DNS

最适合Azure原生应用程序
与Azure流量管理器集成
Azure私有DNS区域
Azure RBAC用于访问控制
定价：$0.50/月每区域 + $0.40每百万查询

Cloudflare

最适合多云或云无关
全球最快DNS查询时间
内置DDoS保护
带无限查询的免费层
CDN集成
定价：免费层，$20/月专业版，$200/月商业版

选择决策树

基于选择：
├─ AWS密集型？ → Route53
├─ GCP原生？ → Cloud DNS
├─ Azure原生？ → Azure DNS
├─ 多云？ → Cloudflare或OctoDNS/DNSControl
├─ 需要最快全球DNS？ → Cloudflare
├─ 需要DDoS保护？ → Cloudflare
└─ 预算有限？ → Cloudflare（免费层）或Cloud DNS（最低区域成本）

有关详细提供商比较和示例，请参阅references/cloud-providers.md。

基于DNS的负载均衡

GeoDNS（地理路由）

基于客户端位置返回不同IP地址以：

减少延迟（路由到最近数据中心）
遵守数据驻留要求
跨区域分发负载

示例模式：

客户端位置 → DNS响应
├─ 北美 → 192.0.2.1（美国数据中心）
├─ 欧洲 → 192.0.2.10（欧盟数据中心）
└─ 默认 → CloudFront边缘（全球CDN）

加权路由

按百分比分发流量用于：

蓝绿部署
金丝雀发布（10%到新版本）
A/B测试

示例模式：

DNS响应：
├─ 90% → 192.0.2.1（稳定版本）
└─ 10% → 192.0.2.2（金丝雀版本）

基于健康检查的故障转移

自动将流量路由远离不健康端点。

模式：

主：192.0.2.1（每30秒健康检查）
├─ 健康 → 返回主IP
└─ 不健康 → 返回次IP（192.0.2.2）

故障转移时间：~2-3分钟
= 健康检查失败（90秒） + TTL过期（60秒）

有关完整负载均衡示例，请参阅examples/load-balancing/。

故障排除

基本命令

检查DNS解析：

# 基本查询
dig example.com

# 清洁输出（仅IP）
dig example.com +short

# 查询特定DNS服务器
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# 跟踪解析路径
dig +trace example.com

检查TTL：

dig example.com | grep -A1 "ANSWER SECTION"
# 查找TTL值（IN A前的数字）

检查传播：

# 多个解析器
dig @8.8.8.8 example.com +short       # Google
dig @1.1.1.1 example.com +short       # Cloudflare
dig @208.67.222.222 example.com +short # OpenDNS

刷新本地DNS缓存：

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux
sudo systemd-resolve --flush-caches

常见问题

慢传播：

检查当前TTL（旧TTL必须先过期）
变更前24-48小时降低TTL
使用传播检查器：whatsmydns.net、dnschecker.org

区域顶点的CNAME：

错误：不能在@（区域顶点）使用CNAME
解决方案：使用ALIAS记录（Route53、Cloudflare）或A记录

external-dns不创建记录：

验证注释拼写：external-dns.alpha.kubernetes.io/hostname
检查域名过滤器匹配：--domain-filter=example.com
查看external-dns日志以获取错误
确认提供商凭据配置

有关详细故障排除，请参阅references/troubleshooting.md。

常见模式

模式1：Kubernetes DNS自动化

# 部署external-dns（每个集群一次）
helm install external-dns external-dns/external-dns \
  --set provider=aws \
  --set domainFilters[0]=example.com \
  --set policy=sync

# 然后注释服务
apiVersion: v1
kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: api.example.com
    external-dns.alpha.kubernetes.io/ttl: "300"
spec:
  type: LoadBalancer

模式2：使用OctoDNS的多提供商同步

# octodns-config.yaml
providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./config
  route53:
    class: octodns_route53.Route53Provider
  cloudflare:
    class: octodns_cloudflare.CloudflareProvider

zones:
  example.com.:
    sources: [config]
    targets: [route53, cloudflare]

模式3：基于DNS的故障转移

# 带健康检查的Route53
resource "aws_route53_health_check" "primary" {
  fqdn              = "primary.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_record" "primary" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  ttl            = 60
  set_identifier = "primary"

  failover_routing_policy {
    type = "PRIMARY"
  }

  health_check_id = aws_route53_health_check.primary.id
  records         = ["192.0.2.1"]
}

resource "aws_route53_record" "secondary" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "api.example.com"
  type           = "A"
  ttl            = 60
  set_identifier = "secondary"

  failover_routing_policy {
    type = "SECONDARY"
  }

  records = ["192.0.2.2"]
}

与其他技能的集成

基础设施即代码：

通过Terraform/Pulumi与其他资源一起管理DNS
IaC存储库中的区域配置

Kubernetes操作：

external-dns自动化Kubernetes工作负载的DNS
用于自动DNS的Ingress控制器集成

负载均衡模式：

基于DNS的负载均衡（GeoDNS、加权路由）
健康检查和故障转移配置

安全强化：

用于DNS完整性的DNSSEC
用于证书颁发机构控制的CAA记录
基于DNS的DDoS缓解

秘密管理：

在保险库中存储DNS提供商API凭据
安全DDNS更新机制

附加资源

参考文档：

references/record-types.md - 带示例的详细记录类型指南
references/ttl-strategies.md - TTL场景和传播计算
references/cloud-providers.md - 提供商比较和详细特性
references/troubleshooting.md - 常见问题和解决方案
references/dns-as-code-comparison.md - 工具比较矩阵

示例：

examples/external-dns/ - Kubernetes DNS自动化
examples/octodns/ - 带YAML的多提供商同步
examples/dnscontrol/ - 带JavaScript DSL的多提供商
examples/terraform/ - 云提供商配置
examples/load-balancing/ - GeoDNS和故障转移模式

脚本：

scripts/check-dns-propagation.sh - 跨解析器验证传播
scripts/validate-dns-config.py - 验证DNS配置
scripts/export-dns-records.sh - 导出现有DNS记录
scripts/calculate-ttl-propagation.py - 计算传播时间

快速参考

记录类型速查表

记录	目的	示例
A	IPv4地址	example.com → 192.0.2.1
AAAA	IPv6地址	example.com → 2001:db8::1
CNAME	别名到域名	www → example.com
MX	邮件服务器	10 mail.example.com
TXT	文本/验证	“v=spf1 include:_spf.google.com ~all”
SRV	服务位置	10 60 5060 sip.example.com
NS	名称服务器委派	ns1.provider.com
CAA	CA授权	0 issue “letsencrypt.org”

TTL速查表

场景	TTL	原因
稳定生产	3600秒	平衡速度/负载
变更前	300秒	快速传播
故障转移	60-300秒	快速恢复
NS记录	86400秒	非常稳定

提供商速查表

提供商	最适合	关键特性
Route53	AWS	高级路由、健康检查
Cloud DNS	GCP	DNSSEC、私有区域
Azure DNS	Azure	流量管理器集成
Cloudflare	多云	最快、DDoS保护、免费层

工具速查表

工具	使用时机
external-dns	Kubernetes DNS自动化
OctoDNS	多提供商、Python环境
DNSControl	多提供商、JavaScript偏好
Terraform	与其他基础设施一起管理DNS