Linux系统DNS异常高频请求排查需先用tcpdump捕获UDP 53流量确认现象，再通过ss/lsof定位进程、resolvectl statistics分析查询统计，结合journalctl查看systemd-resolved日志，重点检查hostname配置缺失、/etc/resolv.conf search冗余、/etc/nsswitch.conf hosts顺序错误及监控脚本轮询等典型根因。
Linux 系统频繁向 DNS 服务器发送无效请求，通常不是“DNS 本身出错”，而是某个进程、服务或配置在持续发起无意义、重复、错误或无法响应的查询。这类行为会导致网络负载升高、DNS 服务器压力增大，甚至触发防火墙限流或被上游拦截。排查关键在于定位源头 + 判断请求性质 + 验证是否真“无效”。
查看实时 DNS 流量，确认是否真存在高频请求
先用 tcpdump 抓取 UDP 53 端口的出向 DNS 查询，避免依赖缓存或日志延迟：
sudo tcpdump -i any -n port 53 and udp and src host $(hostname -I | awk '{print $1}') -c 20关注输出中的：
- 查询域名（如
xxx.invalid、localhost.localdomain、空字符串、超长随机名） - 查询类型（大量
PTR反向解析？AAAA但无 IPv6 环境？） - 目标 DNS IP（是否指向不可达地址或内网不存在的服务？）
若看到大量NXDOMAIN或SERVFAIL响应，或同一域名每秒查多次，基本可判定为异常请求。
检查哪些进程在发 DNS 请求
现代 Linux 多数 DNS 请求经 systemd-resolved 或 glibc 发起，直接查进程较难，需结合工具：
- 使用
ss+lsof定位活跃 UDP 53 连接源：sudo ss -unp | grep ':53' | grep -v '@' # 排除 Unix socket sudo lsof -iUDP:53
- 若使用
systemd-resolved，查看其活动查询：resolvectl statistics # 显示总查询数、缓存命中率、失败数 resolvectl query example.com # 触发一次并观察日志
- 启用
systemd-resolved调试日志（临时）：sudo systemctl edit systemd-resolved # 加入： [Service] Environment=SYSTEMD_RESOLVE_LOG_LEVEL=4 sudo systemctl restart systemd-resolved journalctl -u systemd-resolved -f --since "1 min ago"
日志中会显示每个查询的来源 PID、UID、域名和结果。
分析常见无效请求来源
以下几类是高频“无效请求”的典型根因：
未配置主机名或 FQDN 的服务自动补全
某些守护进程（如rsyslog、auditd、chrony）在日志或同步时尝试解析本机hostname的完整域名。若/etc/hosts缺少127.0.0.1 $(hostname)或$(hostname).local映射，就会向外发起 PTR/A 查询。
✅ 解决：echo "127.0.0.1 $(hostname)" | sudo tee -a /etc/hosts应用硬编码错误域名或 fallback 查询
如 Java 应用默认查myhost.domain.com和myhost.localdomain；Node.js 的dns.lookup()在ipv4First: true下可能多查一次 AAAA；某些旧版 curl 会为短名自动追加search域（见/etc/resolv.conf中search行）。
✅ 解决：检查/etc/resolv.conf的search是否冗余；对关键服务禁用 IPv6 DNS 查询（如curl --ipv4测试）NSS 配置错误导致反复回退查询
/etc/nsswitch.conf中hosts: files dns是标准配置，但如果误写成hosts: dns files，系统会先查 DNS 再查/etc/hosts，导致本可本地解决的映射（如localhost）也发出去。
✅ 解决：确认hosts行以files开头，且不含拼写错误（如file少字母）监控或健康检查脚本轮询失败域名
自定义脚本（如check_http.sh）未加失败退出逻辑，当dig google.com +short返回空时仍继续循环执行；或容器化环境里 sidecar 不断查kubernetes.default.svc.cluster.local但 CoreDNS 未就绪。
✅ 解决：用ps aux | grep -E "(sh|bash|python)"找可疑脚本；检查systemctl list-timers --all中是否有高频定时任务。
验证请求是否真“无效”，还是被误判
有些请求看似无效，实为正常行为：
-
dig -x 127.0.0.1→ 查1.0.0.127.in-addr.arpa.是标准反向解析，用于日志标识或认证 - 查询
wpad或proxy.pac→ 浏览器或系统自动代理发现机制，即使你没配代理也会触发 -
*.local域名查询 → Avahi/mDNS 服务启用时合法，不应被阻断
若确认是无效请求，可临时拦截验证：
# 用 iptables 丢弃发往特定 DNS 的 UDP 53（仅测试！） sudo iptables -I OUTPUT -d 192.168.1.1 -p udp --dport 53 -j DROP # 观察应用是否报错或日志是否停止刷 DNS 行为
再结合 journalctl -b | grep -i "resolve\|dns" 查关联错误线索。
不复杂但容易忽略
