Cloudflare DNS、域名所有权与安全机制

1. DNS 的权威委派链

全球 DNS 系统是分级委派的：

根服务器（Root Server）
↓ 委派 TLD 给注册局
注册局（Registry，如 Verisign 管理 .com）
↓ 根据 NS 记录委派给权威 DNS
权威 DNS 服务器（如 Cloudflare、AWS Route53 等）
↓ 响应具体的 DNS 查询（A、CNAME、MX 等）

• 根服务器 → 把 .com / .cn 等顶层域委派给注册局
• 注册局 → 把你买的域名委派给注册商设置的 NS 记录指向的服务器
• 你的 NS 服务器 → 实际响应域名下所有 DNS 查询

2. NS 的作用与原理

当你把域名的 NS 记录改成 Cloudflare 的 NS 地址，本质是告诉注册局："这个域名的权威 DNS 由 Cloudflare 负责"。自此，所有关于该域名的 DNS 查询（A/CNAME/MX/TXT 等）都会被引导到 Cloudflare，Cloudflare 即可自由配置全部记录，包括自动签发 SSL（通过 DNS-01 或 HTTP-01 验证域所有权）。

谁控制 NS，谁就控制这个域名的 DNS 和证书（如果开启自动签发）。

3. Cloudflare NS 分配与鉴权机制

NS 名称的分配

• Cloudflare 有一个有限的 NS 名称池（几十对名称，如 hera.ns.cloudflare.com, elliott.ns.cloudflare.com）
• 添加域名时，Cloudflare 从池中选一对分配给该域名
• NS 名称不是每个账户不同，也不是每个域名强制唯一——不同账户下的不同域名可能拿到相同的 NS 对
• NS 名称只是路由标识，指向共享的 Cloudflare 权威 DNS 基础设施

域名添加与验证流程

用户在 Cloudflare 添加 example.com
↓
CF 内部数据库登记：example.com → 账户 A → 分配 NS: hera/elliott
状态: pending（待验证）
↓ （展示 NS 名称给用户，让用户去注册商修改）
用户去注册商把 NS 改成 hera/elliott
↓
CF 定时扫描公共 DNS，检测到 example.com 的 NS = hera/elliott
↓
CF 在自己的 pending 列表中找到 example.com 属于账户 A
↓
标记为 Active ✅ 证明用户同时控制了 CF 账户和注册商

鉴权本质

不是 NS 名称本身鉴权，而是 "改 NS 这个行为"鉴权：

• 域名在 CF 内全局唯一：一个域名一旦被某账户添加（即使 pending），其他账户无法再添加
• 改 NS 需要注册商权限：只有域名真正的主人才能改 NS 记录
• CF 验证 NS 匹配 = 验证"发起添加的人 = 能操作注册商的人"

共享 NS 名称不会导致越权

即使两个域名（连同不同账户）用同一对 NS 名称，不会互相影响：

| 场景 | 结果 |

|------|------|

| 到 CF Dashboard 添加别人的域名 | ❌ 提示"已被其他账户添加" |

| CF DNS 服务器收到别人的域名查询 | ✅ 正常返回对方的 DNS 记录 |

| 修改自己账户下的 DNS 记录 | ✅ 只影响自己的域名 |

原因：DNS 查询到达 Cloudflare 时，内部按查询的域名本身路由到对应账户的配置，不是按 NS 名称或 IP。

预设置攻击防御

如果域名在注册商改 NS 但尚未添加到 CF：

第三方尝试添加该域名到自己的 CF 账户
↓
CF 检测到 NS 已指向 CF，但系统内无此域名记录
↓
❌ 不通过 NS 认证，要求替代验证（TXT 记录 / HTTP 文件上传）

单靠改 NS 无法完成"抢占"。

4. Cloudflare 的 Anycast 路由

Cloudflare 的 NS 名称（如 hera.ns.cloudflare.com）解析到 Anycast IP（如 108.162.192.162）：

• 全球所有 CF 用户共享这些 IP（Anycast 技术）
• 用户查询时被路由到最近的 CF 边缘节点
• 边缘节点检查 DNS 查询包的 qname（被查询的域名）
• 查内部数据库找到该域名的 zone 配置

用户的 DNS 查询（example.com） → 公共 Anycast IP → 最近的 CF 边缘节点
↓
边缘节点查看查询的域名
↓
查内部 DB → example.com 的 DNS 配置

NS 名称 → IP 这一步是共享的，区分谁是谁全靠 DNS 查询包里的域名本身。

5. 注册局 vs 注册商 vs 用户

层级关系

注册人（你）
↓ UI/API
注册商（Registrar，如 Namecheap、GoDaddy、Cloudflare）
↓ 通过 EPP 协议（Extensible Provisioning Protocol）
注册局（Registry，如 Verisign 管理 .com）
↓
权威数据库（最终数据源）

谁管什么

| 操作 | 谁修改 | 说明 |

|------|--------|------|

| 改 NS 记录 | 注册商 → EPP → 注册局 | 注册局更新全球根区 |

| 域名锁（Transfer Lock） | 注册商 → EPP → 注册局 | 锁状态存注册局 |

| 获取 EPP 码 | 注册商 → EPP → 注册局 | 转出必需的授权码 |

| 更新注册人信息 | 注册商 → EPP → 注册局 | 需要验证邮箱 |

| DNS 解析记录（A/CNAME） | DNS 服务器 | 注册局不关心具体解析记录 |

注册局的权威性

注册局持有核心数据：域名状态、NS 记录、注册人信息、到期日、EPP 码。注册商只是管理界面/代理，通过 EPP 协议发指令给注册局，注册局校验权限后写入数据库。注册商没有独立于注册局的数据副本。

证据：不同注册商查同一域名的 whois 数据完全一致（均来自注册局）。注册商删库也不影响域名存在。

6. 域名转移保护

ICANN 强制转移流程

域名解锁（用户在注册商后台操作） + 获取 EPP 码 → 在新注册商发起转移
↓
注册人邮箱收到确认邮件（必须点击同意/拒绝）
↓
默认 5 天 ICANN 锁定期（可拒绝转移）

• 注册商无法绕过注册人邮箱确认
• 转移操作有完整审计日志，注册局可追溯
• 受 ICANN 认证监管，违规操作导致吊销资质

域名锁

域名默认 Registrar Lock（Transfer Lock），锁着的域名注册商的后台系统也无法直接发起转移。

真实的"域名被转移"场景

通常不是注册商私自操作，而是注册商账号被盗：

攻击者登录你的注册商账户 → 关锁 → 拿 EPP 码 → 发起转移

防御措施：双重认证 + 开启域名锁 + 确保注册邮箱安全。

7. WHOIS 与隐私保护

查询方式

whois <domain>

查询结果直接来自注册局的权威数据库。

GDPR 后的变化

GDPR 生效后，ICANN 实施临时规范，注册人的真实信息在公共 WHOIS 中红化：

Registrant Email: DATA REDACTED
Registrant Name: DATA REDACTED

注册局确实存着真实注册人邮箱（用于转移确认、到期通知等），但公众不可查。

可查询真实信息的主体

• 注册商（通过自身后台查看）
• 执法/法院（向注册局调取）
• 域名争议场景（走 UDRP 程序，注册局配合披露）

公共 WHOIS 只能查到 abuse@cloudflare.com 等代理邮箱。

8. 注册商中间人风险

理论风险

注册商给你展示的邮箱是"你的"，但提交给注册局的邮箱可以是注册商自己的。由于 WHOIS 已红化，用户无法从公开渠道核对注册局的真实记录。

实际约束

1. ICANN 年度验证：注册商必须每年验证注册人联系信息有效性。违反 RAA（注册商协议）会被吊销资质。

2. 转移操作会暴露：拿 EPP 码和转移确认邮件都会发到注册局记录的邮箱。如果是注册商的邮箱，用户察觉不到这些操作。

3. UDRP 仲裁可调取原始数据：一旦闹到仲裁，注册局的真实记录和注册商的不一致，注册商面临灭绝性风险。

4. 大注册商信誉成本极高：为几个域名冒险等于拿公司牌照开玩笑。

结论

技术可行，但只可能发生在小型/无良注册商身上。Namecheap、Cloudflare、GoDaddy 等大型注册商（全球前 5~10 位，持 ICANN 认证）不值得冒这个风险。注册商的信誉是最后一道防线。

9. 关键安全原则总结

| 原则 | 说明 |

|------|------|

| 控制 NS = 控制 DNS + 证书 | 谁控制权威 DNS 服务器，谁就能任意配置解析记录和签发证书 |

| NS 名称不是凭证 | NS 只是路由标识，内部按域名本身路由配置 |

| 改 NS 的行为才是鉴权 | CF 通过验证 NS 更改来证明你对注册商的控制权 |

| 注册局是最终真相源 | 注册商只是代理，核心数据在注册局 |

| 域名锁 + 2FA 是你的防线 | 注册商内部作恶概率极低，账号被盗才是常见风险 |

| 大注册商靠信任生存 | 小注册商需谨慎选择，ICANN 认证和运营时长是关键指标 |