当遭遇DNS污染、缓存投毒、重放攻击、流量放大攻击等事件时，DNS 日志是最关键的取证材料及问题定位依据。许多运维人员在排查网络异常时往往忽略 DNS 维度，而深入分析DNS Query、Response、Flags、Rcodes、TTL、Upstream 等信息，往往可以精确判断污染来源、攻击类型以及潜在的安全隐患。利用 DNS 日志进行排查的核心是建立“正常行为基线”，再从异常查询模式、异常返回 IP、响应延迟抖动、查询源分布变化和协议参数偏移中定位问题。不同解析架构的日志格式略有差异，但分析逻辑具有共性。

　　在分析DNS污染时，首先关注的通常是返回结果的可信度。如果一个请求返回的 A 记录或 CNAME 来自非预期 IP 段，即便查询成功也极可能是链路被污染。例如用户本应访问 172.67.xx.xx，但日志出现 37.xx.xx.xx、203.xx.xx.xx 等陌生地址，并且 TTL 异常偏短或偏长，都可能表示解析链路被强制插入伪造响应。常见污染手法包括基于 UDP 的本地注入、运营商出口干扰、跨境链路劫持等，它们都会留下典型特征：相同 Query 在短时间内被多次应答、Flags 中 AD 位缺失、Authority Section 意外出现本地区域伪造 SOA 信息、Response size 异常偏小或偏大、DNSSEC 验证失败。因此，首先通过日志检索异常 IP 或异常 TTL 是定位污染的关键。

　　一次典型的日志分析流程，可以从记录 DNS Server 内部 Query/Response 行为开始。下面是 CoreDNS 或 Bind 通常会输出的查询记录示例：

28-Nov-2025 11:21:35.123 client @0x7fbdc8000abc 192.168.1.10#52768 (example.com): query: example.com IN A +E (192.168.1.53)
28-Nov-2025 11:21:35.226 client @0x7fbdc8000abc 192.168.1.10#52768 (example.com): reply: example.com IN A 159.223.xx.xx 300

　　如果遭遇污染，日志可能表现如下：

28-Nov-2025 11:21:35.223 unexpected answer example.com A from 37.xx.xx.xx, TTL=5, QR=1, AA=0, AD=0

　　伪造应答通常 TTL 很低(例如 1、5、10)，并且 DNSSEC 的 AD 标志为 0。通过比对真实权威服务器返回的 TTL，可以直接识别链路层注入行为。

　　若目标是排查缓存投毒攻击，可以关注 DNS Server 内部的缓存写入日志以及随机端口、查询 ID 的一致性。攻击者尝试通过伪造响应抢先于真正权威服务器返回数据，因此在日志中会出现相同 Query ID、相同域名的瞬时重复应答冲突。Bind 会输出类似：

named[1528]: validation failure <api.example.com A>: unexpected answer from 203.xx.xx.xx
named[1528]: error (unexpected RCODE SERVFAIL) resolving 'api.example.com/A'

　　如果不断看到验证失败、unexpected answer、bad cache entry 等提示，就应检查随机端口是否被固定、是否启用了 DNSSEC、是否启用了 0x20 位混淆等防御措施。

　　当 DNS 服务器遭受 DoS 或流量放大攻击时，日志的模式变化十分明显。短时间内 QPS 会急速上升，绝大部分请求来源于随机 IP，查询内容多为不存在的子域名、TXT 大记录或 ANY 查询。例如攻击者构造以下行为：

random12345.example.com ANY
dkfjskdfj11.example.com TXT

　　日志会呈现大量 NXDOMAIN 或 REFUSED 响应，同时 CPU 飙升、延迟上升。如果是递归服务器遭受放大利用，还可能出现：

large response size 3500 bytes sent to spoofed IP

　　这意味着攻击者使用伪造源地址的请求，使你的 DNS Server 成为放大源。

　　在排查 DNS 级别攻击时，还需要根据源 IP 分布分析异常。正常情况下，用户的来源应该集中在少量地区、固定网段出口，而攻击流量会呈现全球随机化分布。如果部署了 Unbound，可利用 querylog 工具导出数据，再进行统计分析：

unbound-control dump_requestlist
grep "example.com" /var/log/unbound.log | awk '{print $6}' | sort | uniq -c | sort -nr | head

　　如果某个 IP 在一分钟内发出上千条查询，或仅查询相同子域名、相同类型的记录，则基本可判定为恶意探测或 DoS。

　　对于链路层 DNS 污染，还可以结合 tcpdump 进行验证，因为伪造响应往往会“抢答”，比真实权威服务器更先返回：

tcpdump -nvvv -i eth0 port 53 and host example.com

　　若发现来自陌生地址的响应先于真实权威服务器返回，并且 Query ID 相同，就是典型的本地注入污染。

　　如果 DNS 服务器部署了 DNSSEC，日志中关于验证失败的信息极具价值。DNSSEC 可以识别所有未经签名的伪造响应，因此污染链路常会导致 SERVFAIL、验证失败、签名过期等报错。用户可能认为网站无法访问，但真实原因是链路被污染而 DNSSEC 阻断了响应。日志会出现：

dnssec: signature validation failed for example.com RRSIG: bad signature

　　这是强有力的证据，能用于判断污染是否存在。

　　在排查 CDN 类域名解析异常时，还必须比对不同上游或公共 DNS 的返回结果。若某地运营商出口被污染，用户解析会被重定向到错误的 IP。日志分析可从以下几方面验证：不同递归服务器的响应是否一致、同一 Query 是否在某地区返回特定黑洞地址(通常为 37/8、45/8、109/8 等常见污染 IP)、TTL 是否统一、是否存在丢包或超时。特别是以下日志模式值得警惕：

query timed out to 8.8.8.8#53
unexpected RCODEnxdomain from 114.xx.xx.xx

　　这意味着上游 DNS 已遭受干扰。

　　完成初步分析后，需要建立分析链，明确事件来源。若污染发生在本地网络，应检查路由器是否中毒、是否存在 DNS 劫持、是否被强制转发 53 端口;若污染发生在运营商层面，则应切换 DoT/DoH 或使用加密隧道;若为攻击事件，则需增加限速、启用响应策略、禁止 ANY 查询、开启 RRL、启用 DNS Cookie 等。

　　最后，通过 DNS 日志排查污染和攻击事件的核心能力，是从海量数据中识别异常模式、构建基线并结合链路特性推断问题来源。DNS 日志不是孤立数据，需要同时结合网络抓包、服务器资源监控和外部公共 DNS 返回结果，才能完成完整的定位链路。掌握日志分析后，DNS 不再是黑盒，而是可以被精准观察、快速处置的可控系统。