Linux 系统中怎么排查系统频繁向 DNS 服务器发送无效请求-linux运维-PHP中文网

linux系统dns异常高频请求排查需先用tcpdump捕获udp 53流量确认现象，再通过ss/lsof定位进程、resolvectl statistics分析查询统计，结合journalctl查看systemd-resolved日志，重点检查hostname配置缺失、/etc/resolv.conf search冗余、/etc/nsswitch.conf hosts顺序错误及监控脚本轮询等典型根因。

linux 系统中怎么排查系统频繁向 dns 服务器发送无效请求

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、域名和结果。

Linux installer
先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

分析常见无效请求来源

以下几类是高频“无效请求”的典型根因：

未配置主机名或 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" 查关联错误线索。

不复杂但容易忽略