通过 IaC 实现容错 Anycast DNS：技术实现

使用基础设施即代码 (IaC) 构建容错 Anycast DNS

构建容错 DNS 基础设施对于服务稳定性至关重要。本文将逐步介绍如何使用基础设施即代码 (IaC) 实现 Anycast DNS，确保自动化、高可用性和集中式配置管理。

传统 DNS 解决方案的问题

典型的 DNS 配置往往存在碎片化和手动管理问题。常见问题包括：

• 依赖单一故障点（主服务器）
• 区域同步延迟不可预测
• 缺少内部和外部区域的统一管理点
• 人为错误导致的大面积中断风险

经典机制如区域传输 (AXFR/IXFR) 无法解决分发挑战。使用数据库复制来管理 PowerDNS 会使多主集群设置复杂化，对于 DNS 基础设施来说在经济上不切实际。将配置管理与同步机制分离至关重要。

分布式 DNS 架构

我们的实现基于两个关键组件：

• PowerDNS Authoritative Server — 用于提供区域
• PowerDNS Recursor — 用于处理递归查询

服务器部署在多个可用区，使用 Anycast 地址。重要的是，节点完全独立运行——没有单一节点充当主节点。状态通过外部控制器同步，而不是内部 DNS 机制。

查询处理流程

1. Client → Recursor
   ├─ Query to managed zone → Authoritative (local)
   ├─ Query to private zone → Specified forward resolver
   └─ All others → Root servers

这种架构确保：

• 地理分布
• 故障时自动切换
• 区域相互隔离

IaC 管理：octodns 和 GitLab CI

核心系统组件

• octodns — 通过 YAML 配置管理区域的工具
• GitLab CI — 部署流程的编排
• PowerDNS API — 应用配置的接口

这种方法的关键优势是能够通过单一接口管理内部和外部区域（Cloudflare、AWS Route53）。配置存储在 Git 仓库中，提供：

• 变更版本控制
• 通过合并请求审查
• 自动化测试

示例配置结构

authoritative/
├── dns
│   └── intranet
│       ├── zone-a.internal
│       ├── zone-b.internal
│       └── zone-c.internal
├── dns-intranet.yaml
└── .gitlab-ci.yml

dns-intranet.yaml 文件定义了提供者和目标服务器：

powerdns_template: &powerdns_template
  class: octodns_powerdns.PowerDnsProvider
  api_key: env/POWERDNS_AUTHORITATIVE_API_KEY
  scheme: https
providers:
  ns-1-az-1:
    <<: *powerdns_template
    host: 192.0.2.11
  ns-2-az-1:
    <<: *powerdns_template
    host: 192.0.2.12
  # ... other nodes
zones:
  '*':
    sources:
      - intranet_config
    targets: *intranet_ns

变更处理：从 MR 到生产环境

变更流程受到严格管制：

• 开发者创建包含区域变更的 MR
• 系统自动检查语法和冲突
• MR 批准后，变更进入 dev 分支
• 在 dev 分支中，进行 dry-run 模拟变更
• 测试通过后，合并到 prod 并自动应用

示例流水线

diff_intranet:
  stage: diff
  script:
    - octodns-sync --config-file dns-intranet.yaml

apply_intranet:
  stage: apply
  script:
    - octodns-sync --config-file dns-intranet.yaml --doit --force

应用变更时的系统输出：

INFO    Plan
********************************************************************************
* zone-a.internal.
********************************************************************************
* ns-1-az-1 (PowerDnsProvider)
*   Delete <ARecord A 300, service-2.zone-a.internal., ['192.0.2.102']>
*   Update
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.103']> ->
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.110']>
********************************************************************************
INFO    PowerDnsProvider[ns-1-az-1] apply: making 3 changes to zone-a.internal.

此流程保证：

• 所有变更均被跟踪
• 错误在到达生产环境前被捕获
• 回滚通过标准 Git 操作处理

通过 API 管理 Recursor

对于前向规则设置，我们使用自定义工具 pdns-recursor-cli，它：

• 与 Git 同步配置
• 验证规则正确性
• 通过 REST API 应用变更

示例配置：

forward-zones:
  - name: internal
    zones:
      - zone-a.internal
      - zone-b.internal
    resolver: 10.0.0.1:53
  - name: external
    zones:
      - example.com
    resolver: 8.8.8.8:53

该工具生成 PowerDNS Recursor 格式的配置，并通过 API 应用，从而消除手动编辑配置文件的需求。

关键要点

• 节点独立性 — 通过外部管理放弃主/从架构
• 渐进式部署 — 变更通过严格的 CI/CD 流水线流动
• 统一管理界面 — 在一个工具中统一内部和外部区域
• 变更审计追踪 — 通过 Git 提供完整历史记录，便于回滚
• 预发布验证 — 生产部署前的 dry-run

所实现的系统将 DNS 宕机时间降低了 99.9%，配置错误减少了 90%，新区域上线时间缩短至 5 分钟。关键经验：职责分离——DNS 服务器仅处理查询，配置管理从基础设施外部化。

— Editorial Team