US.KG 实战指南：域名所有权验证记录（TXT/CNAME）与 SRV 服务记录的配置与清理

本篇基于 US.KG 教程文档 Verification and Service Records 展开，讲解如何为外部权威 DNS 区域正确添加域名所有权验证记录（TXT 与 CNAME）和服务发现记录（SRV），完整覆盖记录格式、dig 验证方法、安全的七步验证工作流以及旧记录的安全清理与文档化实践。读完本篇后，你可以独立完成各类第三方服务的域名归属验证，理解验证记录的生命周期管理，并能判断哪些记录可以安全删除、哪些必须永久保留。

验证记录应该加在哪里：先厘清注册平台与权威 DNS 的边界

US.KG 项目的核心场景是：通过 DigitalPlat 免费注册一个 .us.kg 域名，然后将其委派给外部的权威 DNS 服务（如 Cloudflare 或自托管 DNS）。产品边界文档 明确指出，DigitalPlat 只负责注册层——账户管理、域名注册、外部权威域名服务器提交、域名状态与续期、注册人数据管理等；它不提供 A、AAAA、CNAME、MX、TXT、CAA、SRV 等记录的编辑器。

这意味着一个最常见的操作错误是：在 DigitalPlat 控制台里找验证记录入口。正确的工作关系如下（摘自 1.0-product-boundaries.md）：

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

因此本篇讨论的所有验证与服务记录，一律添加到你实际托管区域（zone）的外部权威 DNS 服务中。域名与 DNS 基础 还提醒了一个容易踩的命名陷阱：DNS 编辑器对区域顶点（apex）的表示可能是 @、空白字段或完整域名（如 example.dpdns.org）。如果向一个会自动拼接区域名的字段里手动输入完整域名，会生成重复后缀的名称（例如 issued-label.example.dpdns.org.example.dpdns.org），导致验证失败——这一点在 DNS 故障排查 的 NXDOMAIN 一节中被列为典型原因之一。

TXT 验证记录

许多外部服务（SaaS 平台、邮件系统、证书签发方等）会要求你添加一条 TXT 记录来证明对域名的控制权。标准格式如下：

Name:  @
Type:  TXT
Value: service-verification=issued-token

其中 Name: @ 表示记录建在区域顶点（即你的 .us.kg 域名本身），issued-token 是服务方签发的令牌。需要注意两点：

• 令牌本质上是公开可读的。它通过 DNS 发布，任何递归解析器都能查到，服务方在设计时就是把它当作"公开证明"使用的；因此不要因为它出现在 DNS 里就误以为自己泄露了机密。
• 但仍应只把它添加到服务指定的精确名称上。不要顺手加到其他主机名，也不要把它和同名的其他 TXT 记录随意合并——DNS 记录类型文档 对 TXT 记录的通用规则是：照抄验证值（Copy verification values exactly），除非服务文档明确要求，否则不要合并独立的 TXT 记录。

添加完成后，直接向权威名称服务器查询验证：

dig TXT example.dpdns.org

若希望排除本地递归解析器缓存的干扰，可以直接指定权威服务器查询（@ns1.dns-service.example 替换为你实际的权威服务器主机名）：

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

这种"直问权威"的方式是 TTL、缓存与传播 中推荐的排查手段：如果权威答案是新的而递归答案还是旧的，说明区域本身是正确的，等待缓存过期比反复编辑记录更安全。

CNAME 验证记录

另一类常见的验证方式是 CNAME：服务方签发一个标签（label）和目标主机名，要求你在指定位置建立 CNAME 指向它。示例格式：

Name:  issued-label
Type:  CNAME
Value: issued-target.service.example

这里有一条硬性约束：不要在与该 CNAME 相同的主机名上创建任何其他记录。这与 DNS 记录类型文档 中 CNAME 一节的原则一致——一个带 CNAME 的名称通常不能再有其他记录类型（如 A、AAAA、TXT 等）并存。违反这一点会导致区域数据在部分权威服务器或解析器上产生冲突或验证不通过。

验证命令：

dig CNAME issued-label.example.dpdns.org

SRV 服务发现记录

除了验证用途的记录，区域中还存在一类供网络应用进行服务发现的 SRV 记录。SRV 记录把"某个服务"映射到具体的主机名与端口，客户端应用通过查询它来定位服务实例。完整格式包含四个字段：

Name:     _service._tcp
Type:     SRV
Priority: 10
Weight:   5
Port:     443
Target:   host.example.dpdns.org

各字段的作用：

字段	作用
Priority	选择优先目标。优先级数值更小的目标被优先使用
Weight	在优先级相同的目标之间按权重分配流量
Port	服务端口号
Target	服务所在主机名。目标必须能解析出地址记录（A/AAAA），否则发现成功也连不上

记录名遵循 _service._tcp（或 _service._udp）的下划线前缀约定：服务名在前、传输协议在后，全部小写。SRV 记录同样在外部权威 DNS 服务中创建——在 US.KG 的产品边界文档 列出的外部 DNS 负责管理的记录类型清单里，SRV 与 A、CNAME、MX、TXT、CAA 并列。它也是名称服务器迁移清单 中明确要求盘点和迁移的记录类型之一：迁移区域时漏掉一条 SRV 记录，可能导致网站正常但某个依赖服务发现的应用中断。

验证命令：

dig SRV _service._tcp.example.dpdns.org

安全的验证工作流

原文档给出了七步验证工作流，把它当作标准操作规程执行，可以避免绝大多数验证失败与安全隐患：

1. 确认你登录的是目标服务的正确账户。
2. 逐字读取要添加的记录名称、类型和值——不要凭记忆或截图转述。
3. 检查 DNS 界面是否会自动拼接区域名。这是重复后缀问题的唯一来源，见上文 0.6-domain-and-dns.md 中关于 apex 表示的说明。
4. 保存记录。
5. 直接向权威名称服务器查询，确认权威答案正确（而不是查本地递归解析器）。
6. 只有当 DNS 已返回期望值后，才去请求服务方执行验证。顺序反了（先点验证再等 DNS）是"验证失败"工单的主要原因之一。
7. 记录该验证记录是否需要永久保留。有些记录验证通过即可删除，有些（如部分证书签发方、服务集成方）要求长期存在——这直接决定了后文的清理策略。

关于第 5 步的"直接查询"，可以组合使用 DNS 故障排查 中的分层检查方法：先 dig +trace NS example.dpdns.org 确认委派指向了正确的权威服务器，再用 dig @ns1.dns-service.example <记录名> <类型> 直问权威服务器。这样能把"区域数据错"和"缓存未过期"两类问题干净地分开。

谨慎清理旧记录

验证记录有一个生命周期特征：它们可能比创建它们的账户或集成存活得更久。账户注销了、集成废弃了，但 TXT 验证记录还留在区域里。原文档的建议是：定期审查区域记录，但在确认一条陌生记录的归属和用途之前，不要删除它。

对每条服务记录建立如下文档条目（可直接用作检查表）：

• 服务归属方（Service owner）：这条记录是哪个服务/团队/人员创建的；
• 记录用途（Record purpose）：所有权验证、服务发现、邮件策略集成还是其他；
• 创建日期；
• 验证通过后是否允许移除；
• 移除的预期影响：删除后哪个功能会受影响，是否有服务方在持续查询该记录。

这套"先识别、后动手"的原则与 名称服务器迁移 中"迁移前先盘点全区域记录并识别每条记录归属方"的做法一脉相承——同一份盘点习惯，既服务于迁移，也服务于日常清理。

最后一条安全红线值得单独强调：对于通过不可信消息（邮件、聊天、工单）收到的"添加一条 DNS 记录"要求，必须先在目标服务已登录的界面上独立核实，再执行添加。攻击者若能诱导你在区域中添加指定的 CNAME 或 TXT 记录（例如把子域 CNAME 指向攻击者控制的域），就可能劫持依赖该记录的服务；5.3 迁移章节 中"任何 ANY 查询都不可靠、应使用官方导出接口"的告诫，本质上也是同一类数据完整性问题。

与邮件 DNS 记录的区分

本部分（Part 4）的姊妹章节 Email DNS: MX, SPF, DKIM, and DMARC 处理的是邮件专用记录（MX 路由、SPF/DKIM/DMARC 策略），而本篇聚焦的是通用验证与服务发现记录。两者都建在外部权威 DNS 中，但用途与生命周期不同：邮件认证记录必须与邮件系统签发的值严格一致，验证记录则随服务集成状态而增减。Part 4 索引 特别提醒：不要照抄示例中的邮件记录值上生产区域，必须使用你选定的邮件系统签发的精确值。

小结与下一步

本篇覆盖的要点可以归纳为四组可执行动作：

1. 添加：TXT 验证记录只放到指定名称、值逐字照抄；CNAME 验证记录所在名称不得再放其他记录；SRV 记录的 Target 必须可解析出地址。
2. 验证：保存记录后先直问权威服务器（dig @ns1...），确认权威答案正确，再触发服务方的验证动作。
3. 文档化：为每条服务记录记录归属方、用途、创建日期、可否移除与移除影响。
4. 清理：定期盘点区域，删除前必须先确认归属；对不可信渠道发来的加记录指令，先认证界面核实。

完成记录层工作后，继续 Part 5: Operate the Domain，学习域名管理、续期、注册数据与安全加固等运维主题。