US.KG 免费域名实战命令参考：dig、curl 与 openssl 全链路诊断

DigitalPlat FreeDomain（US.KG）教程的进阶部分（Part 6）中，命令参考 汇集了从域名委派验证到 TLS 证书检查的完整命令行工具箱。本篇以该参考文档为主体，逐组展开 dig、curl、openssl、nc、ss/lsof 等诊断命令的参数含义、适用场景与判读方法，并结合书中 DNS 委派、故障排查、HTTPS、邮件 DNS 等章节补充每条命令背后的原理与上下文。读完后，你可以对已注册的 .US.KG、.DPDNS.ORG 等免费域名独立完成一次从注册层委派到应用层响应的端到端体检，并把诊断结果安全地整理成可分享的证据文件。

适用前提：先替换示例名

参考文档开篇即强调：使用这些命令之前，先替换示例中的域名和文档地址。文中所有命令使用两类占位符：

• example.dpdns.org：代表你在 DigitalPlat FreeDomain 上注册的域（例如你的 .US.KG 域名）；
• ns1.dns-service.example：代表你在注册平台配置的外部权威 DNS 服务器主机名（参见 委派与外部名称服务器 中"注册视图、父级 DNS 视图、子域权威视图"三视图一致的要求）。

直接照抄占位符执行没有意义，务必替换为真实值后再运行。

验证域名委派：dig NS、+trace 与 SOA

dig NS example.dpdns.org
dig +trace NS example.dpdns.org
dig SOA example.dpdns.org

• dig NS example.dpdns.org 通过普通递归解析器查询该域委派给哪些权威服务器，返回的 NS 集合应当与注册平台中配置的外部 DNS 服务一致；
• dig +trace NS example.dpdns.org 从根服务器逐层跟踪解析路径，用于区分"父级委派问题"和"子域问题"——如果父层指向了旧的 NS 主机名，问题在注册层或父级委派；如果 NS 主机名正确但查询超时，问题在外部权威服务或网络（对照 委派故障模式表 逐层定位）；
• dig SOA example.dpdns.org 查询起始授权机构记录，它是区域（zone）存在的标志：如果 SOA 返回区域不存在，说明该区域在外部 DNS 服务上缺失，此时"等待传播"不会修复权威答案错误（参见 DNS 故障排查 第 4 步的判断逻辑）。

这三条命令构成排障的"第 2 步：检查父级委派"与"第 3 步：逐台检查权威服务器"的基础。

直连权威服务器查询

绕过递归缓存，直接问权威服务器要答案：

dig @ns1.dns-service.example SOA example.dpdns.org
dig @ns1.dns-service.example A example.dpdns.org
dig +tcp @ns1.dns-service.example SOA example.dpdns.org

• @ns1.dns-service.example 把查询目标指向指定的权威服务器；多台权威服务器应逐一查询（例如再加一条 @ns2...），所有权威服务器都应当回答同一个区域。如果各服务器返回不同序列号或长期不一致，说明 DNS 服务的区域同步出了问题（DNS 故障排查 第 3 步）；
• +tcp 强制使用 TCP 而非默认的 UDP 发送 DNS 查询。自托管权威 DNS 一章节指出：TCP 不是可以忽略的可选回退，大响应、区域传输和协议行为都可能依赖它，因此权威 DNS 必须同时应答 53 端口的 UDP 和 TCP，+tcp 命令正是验证 TCP 通道的标准手段。

网站记录检查：A、AAAA、CNAME 与 CAA

dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
dig CAA example.dpdns.org

• A 与 AAAA 分别验证 IPv4 与 IPv6 解析。DNS 故障排查 特别提到"只有部分用户看到新网站"的常见原因之一就是 IPv4 和 IPv6 指向了不同服务器，因此两条都要查；
• CNAME www.example.dpdns.org 验证 www 别名指向。注意常见误区：www 的 CNAME 不会自动配置根域名，"www 能打开但根域名打不开"时必须检查根域名的 A/AAAA 记录以及 Web 服务器接受的主机名列表；
• CAA 查询证书颁发机构授权记录。启用与验证 HTTPS 在证书申请前要求确认"任何 CAA 记录都允许你所使用的证书颁发机构"，这条命令就是验证手段。

邮件记录检查：MX 与三类 TXT

dig MX example.dpdns.org
dig TXT example.dpdns.org
dig TXT selector1._domainkey.example.dpdns.org
dig TXT _dmarc.example.dpdns.org

这四条命令覆盖 邮件 DNS：MX、SPF、DKIM 与 DMARC 的全部验证点：

• MX 验证收信路由，较低优先级数字优先尝试，目标应是主机名而非 IP；
• 域根上的 TXT 对应 SPF 策略（v=spf1 ...）——每个名称只应发布一条 SPF 策略，且要留意嵌套 include 带来的 DNS 查询次数限制；
• selector1._domainkey 下的 TXT 是 DKIM 公钥记录，selector1 需替换为邮件系统实际给出的选择器；私钥永远留在发信系统，绝不放入 DNS；
• _dmarc 下的 TXT 是 DMARC 策略，建议从不了解全部合法发信源的监控策略（p=none）起步，待报表确认对齐后再逐步收紧。

精简输出：+short 的便利与代价

dig +short A example.dpdns.org
dig +short NS example.dpdns.org

+short 只输出答案主体，便于在脚本中解析。参考文档给出了明确的使用边界：精简输出虽然方便脚本，但丢掉了 flags、authority 段和 TTL 等诊断上下文，排障时应使用普通输出。这一点很关键——判断缓存剩余时间、负缓存、委派胶水记录等信息都需要完整输出。

HTTP 与重定向检查

curl -I http://example.dpdns.org
curl -I https://example.dpdns.org
curl -L -o /dev/null -s -w '%{http_code} %{url_effective}\n' http://www.example.dpdns.org

• curl -I 只取响应头（HEAD 请求），用于快速确认 HTTP/HTTPS 服务是否可达、返回的状态码与跳转目标，是 DNS 故障排查 中"DNS 正确但网站打不开"场景的第一手证据；
• 第三条命令的 -L 跟随重定向链，-o /dev/null -s 丢弃正文并静默，-w '%{http_code} %{url_effective}\n' 最终只打印状态码和落地 URL——这是把"重定向是否正确一次到达目标 HTTPS 主机名"（HTTPS 最终检查清单 的要求）变成一行可脚本化判定的标准写法。

DNS 生效前测试虚拟主机

域名解析还未指向新服务器时，也可以先验证服务器上的虚拟主机配置：

curl -I -H 'Host: example.dpdns.org' http://192.0.2.10
curl --resolve example.dpdns.org:443:192.0.2.10 -I https://example.dpdns.org

• 第一条命令用 Host 头手动指定虚拟主机名，直接请求目标 IP（192.0.2.10 为文档地址，需替换），可提前发现 Web 服务器未接受该主机名的问题；
• 第二条用 --resolve 让 curl 在本地把主机名固定解析到指定地址再发起 HTTPS 请求。参考文档指出，该 HTTPS 命令会在连接指定地址的同时按主机名验证证书——这意味着你可以在 DNS 切换前就确认证书与虚拟主机都已就绪，避免"解析切过去才发现配置不对"的切换事故。这是 网站架构模式 中"迁移时保持边界、小步验证"思路的具体落地。

检查 TLS 证书

完整握手输出：

openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null

</dev/null 防止命令在交互等待中输入卡住；-servername 设置 SNI，让多虚拟主机服务器返回正确的证书。

证书字段摘要（日常使用更推荐这条，输出紧凑可复制）：

openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

该管道将握手输出经 openssl x509 过滤，只保留主题（subject）、颁发者（issuer）、有效期（dates）和 SAN 扩展四段信息。对照 HTTPS 验证清单：证书必须覆盖所有对外提供 HTTPS 服务的主机名，且能被自动续期；监控与事故响应 也要求对"证书过期、主机名不匹配、无效链"设置告警，这条摘要命令正是这类监控任务的基础。

查看本地监听端口

确认 80/443 等端口确实被目标进程监听：

Linux：

sudo ss -lntup

macOS：

lsof -nP -iTCP -sTCP:LISTEN

两条命令分别基于 ss 与 lsof，只列出处于 LISTEN 状态的 TCP 监听；-p 关联进程、-n/-nP 跳过反解以便快速阅读。当 dig A 返回的地址正确但端口不通时，先用这两条命令排除"进程没起、绑错地址（如只绑了 127.0.0.1）或防火墙拦截"这类本机问题。

Web 服务器状态与日志

sudo nginx -t
systemctl status nginx --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager

• sudo nginx -t 在重载配置前做语法与配置测试（HTTPS 章节 中"测试配置后再 reload"即此命令）；
• systemctl status nginx --no-pager 查看服务运行状态，--no-pager 避免输出被分页器挂起；
• journalctl -u nginx --since '30 minutes ago' --no-pager 拉取最近 30 分钟的服务日志。

这三条命令对应 服务器加固与运维 所在运维章节中"DNS 只负责定位服务器，后续要检查服务器进程、防火墙、虚拟主机、证书与应用日志"的排障顺序（参见 DNS 故障排查 的"DNS 正确但网站打不开"小节）。

端口连通性：nc -vz

nc -vz example.dpdns.org 80
nc -vz example.dpdns.org 443

-vz 表示详细模式 + 仅探测不发送数据：TCP 三次握手成功即报告可达并退出。参考文档特别强调一个判断边界：TCP 连接成功不能证明 HTTP、TLS 或应用本身是正确的——端口通只是 监控与事故响应 中"DNS 解析 → TCP 连接 → TLS 验证 → HTTP 返回预期状态码"用户路径上的第二环，后续环节仍需 curl 与 openssl 逐一确认。

保存诊断输出

把多个命令的结果一次性归档到文件：

{
  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

花括号块依次执行：先记录 UTC 时间戳（跨时区协同时可精确定位"何时改的、改前 TTL 是多少"），再抓取委派、解析与 HTTP 响应头，--max-time 15 防止 curl 卡死整个采集过程，2>&1 保证错误信息一并落盘。

分享前务必审阅文件，删除个人数据、内部主机名、令牌、Cookie 等敏感内容——这与 DNS 故障排查 "求助前先收集证据"清单的要求一致：准确的主机名与记录类型、dig NS 输出、权威直连结果、期望与实际值、变更时间与旧 TTL、相关时的 curl -I 状态码。

组合成诊断流程：从委派到应用

参考文档的各命令组并非孤立清单，按 DNS 故障排查 的五步法串起来即是一条完整的诊断链：

1. 确认名称与类型：dig A www.example.dpdns.org（检查拼写、重复后缀、记录类型）；
2. 检查父级委派：dig +trace NS example.dpdns.org 对照注册层配置的 NS 集合；
3. 逐台检查权威服务器：dig @ns1... SOA / dig @ns2... SOA，比较序列号一致性；
4. 直连查询记录：dig @ns1.dns-service.example A www.example.dpdns.org，权威答案错了就改区域，而不是等待传播；
5. 比较递归答案：在本地解析器与第二个解析器之间对比，TTL 过渡期内出现不同缓存值是正常现象。

确认 DNS 链路无误后，再沿用户路径向下走：nc -vz（TCP）→ curl -I（HTTP/HTTPS）→ openssl s_client（证书）→ 本地 ss/lsof 与 nginx -t/journalctl（服务器侧）。参考文档中"权威答案错误时等待传播不会修复问题"的原则贯穿全程——每一步的判断依据都来自该层命令的实际输出。

相关文档

• 命令参考原文
• 委派与外部名称服务器
• DNS 故障排查
• 自托管权威 DNS
• 启用与验证 HTTPS
• 邮件 DNS：MX、SPF、DKIM 与 DMARC
• 网站架构模式
• 监控与事故响应