Cloudflare Internal DNS 现已正式可用。它把私有网络需要的权威 DNS 与递归 DNS 放到 Cloudflare 的全球网络上，并与 Zero Trust、网络服务和公共 DNS 使用同一套控制平面。对同时维护办公网络、云上 VPC、数据中心和远程接入的团队来说，这项变化的重点不只是“多了一个 DNS 产品”，而是内部域名解析终于可以和网络访问策略放在同一个运营边界内考虑。
两类 DNS 职责，解决的是不同问题
内部 DNS 经常被当成一个整体，但实际包含两条不同的数据路径。
权威 DNS 回答组织自己拥有的私有区域。例如：
api.corp.example应该解析到哪个内部负载均衡器；db.prod.internal对应哪个私有地址；- 某个服务发现记录的 TTL 和目标是什么。
递归 DNS 则代表客户端继续查找答案。员工设备或工作负载查询公共域名、合作方域名或其他内部区域时，递归解析器负责沿 DNS 委派链获取结果并缓存响应。
将两者同时纳入私有网络方案很重要。如果只迁移权威区域，客户端仍可能依赖分散在各地的递归服务器；如果只统一递归入口，私有区域的配置、委派和故障处理依旧散落在不同环境中。Cloudflare Internal DNS 的核心价值，就是在同一个全球网络和控制平面上承载这两类职责。
统一控制面能改变哪些运维工作
当内部 DNS 与 Zero Trust、网络服务以及公共 DNS 运行在同一套控制平面上，团队可以围绕统一的网络边界设计解析路径。实际落地时，可以重点审视以下变化：
| 关注点 | 传统分散部署 | 统一后的目标状态 |
|---|---|---|
| 私有区域 | 分布在 VPC、机房或各业务团队 | 统一梳理区域、记录和所有权 |
| 递归入口 | 客户端按所在地使用不同解析器 | 按网络接入路径提供一致入口 |
| 故障排查 | 在 VPN、DNS 和云网络之间逐层检查 | 从统一控制面关联网络与解析问题 |
| 变更管理 | 多套系统分别修改 | 使用一致的审批、发布和回滚流程 |
这里需要注意一个边界：来源信息说明了产品的网络位置和控制面整合，但没有给出具体迁移 API、策略语法或客户端配置格式。因此，实施时应以当前账户中提供的配置界面和产品文档为准，不要根据公共 DNS 的接口推测 Internal DNS 的接口完全相同。
可以这样实践：先做可重复的解析验收
迁移内部 DNS 时，不要只用一次 nslookup 判断成功。可以建立一组固定探针，分别验证权威记录、递归解析、NXDOMAIN 行为和响应时间。
下面的 Bash 脚本可以直接运行。执行前，把 INTERNAL_DNS_IP、PRIVATE_NAME 和 EXPECTED_PRIVATE_IP 替换为测试环境中的实际值；脚本假设目标解析器可以通过 UDP/TCP 53 端口访问。
#!/usr/bin/env bash
set -euo pipefail
: "${INTERNAL_DNS_IP:=10.0.0.53}"
: "${PRIVATE_NAME:=api.corp.example}"
: "${EXPECTED_PRIVATE_IP:=10.20.30.40}"
: "${PUBLIC_NAME:=example.com}"
query_a() {
local server="$1"
local name="$2"
dig +time=2 +tries=1 +short "@${server}" "${name}" A
}
echo "[1/4] 检查私有权威记录"
actual_private_ip="$(query_a "${INTERNAL_DNS_IP}" "${PRIVATE_NAME}" | head -n1)"
if [[ "${actual_private_ip}" != "${EXPECTED_PRIVATE_IP}" ]]; then
echo "失败：${PRIVATE_NAME} 期望 ${EXPECTED_PRIVATE_IP}，实际 ${actual_private_ip:-<empty>}" >&2
exit 1
fi
echo "[2/4] 检查公共域名递归解析"
public_answer="$(query_a "${INTERNAL_DNS_IP}" "${PUBLIC_NAME}" | head -n1)"
if [[ -z "${public_answer}" ]]; then
echo "失败：${PUBLIC_NAME} 没有返回 A 记录" >&2
exit 1
fi
echo "[3/4] 检查不存在记录的状态码"
rcode="$(dig +time=2 +tries=1 "@${INTERNAL_DNS_IP}" \
"missing-${RANDOM}.${PRIVATE_NAME}" A +noall +comments \
| awk '/status:/ {gsub(/,/, "", $6); print $6}')"
if [[ "${rcode}" != "NXDOMAIN" ]]; then
echo "失败：期望 NXDOMAIN，实际 ${rcode:-<empty>}" >&2
exit 1
fi
echo "[4/4] 检查 TCP 查询"
dig +tcp +time=2 +tries=1 "@${INTERNAL_DNS_IP}" "${PRIVATE_NAME}" A +short >/dev/null
echo "通过：权威解析、递归解析、NXDOMAIN 和 TCP 查询均符合预期"
运行方式：
chmod +x verify-internal-dns.sh
INTERNAL_DNS_IP=10.0.0.53 \
PRIVATE_NAME=api.corp.example \
EXPECTED_PRIVATE_IP=10.20.30.40 \
./verify-internal-dns.sh
这类测试适合放入变更流水线，也可以从办公室、VPC、数据中心和远程接入网络分别执行。这样能区分“DNS 记录配置错误”和“客户端到解析器的网络路径不可达”。
客户端切换不宜一步到位
正式采用时，可以按区域或用户组逐步切换递归入口，并保留旧解析器用于短期回退。一个稳妥的检查清单包括：
- 盘点私有区域、反向解析区域、条件转发规则和记录所有者；
- 记录关键域名当前的 A、AAAA、CNAME、SRV、TXT 和 PTR 响应；
- 从每种网络接入方式验证 UDP 53、TCP 53、超时和缓存行为；
- 检查重叠命名空间，例如公共与私有环境同时存在的
example.com； - 为错误记录、解析超时和异常查询量建立监控；
- 预先定义回滚条件，避免在故障期间临时决定切换方案。
统一平台可以减少系统边界，但不会自动消除 DNS 本身的复杂性。私有区域的所有权、TTL、缓存、网络可达性和分阶段迁移仍然需要明确设计。更合适的采用路径是先选取一个低风险区域完成双路径验证，再逐步扩大到核心服务和更多网络位置。