DNS 操作手册

查询失败、回答不同、修改尚未被看到，是三类问题。每次记录查询名、类型、所问服务器和时间，再比较权威、递归与系统解析路径。示例域名不用于真实变更。

当前任务	入口
域名解析失败	读完整响应
改了记录仍是旧 IP	权威与缓存
验证 DNSSEC / 加密 DNS	验证边界

排障时先别用 +short 隐藏状态

先读完整响应

# 查询当前配置的 DNS 服务器并保留响应头
dig example.com A

记录 status、flags、ANSWER、AUTHORITY、SERVER 和 Query time。下面是示例片段，TTL 300 的单位是秒，SERVER 才说明问了谁。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
www.example.com. 300 IN A 192.0.2.10
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

# 向指定递归器查询同一名字和类型
dig @1.1.1.1 example.com A +noall +comments +answer +authority +stats

@ 指定服务器；这组显示选项保留状态、回答、权威区和服务器统计，用来与上次结果比较，不改变解析记录。

按业务需要选择记录类型

# 查询 IPv6 地址记录
dig example.com AAAA

IPv4 正常但 IPv6 失败时，检查 AAAA 与实际 IPv6 路径；无 AAAA 不等于域名不存在。

# 读取邮件交换器与优先级
dig example.com MX

数字越小优先级通常越高；随后单独查询交换器主机的地址。TXT、CAA、CNAME 等同样按实际问题替换类型，不用 ANY 获取所谓全部记录。

# 把地址转换为反向 DNS 名称查询 PTR
dig -x 192.0.2.10

IP 替换为实际目标；PTR 与正向 A/AAAA 分别维护，不能用其中一个证明另一方向已配置。

确认应用是否走同一解析路径

# 通过 Linux NSS 获取应用常用的地址结果
getent ahosts example.com

结果可能来自 hosts、DNS 或其他 NSS 模块；与 dig 不同应先查来源。应用也可能自带解析器或使用 DoH。

# 在使用 systemd-resolved 的主机查看解析结果与链路
resolvectl query example.com

不使用 resolved 的系统无需执行；配合 resolvectl status 看每链路 DNS 和路由域。

响应	含义与下一步
NOERROR + answer	查询得到记录，仍核对 CNAME 链、类型、TTL 和 SERVER
NOERROR + empty answer	可能是该类型无数据（NODATA）、转介等；读 authority，不等同域名不存在
NXDOMAIN	所问解析视图认为该名字不存在，留意负缓存
SERVFAIL	服务器未能完成查询；可能 DNSSEC、权威不可达等，非直接证明域名不存在
timeout	没有及时收到回复；查路径、UDP/TCP 53、服务及超时设置

dig 直接问 DNS；getent 经过系统 NSS，可能包含 hosts 等来源；resolvectl 适用于 systemd-resolved。它们不是完全相同的路径。+short 适合已确认状态后的提取。ANY 不保证返回全部记录；按 A/AAAA/CNAME/MX/TXT/NS/SOA/CAA 等实际问题指定类型。

TTL 属于各缓存条目，不是全球倒计时

正在呈现知识画面

先确认权威，再比较缓存

# 查找目标区域的权威服务器线索
dig example.com NS

对子域还需确认是否另有委派；不能因为父域 NS 存在就默认它负责所有子域。

# 直接向已确认权威服务器查询目标记录
dig @ns1.example.com www.example.com A +norecurse

替换服务器名并检查 aa 标志、SOA/委派信息；无 aa 先确认问对区域。多台权威需要分别核对，排除部署不同步。

# 比较指定递归器的答案与剩余 TTL
dig @1.1.1.1 www.example.com A

记录查询时间；权威已更新而递归仍旧，可能等待旧 TTL 到期。负缓存也会延迟新建记录可见性。

# 沿委派链定位根、父区与子区之间的断点
dig +trace www.example.com A

需要本机能直接访问各级 DNS；它不复现企业转发器、分域配置或目标递归器的缓存。

只在证据指向本机缓存时刷新

# 清空本机 systemd-resolved 的缓存
sudo resolvectl flush-caches

这是可选修复，不是每次查询的前置步骤。执行后重做 resolvectl query 和实际应用请求；其他递归器、浏览器、容器的缓存不会因此消失。

ns1.example.com 替换为实际权威服务器；核对 AA、委派与目标区域。+trace 从根迭代查询，不复现生产递归解析器的缓存/转发/分视图路径。各地答案不同可来自 GeoDNS、分视图、缓存、轮转或故障，不能仅凭不同就判定污染。降低 TTL 必须等旧 TTL 的缓存退出后才对已有缓存有效；负回答也可被缓存。

改记录前保存身份，改完分层验证

云平台操作先读取 zone/record ID、RR、Type、Value、TTL 与线路，保存旧值。按记录 ID 更新，避免无意新增同名记录；Alibaba Cloud 的 UpdateDomainRecord 同时需要 RR、Type、Value，不能只给 Value。TXT 尤其可能有多条业务验证值，不覆盖整组。API 返回成功后，依次查权威、目标递归解析器和实际应用。

只在确认本机缓存是问题时使用 resolvectl flush-caches；它不会清空 ISP、浏览器、容器或其他递归器的缓存。ACME DNS-01 还需核对委派、TXT 名和值，见 证书。

加密传输与 DNSSEC 验证分开看

请求 DNSSEC 记录与自行验证是两件事

# 设置 DO，要求返回相关 DNSSEC 数据
dig @1.1.1.1 example.com A +dnssec

读 RRSIG 等记录和 ad 标志；dig 本身不会因此验证信任链。

# 使用本地验证器检查 DNSSEC 结果
delv example.com A

检查 validated / unsigned / validation failure 的区别；先确保时钟、信任锚和网络正常。未签名区域与签名损坏不是同一结果。

比较传输方式时保持问题一致

# 用 TCP 53 对照 UDP 查询
dig @1.1.1.1 example.com A +tcp

UDP 超时而 TCP 成功时查防火墙、分片与路径；TCP DNS 本身不是加密 DNS。

# 通过 DoT 查询，并核验服务器证书与名称
kdig @1.1.1.1 example.com A +tls +tls-ca +tls-hostname=cloudflare-dns.com

+tls 使用 TLS，+tls-ca 检查信任链，+tls-hostname 指定应匹配的身份。握手失败先查端口、时间与证书，不通过关闭校验掩盖问题；协议能力按提供商文档确认。

kdig 需安装 Knot 工具并支持 TLS；目标服务能力以提供商文档为准。+dnssec 设置 DO 请求 DNSSEC 相关记录，不让 dig 自己验证链。AD 表示该解析器声称已验证，信任它还依赖可信传输与解析器；delv 自行验证并依赖正确的信任锚和时钟。DoT/DoH/DoQ 保护传输，不自动证明所查询区域启用 DNSSEC；不要把任意 DNS IP 当作支持所有加密协议。

BIND dig/delv · DNS negative caching RFC 2308 · Alibaba UpdateDomainRecord · Cloudflare DoT