直接答案
dnsmasq 的 rebind protection 旨在防止公网名称被回答为私有地址而把客户端导向内部资源。若自有内网名称被误拦，不要直接关闭全局保护；先确认 DNS 回答、该名称的管理边界和是否需要一个最小范围的例外。
症状
客户端能解析公共域名，却在访问自建 NAS、家庭网关或内部服务名称时得到空回答或 dnsmasq 日志中的 rebind 提示。直接填写私有 IP 可能连通，但这不能证明 DNS 配置是安全的。
适用于运行 dnsmasq 的 OpenWrt 网络。不同 OpenWrt 版本、LuCI 页面和上游 DNS 行为可能不同；本文不假定某个界面字段或第三方规则一定存在。
原因判断
先区分三种情况：上游 DNS 正确返回了你管理的私有服务地址；某个外部名称意外或恶意被回答为私网地址；客户端实际用了另一台 DNS。只有第一种才可能需要受限的本地域例外。
只读诊断
# 在获授权的路由器或 LAN 终端上比较答案与 dnsmasq 日志
nslookup <internal-fqdn> <lan-dns-resolver>
logread | grep -iE 'dnsmasq|rebind' | tail -n 80
uci show dhcp记录名称、解析器和回答类别即可；不要把完整家庭地址、订阅地址、令牌或无关客户端信息写入共享日志。
解决步骤
- 先为自有服务使用稳定的内部 FQDN，并确认该记录只由预期 DNS 管理。
- 确认问题客户端通过 DHCP 或手动设置使用该 LAN DNS，而不是 VPN、浏览器私有 DNS 或公共解析器。
- 若确实需要例外，在 OpenWrt 的现有 dnsmasq 配置中只针对该受管域设置最小范围例外；变更前导出配置并保留 LAN 管理入口。
- 不要把整个 RFC1918 地址段、所有上游域名或所有 DNS 保护都加入白名单。
验证方法
从一个 LAN 终端重复查询完整名称，确认得到预期记录；再查询一个不相关公网名称，确认它仍不会被错误解析到私有地址。测试访客 VLAN 时应同时确认该 VLAN 没有因此获得不应有的内部服务访问权限。
替代方案与限制
如果服务只供局域网使用，优先使用本地 DNS 区域或 hosts/静态租约的受控记录，而不是依赖公共 DNS 回答私网地址。若 DNS 回答来自不受你控制的上游，先联系该域名或网络管理员。Wi-Fi 信号、网线和外部出口质量不会直接修复 rebind 判定。
来源与下一步
OpenWrt 的 DHCP 与 dnsmasq 配置背景见 官方文档。继续阅读 局域网 DNS 路径 与 DHCP 域搜索后缀；它们处理的是不同层级的问题。