US.KG FreeDomain 实战：将免费域名委托给外部权威 Name Server 并用 dig 完整验证 DNS 委托

本文讲解 DigitalPlat FreeDomain（US.KG 项目）的核心网络流程：注册得到的免费域名（如 example.dpdns.org）如何委托给外部权威 DNS 服务，包括创建外部 zone、完整复制分配的 nameserver、在 DigitalPlat 保存委托值，以及用 dig 从父区到子区逐层验证委托是否生效。读完本文，你将能够独立完成一次 nameserver 委托，并掌握区分"父区委托问题"与"子区配置问题"的排查手段。

产品边界：DigitalPlat 只负责注册与委托，不提供记录编辑器

1.3-connect-nameservers.md 开宗明义地说明了这一产品的架构定位：

DigitalPlat 将注册的域名委托给外部权威 DNS 服务（delegates the registered domain to an external authoritative DNS service），它不提供普通 DNS 记录的编辑器（It does not provide the editor for ordinary DNS records）。

这条边界决定了整个使用姿势：你在 DigitalPlat 上能操作的是"这个域名归哪些权威 nameserver 管理"，而不是"A 记录指向哪个 IP"。文档同时声明，DigitalPlat 不背书、不保证任何第三方 DNS 服务；教程中的截图仅以 Cloudflare 作为界面示例（The screenshots below use Cloudflare only as a short interface example），任何你自选的外部服务都可以。

产品边界章节 给出了完整的职责划分，值得在动手前读一遍：

• DigitalPlat（注册控制层）负责：账号注册与登录、域名可用性与注册、命名空间策略确认、外部权威 nameserver 提交、域名状态与到期信息、续费流程、注册人联系数据管理、产品公告。
• 外部权威 DNS 负责：托管 zone，并提供 nameserver。A、AAAA、CNAME、MX、TXT、CAA、SRV 等所有普通记录的编辑都在它的界面里完成。
• Web 主机负责：存放或运行网站，在 DNS 指向它之后接受 HTTP/HTTPS 连接。DigitalPlat 的注册流程不做上传代码、开端口、配反代、发证书、建邮箱这些事。

三者关系可以画成一条链：

DigitalPlat registration
  |
  | delegates the domain to external NS hostnames
  v
External authoritative DNS
  |
  | publishes A, CNAME, MX, TXT, and other records
  v
Website, email, and other services

以 example.dpdns.org 为例，完整流程是：DigitalPlat 记录该域名使用 ns1.dns-service.example 和 ns2.dns-service.example；外部 DNS 服务发布 example.dpdns.org 的 zone；你在该服务里创建 A 记录；浏览器解析记录后连上 Web 服务器。如果记录缺失，反复修改 DigitalPlat 的 nameserver 字段也不会凭空创建出记录来。

委托章节 进一步提出了理解委托的关键心智模型——同一个域名存在三个视角，三者必须足够一致，解析才能工作：

1. 注册视角（Registration view）：保存你提交的预期权威 nameserver 主机名；
2. 父区视角（Parent DNS view）：发布解析器实际遵循的委托信息；
3. 子区视角（Child authoritative view）：发布 zone 的 SOA、NS 和普通资源记录。

排障时，"注册里填的值"与"父区实际发布值"与"子区实际应答值"三者之间的差异，就定位到了故障层。

前置准备：注册前就要准备好外部 Nameserver

注册章节 指出，DigitalPlat 的注册流程可能要求提交权威 nameserver 主机名。因此正确顺序是先在外部的 DNS 服务里建好计划中的 zone，再复制全部分配的 nameserver，而不是注册完成后再补。其格式示例为：

ns1.dns-service.example
ns2.dns-service.example

文档反复强调：这些是主机名（hostname），既不是客户端 DNS 解析器地址，也不是网站 IP 地址。

另外两点准备工作：

• 先打开 Dashboard 的公告板（notice board）。支持的后缀、注册暂停、slot 要求、价格、限制、续费窗口与策略都可能变化，不要拿旧截图当当前可用性或费用的证明。
• 支持的命名空间包括 .DPDNS.ORG、.US.KG、.QZZ.IO、.XX.KG、.QD.JE（见 README），各后缀的注册条款以注册界面展示为准。

第一步：在外部 DNS 服务中创建 zone

原文档的"Create the External Zone"步骤很直接：

1. 在你选择的外部 DNS 服务注册账号；
2. 在外部服务中添加完整的域名（完整 FQDN，例如 example.dpdns.org，而不是只填前缀）；
3. 选择满足你自身需求的外部服务套餐（Choose an external service plan that meets your own requirements）。

原文档 此处以 Cloudflare 的三张截图演示了"注册账号 → 添加域名 → 选择套餐"的界面（图片见本文开头及 platform/imgs 目录）。注意两点：

• 截图中的套餐选择仅是界面演示。DigitalPlat 不背书、不保证任何第三方服务，选哪个服务、用哪个套餐由你自己的需求决定；
• 这一步的关键产出是：外部服务分配给这个 zone 的一组权威 nameserver 主机名（通常形如 ns1.xxx、ns2.xxx）。zone 建好之后，外部服务会明确列出这一组名字。

第二步：完整复制分配的 Nameserver

外部服务会分配权威 nameserver 主机名（The external service assigns authoritative nameserver hostnames）。原文档对此给出的硬性要求是：

逐字完整复制每一个主机名（Copy every hostname exactly）。 不要在 DigitalPlat 的 nameserver 字段里填入 IP 地址、公共解析器地址或任何 DNS 记录值（Do not enter an IP address, public resolver address, or DNS record value in the DigitalPlat nameserver field）。

这条要求背后的原理在 2.0 委托章节的"Do Not Mix Fields" 里讲得很清楚——以下几类东西分属不同上下文，填错位置就是最常见的配置事故：

Nameserver field: ns1.dns-service.example      <- 权威 nameserver 主机名（注册处/管理处填这个）
A record value:   192.0.2.10                    <- A 记录值（只属于外部 zone 编辑器）
CNAME value:      another-host.example          <- CNAME 目标（只属于外部 zone 编辑器）
Resolver address: an IP configured on a client  <- 客户端解析器地址（与注册完全无关）

另外，如果外部服务分配了多个 nameserver（通常是一对或一对以上），必须全部填入，只填其中一个是最常见的错误之一（见后文错误表）。

第三步：在 DigitalPlat 保存 Nameserver

原文档的"Save Nameservers in DigitalPlat"步骤给出两个时机：

• 注册时：在提交流程的 nameserver 字段中直接填入分配好的外部 nameserver 主机名（见文首 DigitalPlat 注册界面截图）；
• 注册后：通过可用的域名管理流程（domain management workflow）修改/更新。

保存前逐项核对（可结合 1.2 注册章节 的提交前检查清单）：完整域名的拼写、所选后缀、外部 nameserver 主机名（逐字、完整集合）、注册人信息、策略确认、Dashboard 显示的 slot 或扣费。注册会产生外部状态、可能消耗 slot 或产生费用，任何值不符合预期就停下来。

需要牢记的边界是：DigitalPlat 的责任止于委托（delegation）。委托之后，网站、邮件或验证记录都要回到外部 DNS 服务去创建，DigitalPlat 界面里找不到这些编辑器：

DigitalPlat's responsibility ends at delegation. After delegation, open the external DNS service to create website, email, or verification records.

用 dig 验证委托是否生效

保存 nameserver 不等于委托已生效——注册处保存的值要经过父区发布、各层级缓存刷新后才会体现在解析器实际遵循的路径上。原文档 给出了三条核心验证命令，命令参考 补充了更多细节，下面逐条展开。

1. 直接问父区：dig NS

dig NS example.dpdns.org

判断标准只有一条：ANSWER SECTION 中返回的 nameserver 必须与你在 DigitalPlat 里填入的外部 nameserver 完全一致（The answer must contain the same external nameservers entered in DigitalPlat）。

正常输出大致形如：

;; ANSWER SECTION:
example.dpdns.org.  86400  IN  NS  ns1.dns-service.example.
example.dpdns.org.  86400  IN  NS  ns2.dns-service.example.

若返回的是旧的 nameserver 集合，说明父区还在发布旧委托——要么注册处的值没改对，要么是委托变更还在缓存/传播中；若返回 NXDOMAIN 或 authority 段的 SOA 表明 zone 不存在，则问题在委托本身而非记录。

2. 追踪父区路径：dig +trace

dig +trace NS example.dpdns.org

+trace 从根服务器开始逐层记录查询路径，直到拿到该域名的 NS 集合。它的价值在于把"父区委托问题"和"子区问题"区分开（The trace helps distinguish a parent delegation problem from a child-zone problem）：

• 如果 trace 显示父区给出的 NS 集合就是你在 DigitalPlat 填写的值，但子区应答异常 → 问题在外部权威服务一侧；
• 如果 trace 在父区层级就看到了错误的 NS → 问题在注册/父区委托一侧。

3. 直接询问外部权威服务器

dig @ns1.dns-service.example SOA example.dpdns.org

@ns1.dns-service.example 让 dig 绕过一切缓存，直接向指定的外部权威服务器发起查询。这条命令回答的问题是"子区本身是否已经就绪"：

• 权威服务器应返回该 zone 的 SOA 记录，证明 zone 存在且被发布；
• 若权威服务器回答 NXDOMAIN / SOA 表明 zone 不存在，说明外部服务侧 zone 缺失——原文档错误表 里对应"Waiting when the external authoritative server has no zone / Fix the external zone first"一行；
• 建议对外部服务分配的每一台 nameserver 都各查一次（@ns2... 同理），确认多服务器数据已同步。2.0 委托章节 明确要求："An authoritative server must publish the zone before waiting for caching can help"——权威服务器必须先发布 zone，指望缓存等待是救不了缺失的 zone 的。

命令参考 还提供了两个实用变体：

dig +tcp @ns1.dns-service.example SOA example.dpdns.org   # 响应超过 UDP 限制时改用 TCP
dig +short NS example.dpdns.org                            # 精简输出，适合脚本

精简输出方便脚本使用，但会丢掉 flags、authority 段和 TTL 上下文；诊断阶段建议使用常规完整输出。

4. 保存诊断证据

排障时建议把时间戳和命令输出一起留档（来自 命令参考）：

{
  date -u
  dig NS example.dpdns.org
  dig A example.dpdns.org
  curl -I --max-time 15 https://example.dpdns.org
} > domain-diagnostic.txt 2>&1

分享前记得去掉个人数据、内部主机名、token 与 cookies。

常见错误与正确动作

原文档 的常见错误表是本章的精华，完整保留如下：

错误	正确动作
把服务器 IP 当作 NS 值填入	填入分配给你的权威 nameserver 主机名
在 DigitalPlat 里寻找 A 记录编辑器	打开外部 DNS zone
外部 zone 的域名拼写错误	在委托之前重建或修正外部 zone
多个分配的 nameserver 只填了一个	填入完整的分配集合
外部权威服务器上根本没有 zone 却在干等	先修好外部 zone

再结合 2.0 委托章节 的"委托失败模式"表，可以把观察到的现象直接映射到故障层：

现象	可能的故障层
父区指向旧的 NS 主机名	注册或父区委托
NS 主机名正确但查询超时	外部权威服务或网络
一台 nameserver 应答、另一台不应答	外部 DNS 同步或可用性问题
SOA 表示 zone 不存在	外部 DNS 服务缺少 zone
NS 正常但 A 记录为空	外部 zone 缺少普通记录

故障排查树 则给出了对应的决策路径：dig NS 是否显示预期的外部 nameserver？否 → 检查注册层 NS 值与委托缓存；是但记录不对 → 修外部 zone；NS 正确但记录缺失 → 在外部 zone 里补记录。

建议按 2.0 委托章节 的"证据工作表"格式记录每次验证，避免凭印象排障：

Expected external nameservers:
Observed delegated nameservers:
SOA answer from nameserver 1:
SOA answer from nameserver 2:
Time checked in UTC:
Next action:

委托生效需要等待：TTL 与缓存的边界

验证时一个高频困惑是"我刚改完 nameserver，为什么 dig NS 还是旧值？"。TTL 与传播章节 解释了原因：DNS 变更不会瞬间复制到每台设备，递归解析器会按记录的 TTL 缓存应答；负应答同样会被缓存，在有人查询过不存在名字之后立刻创建记录，部分解析器仍可能继续返回 NXDOMAIN 一段时间。

该章节给出的实操区分法值得直接套用——把"权威状态"与"缓存状态"分开验证：

dig @ns1.dns-service.example A example.dpdns.org   # 问权威服务器（权威状态）
dig A example.dpdns.org                            # 问本机配置的解析器（缓存状态）

如果权威应答是新值、递归应答是旧值，说明 zone 是对的，只是缓存仍有效——等待比反复改记录更安全。查看 TTL 剩余值可以用：

dig A example.dpdns.org +noall +answer

答案中 IN 前面的数字是剩余 TTL（秒）；若应答来自缓存，这个数字会在多次查询之间递减。委托类变更的等待期本质上由父区 NS 记录的 TTL 决定，dig +trace 观察到的值可作为参考。

延伸阅读

围绕"委托与 nameserver"这一主题，本仓库中以下文档可继续深入（路径均相对仓库根目录）：

• 2.0 Delegation and External Nameservers：委托三视角、失败模式与证据工作表的完整论述；
• 2.1 Record Types：委托生效后在外部 zone 里创建的各种记录；
• 2.3 TTL, Caching, and Propagation：缓存机制与 TTL 选择；
• 1.2 Domain Registration：注册流程中 nameserver 的提交时机；
• 1.4 Check Status and Renew：原文档指定的下一步，委托完成后的状态检查与续费；
• 5.3 Migrate Nameservers Safely：已运行域名的 nameserver 迁移（含旧 zone 清点、双 zone 并存与回滚）；
• 6.3 Command Reference：全部诊断命令速查。

注意两点适用前提：其一，nameserver 的具体字段与流程以 Dashboard 当前界面和公告为准，旧截图不能证明当前的可用性、限制或费用；其二，本文所有 dig 命令示例中的 example.dpdns.org、ns1.dns-service.example、192.0.2.10 均为文档占位示例，实际操作时请替换为你自己的域名、外部服务真实分配的 nameserver 主机名与服务器地址。