MyNote

外观

DNS 名称解析、缓存与安全 ​

内容摘要：域名系统（Domain Name System，DNS）是分层、分布式、可缓存的命名数据库。浏览器输入 URL 后，应用通常先经本机 stub resolver 查询递归解析器；缓存未命中时，递归解析器沿根、顶级域和权威服务器迭代查询。本章讲清名称空间、区域、委派、DNS 报文、常见资源记录、TTL 与负缓存、UDP/TCP/DoT/DoH、DNSSEC，并给出解析慢、NXDOMAIN、SERVFAIL、污染与缓存不一致的证据链。

难度：高级　|　前置知识：07 IP 编址、12 UDP、13 TCP　|　所属层次：应用层

一、DNS 解决什么问题 ​

DNS 把层次化名称映射为带类型的数据：

text
www.example.com. → A/AAAA 地址
example.com.     → MX 邮件交换器
_sip._tcp.example.com. → SRV 服务位置

它不是单一服务器或全球强一致数据库，而是：

  • 层次化名称空间：根 .、顶级域 .com、二级域 example.com。
  • 分布式管理：父区通过 NS/DS 把子树委派给子区。
  • 按类型查询：同一个名称可有 A、AAAA、MX、TXT 等不同 RRset。
  • 最终传播 + 缓存：权威数据是源，递归解析器按 TTL 缓存副本。

域、区域与委派不是一回事 ​

术语含义
域（domain）名称空间中的一个节点及其后代
区域（zone）某权威服务器负责的一段连续名称空间
区域顶点（zone apex）区域最上层名称，如 example.com.
委派（delegation）父区用 NS 记录把子域管理权交给子区
胶水记录（glue）父区为委派 NS 提供必要的 A/AAAA，打破解析循环

域可以包含被再次委派出去的子域，但父区不再权威管理子区内部数据。

二、解析参与者 ​

角色主要职责是否通常缓存
应用发起名称解析；浏览器还可能维护独立缓存可能
Stub Resolver把查询交给配置的递归解析器实现相关
递归解析器代表客户端完成查询、缓存、可能做 DNSSEC 验证是
权威服务器返回自己负责区域的权威数据或委派不把递归缓存当权威答案
根/TLD 服务器提供下一层委派权威数据

/etc/hosts、mDNS、企业内部搜索域等可能在 DNS 前后参与名称服务。应用调用 getaddrinfo() 的结果不一定只来自 DNS；排障时不能只执行一次 dig 就断言应用实际解析链路相同。

三、递归查询与迭代查询 ​

客户端通常向递归解析器提出“请给最终答案”的递归查询；递归解析器向权威体系逐级进行迭代查询。

1、缓存未命中 ​

2、缓存命中 ​

DNS 头标志常见含义：

  • RD（Recursion Desired）：请求递归。
  • RA（Recursion Available）：服务端提供递归。
  • AA（Authoritative Answer）：答案来自该区域权威服务器。
  • AD（Authenticated Data）：验证解析器认为数据通过 DNSSEC 验证。
  • CD（Checking Disabled）：客户端要求上游关闭验证检查。

AA=0 不代表答案错误，递归缓存答案通常不是权威响应；AD=0 也不能直接证明 DNSSEC 失败，可能是查询链路或解析器不提供验证结果。

四、DNS 报文结构 ​

DNS 请求与响应共享 12 字节固定头，后接四个可变区段：

1、头字段 ​

字段位宽语义抓包显示常见异常
ID16 位UDP 查询/响应关联标识dns.id猜测 ID 参与投毒
QR1 位0 查询、1 响应dns.flags.response—
OPCODE4 位标准查询等操作类型dns.flags.opcode不支持返回 NOTIMP
AA1 位权威答案dns.flags.authoritative把缓存答案误当权威
TC1 位响应被截断dns.flags.truncated应重试 TCP
RD/RA各 1 位请求/支持递归dns.flags.recdesired/recavail公网开放递归风险
AD/CD各 1 位DNSSEC 已验证/关闭检查dns.flags.authenticated信任边界误判
RCODE4 位基础值NOERROR/NXDOMAIN/SERVFAIL 等dns.flags.rcode需结合区段判断
QD/AN/NS/ARCOUNT各 16 位四区段记录数量dns.count.*计数与长度不一致

2、Question 与 Resource Record ​

Question：

text
QNAME | QTYPE | QCLASS

资源记录（Resource Record，RR）：

text
NAME | TYPE | CLASS | TTL | RDLENGTH | RDATA

同一 NAME + TYPE + CLASS 的多条记录组成 RRset；DNSSEC 对 RRset 签名，而不是随意对单条记录签名。

五、常见资源记录 ​

IANA DNS Parameters 于 2026-08-11 更新，以下 TYPE 均按注册表核验：

类型作用示例工程注意
AIPv4 地址www 300 IN A 192.0.2.10可有多条，不保证客户端轮询方式
AAAAIPv6 地址www 300 IN AAAA 2001:db8::10双栈选择见 08
CNAME别名指向规范名称api CNAME edge.example.net.CNAME owner 通常不能同时有其他普通数据；区域顶点不宜配置传统 CNAME
NS区域权威服务器example.com. NS ns1.example.net.委派处可能需要 glue
SOA区域起始与序列/定时参数serial refresh retry expire minimumMINIMUM 参与负缓存语义
MX邮件交换器及优先级10 mail.example.com.目标应是名称，不是 CNAME/裸 IP
TXT文本数据SPF、域所有权验证单字符串长度与整条记录编码有限制
SRV服务位置、端口、权重_sip._tcppriority/weight 不是普通 DNS 轮询
PTR反向名称10.2.0.192.in-addr.arpa.正反向一致需分别维护
CAA限制可签发证书的 CA0 issue "ca.example"CA 授权约束，不替代证书校验
DS/DNSKEY/RRSIGDNSSEC 信任链、密钥、签名—见第九节
SVCB/HTTPS服务参数与替代端点ALPN、端口、地址提示RFC 9460；客户端支持仍有版本差异

TXT 不是任意大对象存储；超大 RRset 增加分片、TCP 回退和放大风险。配置前应测实际响应大小和路径 MTU（09）。

六、TTL、缓存与负缓存 ​

TTL（Time to Live）由权威数据发布者设置，递归缓存通常按秒递减。

1、TTL 不是绝对失效承诺 ​

不得把 TTL 解释为“全球所有客户端一定保留这么久”或“到点立刻全部更新”：

  • 浏览器、应用、操作系统和递归服务器可能有多层缓存。
  • 实现可能设置最小/最大缓存 TTL、预取、serve-stale 等策略。
  • 连接池可能继续使用已解析 IP，不会因 DNS TTL 到期主动断开。
  • 缓存开始时间不同，各地剩余 TTL 不同。
  • 修改记录前已缓存的旧 TTL 仍然有效；临时调低 TTL 需提前一个旧 TTL 周期。

2、负缓存 ​

RFC 2308 定义对不存在结果的缓存：

  • NXDOMAIN：名称不存在。
  • NODATA：名称存在，但查询类型不存在，通常表现为 NOERROR + Answer 为空。
  • 负缓存 TTL 与权威区 SOA 相关，不是简单沿用查询名称的普通 RR TTL。

本机查询保留域 .invalid 的真实结果：

text
status: NXDOMAIN
flags: qr rd ra
ANSWER: 0, AUTHORITY: 1
. 962 IN SOA a.root-servers.net. ... 86400
Query time: 86 msec

该 TTL 是查询时的剩余值；不同时间、解析器策略可能不同。

七、RCODE 与失败路径 ​

状态含义常见根因
NOERROR + Answer正常答案—
NOERROR + 空 AnswerNODATA、CNAME 链或委派信息需结合 Authority 看查询类型不存在
NXDOMAIN查询名称不存在拼写错误、记录删除、错误搜索域
SERVFAIL服务器未能完成解析DNSSEC 验证失败、权威超时、委派循环、内部错误
REFUSED服务器按策略拒绝未授权递归/区域传送
FORMERR报文格式错误EDNS/中间盒/客户端实现问题
NOTIMP不支持操作OPCODE/功能不支持

八、UDP、TCP、EDNS、DoT 与 DoH ​

IANA 服务注册表：

协议端口/传输用途
传统 DNS53/UDP 与 53/TCP普通查询、TCP 回退、区域传送
DNS over TLS（DoT）853/TCPDNS 封装于 TLS（RFC 7858）
DNS over HTTPS（DoH）通常 443/TCP 或 QUIC每个 DNS 查询映射为 HTTPS 交换（RFC 8484）
DNS over QUIC（DoQ）853/UDPDNS over QUIC（RFC 9250）

1、UDP 和 TCP ​

  • 传统 DNS 优先使用 UDP，不建立连接、开销低。
  • 原始 DNS UDP 上限为 512 字节；EDNS(0) 用 OPT 伪 RR 宣告更大接收能力。
  • 响应设置 TC=1 时，客户端应使用 TCP 重试。
  • TCP 不只是“超 512 字节备用”：RFC 7766 要求通用 DNS 实现支持 TCP，DNSSEC、区域传送和多查询复用都会使用。
  • 宣告过大 EDNS UDP payload 可能造成 IP 分片；现代实践常保守使用约 1232 字节，具体见 RFC 8900/路径实测。

本机同一查询的单次观测：

text
UDP A 查询：27 ms
TCP A 查询：54 ms

差异包含缓存时刻、TCP 建连和瞬时网络变化，不能推广成固定“TCP 多 27ms”。

2、DoT 与 DoH ​

DoT/DoH 提供客户端到所选递归解析器之间的机密性与完整性，防止普通旁路观察或篡改该链路；它们不自动解决：

  • 递归解析器本身的日志、隐私与信任问题。
  • 递归到权威链路是否加密。
  • 权威数据真实性（由 DNSSEC 解决）。
  • 恶意域名、钓鱼内容或应用层授权。

DoH 与普通 HTTPS 共用 443，易穿过网络但也让企业 DNS 策略、故障定位和流量治理更复杂。DoH 的 DNS RCODE 与 HTTP 状态码是两层：一个合法的 NXDOMAIN DNS 响应仍可使用 HTTP 200 承载。

九、DNSSEC ​

DNS Security Extensions（DNSSEC）为 DNS RRset 提供数据来源认证、完整性和可验证的不存在证明，不提供机密性。

记录/标志作用
DNSKEY区域公开验证密钥
DS父区保存对子区 DNSKEY 的摘要，连接信任链
RRSIG对 RRset 的数字签名
NSEC/NSEC3认证名称/类型不存在
DOEDNS 标志，请求返回 DNSSEC 数据
AD验证解析器告知客户端数据已验证
CD客户端要求上游关闭验证

DNSSEC 运维失败常见为：

  • 签名过期但未续签。
  • KSK/ZSK 轮换顺序错误。
  • 父区 DS 与子区 DNSKEY 不匹配。
  • 系统时间错误导致签名“未生效/已过期”。
  • 大响应因 MTU/防火墙丢失。

DNSSEC 验证失败通常对客户端表现为 SERVFAIL；应使用验证解析器日志、dig +dnssec 和链路工具交叉确认。

本机 dig cloudflare.com A +dnssec 显示 EDNS DO，但响应没有 AD。这只证明请求了 DNSSEC 数据；当前本地转发器没有向该查询声明验证成功，不能由此断言目标区域未签名。

十、从 URL 到 DNS 结果 ​

输入 https://www.example.com/docs?q=dns 后，在 TCP/TLS 之前可能发生：

完整分阶段实测放在 17 HTTPS 建连全过程；DNS 阶段只负责获得候选服务端信息，不保证 TCP、TLS、HTTP 或业务可用。

十一、最小可复现实验 ​

1、查询 A、AAAA 与 NS ​

环境：macOS 26.6.2，DiG 9.10.6，2026-09-07，仅查询文档域名。

bash
dig example.com A +noall +answer +stats
dig example.com AAAA +noall +answer +stats
dig example.com NS +noall +answer +stats

真实输出节选：

text
example.com. 164  IN A    104.20.23.154
example.com. 164  IN A    172.66.147.243
example.com. 236  IN AAAA 2606:4700:10::ac42:93f3
example.com. 236  IN AAAA 2606:4700:10::6814:179a
example.com. 7491 IN NS   elliott.ns.cloudflare.com.
example.com. 7491 IN NS   hera.ns.cloudflare.com.
SERVER: 127.0.0.1#53

TTL、地址和时延是动态观测，不应写入程序常量。

2、观察迭代路径 ​

bash
dig example.com A +trace +nodnssec

本机真实输出先出现 13 个根 NS，再出现 .com 权威 NS，随后到目标区域委派。+trace 由本机直接执行迭代查询，可能被企业网络、防火墙或 DNS 劫持阻断；它与应用使用的递归解析器路径不同。

3、抓包 ​

需授权和抓包权限，当前环境未执行：

bash
sudo tcpdump -i any -nn -s 0 -w dns-query.pcap \
  '(udp port 53 or tcp port 53) and host 192.0.2.53'

Wireshark：

text
dns
dns.flags.rcode != 0
dns.flags.truncated == 1
dns.qry.name == "example.com"

PCAP 可能包含用户访问域名，必须按 20 的授权、脱敏和销毁规则处理。

十二、安全风险与加固 ​

风险利用条件影响加固
缓存投毒可伪造响应并猜中查询关联信息域名指向恶意地址DNSSEC 验证、源端口/ID 随机化、最小化附加数据
反射放大公网开放递归/权威响应大、源 IP 可伪造DDoS禁止开放递归、RRL、BCP 38、DNS Cookie
DNS 污染/劫持路径上可观察或篡改明文 DNS返回错误地址DoT/DoH 保护到递归端；DNSSEC 验证数据
区域传送泄露AXFR 未限制暴露内部名称资产TSIG/ACL，仅允许授权 secondary
随机子域攻击大量唯一名称绕过缓存权威/递归资源耗尽限速、最小响应、容量与异常检测
Dangling DNSCNAME 指向已释放云资源子域接管资产回收联动、持续验证目标所有权

DNSSEC 与加密 DNS 是互补关系：

text
DNSSEC：这份数据确实由被信任的区域签名，且未被篡改
DoT/DoH：客户端到递归解析器的查询内容不被普通旁路读取/修改

十三、排障清单 ​

  1. 明确应用实际查询的名称、类型、搜索域和解析器。
  2. 区分应用缓存、OS 缓存、递归缓存和权威数据。
  3. 对比 dig @递归 与 dig @权威，不要只查公共解析器。
  4. 记录 RCODE、AA/RD/RA/AD/TC、Answer/Authority、剩余 TTL。
  5. 同时验证 UDP/53 与 TCP/53；大响应失败重点检查 MTU/分片。
  6. SERVFAIL 时验证 DNSSEC 链、委派和系统时间。
  7. 多地域问题对比不同递归解析器、Anycast 路径和权威日志。
  8. 记录变更前 TTL、变更时间和各缓存开始时间，不用“已经过 TTL”一句话结束分析。

十四、版本与平台差异 ​

  • Linux systemd-resolved、macOS mDNSResponder、Windows DNS Client 的缓存和 split DNS 行为不同。
  • dig 直接发送 DNS 协议查询，不必经过应用使用的 NSS/浏览器解析链。
  • 浏览器可能启用 DoH、HTTPS RR 和独立缓存；具体行为随版本、策略和网络发现机制变化。
  • EDNS payload、serve-stale、prefetch、QNAME minimization 等为实现/配置行为，应查目标解析器版本。

十五、关联章节 ​

检索关键词 ​

DNS 名称空间 区域 委派 stub resolver recursive resolver authoritative DNS 递归查询 迭代查询 DNS 报文头 RD RA AA TC AD CD A AAAA CNAME MX NS TXT SRV PTR SOA CAA DNS TTL 缓存 DNS 负缓存 NXDOMAIN NODATA EDNS OPT 1232 DNS TCP 回退 DoT DoH DoQ DNSSEC DS DNSKEY RRSIG NSEC DNS SERVFAIL 排障 DNS 缓存投毒 放大攻击

权威来源 ​

DNS 协议、RR TYPE 与端口已于 2026-09-07 对照 RFC Editor 和 IANA 注册表核验。dig 的 A/AAAA/NS、NXDOMAIN、TCP 与迭代查询已在本机真实执行；抓包因当前无免密抓包权限而标记为未执行。

ICP 备案号待补充 · Gitee 主页

Copyright © 2024-2026 MyNote