DNS解析请求被“拦截”实为配置错位所致，常见于DHCP未按子网分发正确DNS、终端使用不可达DNS地址、防火墙/ACL阻断UDP 53端口、DNS服务器未监听新子网地址或拒绝其查询。
子网划分后，DNS解析请求被“拦截”通常不是子网本身在拦截，而是配置错位导致请求根本没发出去、发到了错误地址，或被中间设备（如防火墙、ACL、DHCP下发的错误DNS）阻断。排查关键不在于“子网是否拦截DNS”，而在于厘清请求路径中哪一环断了、改道了或被丢弃了。
确认终端实际使用的DNS服务器地址
很多问题根源是终端拿到了错误的DNS地址——尤其在划分子网后，若DHCP服务器未按子网分发对应DNS，或静态配置未更新，终端可能仍在用旧网段的DNS（比如指向已下线的内网DNS服务器，或指向不可达的公网DNS）。
- Windows执行 ipconfig /all，检查“DNS Servers”项是否为预期地址（如192.168.10.1，而非192.168.1.1）
- Linux/macOS执行 cat /etc/resolv.conf 或 systemd-resolve --status
- 对比该DNS地址是否属于当前子网、能否路由可达（用 ping -c 3 192.168.10.1 测试连通性）
验证DNS请求是否真正发出并到达目标DNS服务器
用抓包工具直接看终端发出的UDP 53端口数据包，是最可靠的判断方式：
- 在终端上运行 tcpdump -i any port 53 -nn（Linux/macOS）或 Wireshark（Windows）
- 同时执行 nslookup www.baidu.com 或 dig @192.168.10.1 www.qq.com
- 观察抓包结果：是否有 outbound UDP 53 包发往目标DNS？是否有 reply 返回？若只有请求、无响应，说明DNS服务器没收到或没回复；若连请求都没有，说明系统根本没走这个DNS（可能被本地hosts、stub resolver或策略路由绕过）
检查子网边界设备是否限制DNS流量
划分子网常伴随VLAN、三层交换机或防火墙策略调整。这些设备可能默认阻止跨子网的UDP 53，或对DNS做了深度检测（如DNS过滤、防劫持策略）。
- 登录核心交换机或出口防火墙，查看ACL/安全策略中是否含类似 “deny udp any any eq 53” 或 “drop dns-query from 192.168.20.0/24” 的规则
- 检查是否启用了DNS代理（如交换机内置DNS relay）、DNS重定向（如某些企业防火墙会强制将53端口请求重定向到自有DNS）
- 临时放行测试：添加一条允许源子网→DNS服务器IP:53的显式permit规则，再试nslookup
验证DNS服务器自身是否能响应本子网请求
即使DNS服务在运行，也可能因绑定地址、访问控制列表（ACL）或监听配置，拒绝来自新子网的查询。
- 登录DNS服务器（如Windows Server DNS、BIND、dnsmasq），确认其监听地址包含本子网网关接口（如192.168.10.1），而非仅127.0.0.1或旧网段IP
- 检查DNS服务的允许查询列表（allow-query in BIND；“根提示”或“转发器”配置是否覆盖新子网）
- 从子网内另一台机器（非客户端）用 telnet 192.168.10.1 53 测试端口可达性（注意：telnet测TCP，DNS主要用UDP；更准用 nc -uvz 192.168.10.1 53）
