managing-dns

DNS 管理

通过适当的 TTL 策略、DNS 即代码模式和故障排除技术，配置并自动化 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）

决策树

Need to point domain to:
├─ IPv4 Address? → A record
├─ IPv6 Address? → AAAA record
├─ Another Domain?
│  ├─ Zone apex (@) → ALIAS/ANAME or A record
│  └─ Subdomain → CNAME
├─ Mail Server? → MX record (with priority)
├─ Email Authentication? → TXT record (SPF/DKIM/DMARC)
├─ Service Discovery? → SRV record
├─ Domain Verification? → TXT record
├─ Certificate Control? → CAA record
└─ Subdomain Delegation? → NS record

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

TTL 策略

标准 TTL 值

按变更频率划分：

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

核心原则： TTL 越低，传播越快，但 DNS 查询负载越高

变更前流程

规划 DNS 变更时：

T-48h: Lower TTL to 300s
T-24h: Verify TTL propagated globally
T-0h:  Make DNS change
T+1h:  Verify new records propagating
T+6h:  Confirm global propagation
T+24h: Raise TTL back to normal (3600s)

传播公式： Max Time = Old TTL + New TTL + Query Time

示例：更改 TTL 为 3600s 的记录，最多需要 2 小时才能完全传播。

按使用场景划分的 TTL

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

如需详细的 TTL 场景和计算方式，请参阅 references/ttl-strategies.md。

DNS 即代码工具

按使用场景选择工具

Kubernetes DNS 自动化 → external-dns

• 在 Service/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

# Kubernetes Service with DNS annotation
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 控制器，之后所有带注解的 Services/Ingresses 都会自动创建 DNS 记录。

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

云 DNS 服务商选择

服务商特性

AWS Route53

• 最适合以 AWS 为主的基础设施
• 高级路由策略（加权、延迟、地理位置、故障转移）
• 配备自动故障转移的运行状况检查
• 适用于 AWS 资源（ELB、CloudFront、S3）的 ALIAS 记录
• 价格：每个区域每月 $0.50 + 每百万次查询 $0.40

Google Cloud DNS

• 最适合原生 GCP 应用
• 提供强大的 DNSSEC 支持和自动密钥轮换
• 用于 VPC 内部 DNS 的私有区域
• 分离视界 DNS（不同的内部/外部记录）
• 价格：每个区域每月 $0.20 + 每百万次查询 $0.40

Azure DNS

• 最适合原生 Azure 应用
• 与 Azure Traffic Manager 集成
• Azure Private DNS 区域
• 通过 Azure RBAC 进行访问控制
• 价格：每个区域每月 $0.50 + 每百万次查询 $0.40

Cloudflare

• 最适合多云或云无关场景
• 全球 DNS 查询速度最快
• 内置 DDoS 防护
• 免费套餐，查询次数不限
• CDN 集成
• 价格：免费套餐，Pro 每月 $20，Business 每月 $200

选择决策树

Choose based on:
├─ AWS-heavy? → Route53
├─ GCP-native? → Cloud DNS
├─ Azure-native? → Azure DNS
├─ Multi-cloud? → Cloudflare or OctoDNS/DNSControl
├─ Need fastest global DNS? → Cloudflare
├─ Need DDoS protection? → Cloudflare
└─ Budget-conscious? → Cloudflare (free tier) or Cloud DNS (lowest zone cost)

详细的服务商对比和示例请参阅 references/cloud-providers.md。

基于 DNS 的负载均衡

GeoDNS（地理路由）

根据客户端位置返回不同的 IP 地址，以便：

• 降低延迟（路由至最近的数据中心）
• 满足数据驻留要求
• 在不同区域之间分配负载

示例模式：

Client Location → DNS Response
├─ North America → 192.0.2.1 (US data center)
├─ Europe → 192.0.2.10 (EU data center)
└─ Default → CloudFront edge (global CDN)

加权路由

按百分比分配流量，适用于：

• 蓝绿部署
• 金丝雀发布（将 10% 的流量导向新版本）
• A/B 测试

示例模式：

DNS Responses:
├─ 90% → 192.0.2.1 (stable version)
└─ 10% → 192.0.2.2 (canary version)

基于运行状况检查的故障转移

自动将流量从不健康的端点转移出去。

模式：

Primary: 192.0.2.1 (health checked every 30s)
├─ Healthy → Return primary IP
└─ Unhealthy → Return secondary IP (192.0.2.2)

Failover time: ~2-3 minutes
= Health check failures (90s) + TTL expiration (60s)

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

故障排除

必备命令

检查 DNS 解析：

# Basic query
dig example.com

# Clean output (just IP)
dig example.com +short

# Query specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Trace resolution path
dig +trace example.com

检查 TTL：

dig example.com | grep -A1 "ANSWER SECTION"
# Look for TTL value (number before IN A)

检查传播情况：

# Multiple resolvers
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 自动化

# Deploy external-dns (once per cluster)
helm install external-dns external-dns/external-dns \
  --set provider=aws \
  --set domainFilters[0]=example.com \
  --set policy=sync

# Then annotate Services
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 with health checks
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"]
}

与其他技能集成

infrastructure-as-code：

• 使用 Terraform/Pulumi 与其他资源一同管理 DNS
• 在 IaC 仓库中配置区域

kubernetes-operations：

• external-dns 为 Kubernetes 工作负载自动配置 DNS
• 集成 Ingress 控制器以自动配置 DNS

load-balancing-patterns：

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

security-hardening：

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

secret-management：

• 在保险库中存储 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 - 验证 DNS 在各解析器中的传播情况
• 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	原因
稳定的生产环境	3600s	平衡速度和负载
变更前	300s	加快传播
故障转移	60-300s	快速恢复
NS 记录	86400s	非常稳定

提供商速查表

提供商	最适用场景	主要功能
Route53	AWS	高级路由、健康检查
Cloud DNS	GCP	DNSSEC、私有区域
Azure DNS	Azure	Traffic Manager 集成
Cloudflare	多云	速度最快、DDoS 防护、免费套餐

工具速查表

工具	适用场景
external-dns	Kubernetes DNS 自动化
OctoDNS	多提供商、使用 Python 的团队
DNSControl	多提供商、偏好 JavaScript
Terraform	与其他基础设施一同管理 DNS