US.KG 免费域名实战命令参考dig、curl 与 openssl 全链路诊断【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KGDigitalPlat FreeDomainUS.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 与 SOAdig NS example.dpdns.org dig trace NS example.dpdns.org dig SOA example.dpdns.orgdig 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.orgns1.dns-service.example把查询目标指向指定的权威服务器多台权威服务器应逐一查询例如再加一条ns2...所有权威服务器都应当回答同一个区域。如果各服务器返回不同序列号或长期不一致说明 DNS 服务的区域同步出了问题DNS 故障排查 第 3 步tcp强制使用 TCP 而非默认的 UDP 发送 DNS 查询。自托管权威 DNS 一章节指出TCP 不是可以忽略的可选回退大响应、区域传输和协议行为都可能依赖它因此权威 DNS 必须同时应答 53 端口的 UDP 和 TCPtcp命令正是验证 TCP 通道的标准手段。网站记录检查A、AAAA、CNAME 与 CAAdig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org dig CAA example.dpdns.orgA与AAAA分别验证 IPv4 与 IPv6 解析。DNS 故障排查 特别提到只有部分用户看到新网站的常见原因之一就是 IPv4 和 IPv6 指向了不同服务器因此两条都要查CNAME www.example.dpdns.org验证www别名指向。注意常见误区www的 CNAME 不会自动配置根域名www 能打开但根域名打不开时必须检查根域名的A/AAAA记录以及 Web 服务器接受的主机名列表CAA查询证书颁发机构授权记录。启用与验证 HTTPS 在证书申请前要求确认任何 CAA 记录都允许你所使用的证书颁发机构这条命令就是验证手段。邮件记录检查MX 与三类 TXTdig MX example.dpdns.org dig TXT example.dpdns.org dig TXT selector1._domainkey.example.dpdns.org dig TXT _dmarc.example.dpdns.org这四条命令覆盖 邮件 DNSMX、SPF、DKIM 与 DMARC 的全部验证点MX验证收信路由较低优先级数字优先尝试目标应是主机名而非 IP域根上的TXT对应 SPF 策略vspf1 ...——每个名称只应发布一条 SPF 策略且要留意嵌套 include 带来的 DNS 查询次数限制selector1._domainkey下的TXT是 DKIM 公钥记录selector1需替换为邮件系统实际给出的选择器私钥永远留在发信系统绝不放入 DNS_dmarc下的TXT是 DMARC 策略建议从不了解全部合法发信源的监控策略pnone起步待报表确认对齐后再逐步收紧。精简输出short 的便利与代价dig short A example.dpdns.org dig short NS example.dpdns.orgshort只输出答案主体便于在脚本中解析。参考文档给出了明确的使用边界精简输出虽然方便脚本但丢掉了 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.orgcurl -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头手动指定虚拟主机名直接请求目标 IP192.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 等端口确实被目标进程监听Linuxsudo ss -lntupmacOSlsof -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-pagersudo 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 -vznc -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 21花括号块依次执行先记录 UTC 时间戳跨时区协同时可精确定位何时改的、改前 TTL 是多少再抓取委派、解析与 HTTP 响应头--max-time 15防止 curl 卡死整个采集过程21保证错误信息一并落盘。分享前务必审阅文件删除个人数据、内部主机名、令牌、Cookie 等敏感内容——这与 DNS 故障排查 求助前先收集证据清单的要求一致准确的主机名与记录类型、dig NS输出、权威直连结果、期望与实际值、变更时间与旧 TTL、相关时的curl -I状态码。组合成诊断流程从委派到应用参考文档的各命令组并非孤立清单按 DNS 故障排查 的五步法串起来即是一条完整的诊断链确认名称与类型dig A www.example.dpdns.org检查拼写、重复后缀、记录类型检查父级委派dig trace NS example.dpdns.org对照注册层配置的 NS 集合逐台检查权威服务器dig ns1... SOA/dig ns2... SOA比较序列号一致性直连查询记录dig ns1.dns-service.example A www.example.dpdns.org权威答案错了就改区域而不是等待传播比较递归答案在本地解析器与第二个解析器之间对比TTL 过渡期内出现不同缓存值是正常现象。确认 DNS 链路无误后再沿用户路径向下走nc -vzTCP→curl -IHTTP/HTTPS→openssl s_client证书→ 本地ss/lsof与nginx -t/journalctl服务器侧。参考文档中权威答案错误时等待传播不会修复问题的原则贯穿全程——每一步的判断依据都来自该层命令的实际输出。相关文档命令参考原文委派与外部名称服务器DNS 故障排查自托管权威 DNS启用与验证 HTTPS邮件 DNSMX、SPF、DKIM 与 DMARC网站架构模式监控与事故响应【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/6 23:07:06 · 阅读 1.2k US.KG 免费域名实战命令参考：dig、curl 与 openssl 全链路诊断
US.KG 免费域名实战命令参考dig、curl 与 openssl 全链路诊断【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KGDigitalPlat FreeDomainUS.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 与 SOAdig NS example.dpdns.org dig trace NS example.dpdns.org dig SOA example.dpdns.orgdig 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.orgns1.dns-service.example把查询目标指向指定的权威服务器多台权威服务器应逐一查询例如再加一条ns2...所有权威服务器都应当回答同一个区域。如果各服务器返回不同序列号或长期不一致说明 DNS 服务的区域同步出了问题DNS 故障排查 第 3 步tcp强制使用 TCP 而非默认的 UDP 发送 DNS 查询。自托管权威 DNS 一章节指出TCP 不是可以忽略的可选回退大响应、区域传输和协议行为都可能依赖它因此权威 DNS 必须同时应答 53 端口的 UDP 和 TCPtcp命令正是验证 TCP 通道的标准手段。网站记录检查A、AAAA、CNAME 与 CAAdig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org dig CAA example.dpdns.orgA与AAAA分别验证 IPv4 与 IPv6 解析。DNS 故障排查 特别提到只有部分用户看到新网站的常见原因之一就是 IPv4 和 IPv6 指向了不同服务器因此两条都要查CNAME www.example.dpdns.org验证www别名指向。注意常见误区www的 CNAME 不会自动配置根域名www 能打开但根域名打不开时必须检查根域名的A/AAAA记录以及 Web 服务器接受的主机名列表CAA查询证书颁发机构授权记录。启用与验证 HTTPS 在证书申请前要求确认任何 CAA 记录都允许你所使用的证书颁发机构这条命令就是验证手段。邮件记录检查MX 与三类 TXTdig MX example.dpdns.org dig TXT example.dpdns.org dig TXT selector1._domainkey.example.dpdns.org dig TXT _dmarc.example.dpdns.org这四条命令覆盖 邮件 DNSMX、SPF、DKIM 与 DMARC 的全部验证点MX验证收信路由较低优先级数字优先尝试目标应是主机名而非 IP域根上的TXT对应 SPF 策略vspf1 ...——每个名称只应发布一条 SPF 策略且要留意嵌套 include 带来的 DNS 查询次数限制selector1._domainkey下的TXT是 DKIM 公钥记录selector1需替换为邮件系统实际给出的选择器私钥永远留在发信系统绝不放入 DNS_dmarc下的TXT是 DMARC 策略建议从不了解全部合法发信源的监控策略pnone起步待报表确认对齐后再逐步收紧。精简输出short 的便利与代价dig short A example.dpdns.org dig short NS example.dpdns.orgshort只输出答案主体便于在脚本中解析。参考文档给出了明确的使用边界精简输出虽然方便脚本但丢掉了 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.orgcurl -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头手动指定虚拟主机名直接请求目标 IP192.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 等端口确实被目标进程监听Linuxsudo ss -lntupmacOSlsof -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-pagersudo 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 -vznc -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 21花括号块依次执行先记录 UTC 时间戳跨时区协同时可精确定位何时改的、改前 TTL 是多少再抓取委派、解析与 HTTP 响应头--max-time 15防止 curl 卡死整个采集过程21保证错误信息一并落盘。分享前务必审阅文件删除个人数据、内部主机名、令牌、Cookie 等敏感内容——这与 DNS 故障排查 求助前先收集证据清单的要求一致准确的主机名与记录类型、dig NS输出、权威直连结果、期望与实际值、变更时间与旧 TTL、相关时的curl -I状态码。组合成诊断流程从委派到应用参考文档的各命令组并非孤立清单按 DNS 故障排查 的五步法串起来即是一条完整的诊断链确认名称与类型dig A www.example.dpdns.org检查拼写、重复后缀、记录类型检查父级委派dig trace NS example.dpdns.org对照注册层配置的 NS 集合逐台检查权威服务器dig ns1... SOA/dig ns2... SOA比较序列号一致性直连查询记录dig ns1.dns-service.example A www.example.dpdns.org权威答案错了就改区域而不是等待传播比较递归答案在本地解析器与第二个解析器之间对比TTL 过渡期内出现不同缓存值是正常现象。确认 DNS 链路无误后再沿用户路径向下走nc -vzTCP→curl -IHTTP/HTTPS→openssl s_client证书→ 本地ss/lsof与nginx -t/journalctl服务器侧。参考文档中权威答案错误时等待传播不会修复问题的原则贯穿全程——每一步的判断依据都来自该层命令的实际输出。相关文档命令参考原文委派与外部名称服务器DNS 故障排查自托管权威 DNS启用与验证 HTTPS邮件 DNSMX、SPF、DKIM 与 DMARC网站架构模式监控与事故响应【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考