先说结论
先说结论，openwrt（至少是部分发行版）的dnsmasq，会劫持过境数据包的UDP53端口！！！
博主使用版本：
系统：Kwrt 24.10-SNAPSHOT 10.18.2025 by Kiddin' / LuCI openwrt-24.10 branch 26.286.45320~2b783f2
dnsmasq：dnsmasq-full 2.90-r4
WAN侧地址：44.32.191.1 （44net,AS153376）
DNS服务器
地址：44.32.191.4 44.32.191.6
软件配置：ubuntu 22.04 mysql 8.0 powerdns
PowerDNS核心配置（/etc/pdns/pdns.conf）
launch=gmysql # 启用MySQL后端存储解析记录
gmysql-host=127.0.0.1 # 数据库地址（本地）
gmysql-port=3306 # 数据库端口
gmysql-user=powerdns # 数据库账号（仅授权powerdns库权限）
gmysql-dbname=powerdns # 数据库名
gmysql-password=hxxxxxxxxxxxxxxxxxxxxiz # 数据库密码（已脱敏）
gmysql-dnssec=no # 暂不启用DNSSEC，优先保证基础解析
local-address=0.0.0.0,:: # 监听所有网卡（包括公网IP）
local-port=53 # 默认DNS端口，初始未怀疑端口问题问题出现
为了解决部分权威域名解析和反向域名解析，我按照知识库的说明，在ubuntu上安装了服务器，搞定主从复制，部署了两台DNS服务器，但是问题来了，这两台NS只能从内网访问，无法从外网访问（提示NXDOMAIN）
1. 内网测试（正常）
LAN侧任意机器查询主从DNS，均能秒返回正确结果：
# 主DNS查询（44.32.191.4）
root@lan-test:~# dig @44.32.191.4 hk1.44net.bcs.zhuantou.com.cn +short
44.32.191.9 # 正确匹配业务服务器IP
# 从DNS查询（44.32.191.6）
root@lan-test:~# dig @44.32.191.6 hk1.44net.bcs.zhuantou.com.cn +short
44.32.191.9 # 主从同步正常2. 外网测试（全崩）
换3台不同环境的外网机器（ISP分别为：AS979NetLab、AS4134中国电信、AS4837），查询结果全是NXDOMAIN（域名不存在）：
root@home-pc:~# nslookup hk1.44net.bcs.zhuantou.com.cn 44.32.191.4
Server: 44.32.191.4
Address: 44.32.191.4#53
*** 44.32.191.4 can't find hk1.44net.bcs.zhuantou.com.cn: NXDOMAIN3. 更诡异的链路测试
外网机器能正常ping通DNS服务器，甚至能telnet到53端口，说明网络链路没问题：
# ping测试（阿里云ECS）
root@aliyun:~# ping 44.32.191.4 -c 3
PING 44.32.191.4 (44.32.191.4) 56(84) bytes of data.
64 bytes from 44.32.191.4: icmp_seq=1 ttl=54 time=18.2 ms
64 bytes from 44.32.191.4: icmp_seq=2 ttl=54 time=18.1 ms
64 bytes from 44.32.191.4: icmp_seq=3 ttl=54 time=18.3 ms
--- 44.32.191.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 18.112/18.234/18.345/0.108 ms
# telnet测试（阿里云ECS）
root@aliyun:~# telnet 44.32.191.4 53
Trying 44.32.191.4...
Connected to 44.32.191.4.
Escape character is '^]'.排查过程：绕了将近两周的“冤枉路”
从DNS服务器到网关，再到运营商，我几乎怀疑了所有环节，每一步都有记录，结果全是乌龙。
第一步：怀疑PowerDNS配置（先找自己问题）
检查PowerDNS运行状态：
root@ns1q1:~# systemctl status pdns ● pdns.service - PowerDNS Authoritative Server Loaded: loaded (/lib/systemd/system/pdns.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2025-10-28 10:00:00 CST; 5h ago Docs: man:pdns_server(1) man:pdns_control(1) Main PID: 1234 (pdns_server) Tasks: 5 (limit: 4567) Memory: 12.3M CPU: 1.2s CGroup: /system.slice/pdns.service └─1234 /usr/sbin/pdns_server --daemon=no --guardian=no --disable-syslog --log-timestamp=no --write-pid=no状态为
active (running)，无报错，排除服务未启动问题。验证数据库记录：
mysql -u powerdns -p Enter password: mysql> use powerdns; Database changed mysql> SELECT id, name, type, content, disabled FROM records WHERE name = 'hk1.44net.bcs.zhuantou.com.cn'; +----+-------------------------------+------+-------------+----------+ | id | name | type | content | disabled | +----+-------------------------------+------+-------------+----------+ | 14 | hk1.44net.bcs.zhuantou.com.cn | A | 44.32.191.9 | 0 |row in set (0.00 sec)
记录存在，`disabled=0`（未禁用），`content`正确，排除记录问题。本地测试PowerDNS响应：
root@ns1q1:~# dig @127.0.0.1 hk1.44net.bcs.zhuantou.com.cn +short 44.32.191.9 # 本地查询正常，说明服务本身没问题
第二步：怀疑OpenWRT网关（中间层排查）
网关是外网流量入口，优先查防火墙和DNS劫持：
检查FORWARD链规则（外网到LAN侧流量走此链）：
[root@Kwrt:04:53 PM ~] # iptables -L FORWARD -n --line-numbers Chain FORWARD (policy ACCEPT)- ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
默认策略`ACCEPT`，无任何`DROP/REJECT`规则，排除防火墙拦截。检查DNS劫持（nat表PREROUTING链）：
[root@Kwrt:04:54 PM ~] # iptables -t nat -L PREROUTING -n --line-numbers | grep "53" [root@Kwrt:05:17 PM ~] # # 无输出，说明无53端口重定向规则LAN侧访问外部DNS测试：
root@lan-test:~# nslookup www.google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: www.google.com Address: 142.250.71.196 Name: www.google.com Address: 2404:6800:4005:81a::2004能正常解析，排除网关劫持问题，当时甚至觉得“网关很干净”。
第三步：怀疑运营商（差点打电话投诉）
因为换非53端口（如5353）能通，我一度笃定是运营商封了53端口：
修改PowerDNS端口为5353：
# 编辑配置 vi /etc/pdns/pdns.conf # 改local-port=5353 systemctl restart pdns # 验证监听 ss -tuln | grep 5353 udp UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* tcp LISTEN 0 128 0.0.0.0:5353 0.0.0.0:*外网测试5353端口：
root@aliyun:~# dig @44.32.191.4 -p 5353 hk1.44net.bcs.zhuantou.com.cn +short 44.32.191.9 # 成功解析，更坚信是运营商问题
3.nslookup查网关（丧心病狂）
root@instance-z9ELqPcK:~# nslookup baidu.com 44.32.191.1
Server: 44.32.191.1
Address: 44.32.191.1#53
Non-authoritative answer:
Name: baidu.com
Address: 39.156.70.37
Name: baidu.com
Address: 220.181.7.203
真相大白：dnsmasq的“隐形劫持”
我那时就很气，我都做到这份上了，到底是谁的问题啊，DNS服务器没问题，内网传输也没问题，网关也没有DNS拦截的规则，天狼一国际IDC，也不可能跟MIIT一样丧心病狂拦截53端口啊？总不能是dnsmasq不规矩吧.....
1. 停止并禁用dnsmasq
[root@Kwrt:06:00 PM ~] # /etc/init.d/dnsmasq stop # 停止服务
[root@Kwrt:06:01 PM ~] # /etc/init.d/dnsmasq disable # 禁用自启
[root@Kwrt:06:02 PM ~] # ps | grep dnsmasq # 确认进程已停
[root@Kwrt:06:03 PM ~] # # 无输出，成功停止2. 外网测试53端口（瞬间正常）
root@instance-z9ELqPcK:~# dig @44.32.191.4 hk1.44net.bcs.zhuantou.com.cn +short
44.32.191.9 # 秒出结果！之前的NXDOMAIN全是dnsmasq搞的鬼3. 结论，openwrt-dnsmasq存在劫持
通过本次排坑实验，我可以确定，dnsmasq存在劫持内网UDP53端口之嫌，这个得待我稍后有时间对其进行代码审计的......
在我没查明白前，使用OPENWRT做边界网关的IDC朋友们，若需要在网内搭建DNS，请务必关掉openwrt的dnsmasq软件，免得麻烦。
后传，如果DNS解决不了问题，请看D-H-C-P!!!!!!!!
草，谁tm打开的DNS重定向？？？？？？
Comments | NOTHING