OPNsense中Dnsmasq优化：解决客户端DNS查询超时问题

在OPNsense防火墙系统中，Dnsmasq作为DHCP和DNS服务组件时，存在一个典型的客户端查询效率问题。当Windows客户端执行非标准FQDN查询（未以点结尾）时，系统会因DNS后缀处理机制导致查询延迟。本文将深入分析问题成因并提供两种优化方案。

问题现象分析

Windows客户端使用nslookup工具查询非FQDN格式域名（如"opnsense.org"而非"opnsense.org."）时，会自动附加DHCP下发的DNS后缀（如".h1.home.arpa"）。这种非标准查询行为会触发以下异常流程：

1. 客户端首先查询"opnsense.org.h1.home.arpa"
2. 等待超时（约2-3秒）后回退查询原始域名
3. 最终获得正确解析结果

通过抓包分析可见，标准DNS查询应在域名末尾包含点字符"."，而Windows的非标准实现导致了性能问题。

技术背景

在OPNsense典型部署中：

• Unbound作为递归解析器
• Dnsmasq处理本地域名和DHCP
• 动态DNS注册使Dnsmasq维护本地主机记录

当Dnsmasq收到未知主机查询时，默认会：

1. 检查本地记录
2. 未找到则转发至resolv.conf配置的上游
3. 可能形成Unbound→Dnsmasq→Unbound的循环查询

优化方案一：禁用Dnsmasq转发功能

通过配置no-resolv参数：

-R, --no-resolv

此方案直接禁止Dnsmasq使用resolv.conf中的上游服务器，效果：

• 加速失败查询的响应速度（返回SERVFAIL）
• 避免查询循环
• 但会返回REFUSED而非NXDOMAIN

优化方案二：声明本地权威域

更完善的解决方案需结合：

1. no-resolv参数
2. local=/domain/声明

例如：

local=/h1.home.arpa/

此方案使Dnsmasq：

• 对声明域具有权威性
• 返回标准NXDOMAIN响应
• 完全避免上游查询
• 保持DNS隔离性

实施建议

对于OPNsense管理员：

1. 确认客户端是否使用标准FQDN查询
2. 评估是否需要完整本地DNS服务
3. 在Dnsmasq配置中声明所有本地域
4. 监控日志验证效果

典型配置组合：

no-resolv
local=/internal-domain1/
local=/internal-domain2/
addn-hosts=/var/etc/dnsmasq-hosts

总结

通过合理配置Dnsmasq的解析行为，可有效解决Windows客户端因非标准查询导致的延迟问题。方案二提供了更符合DNS标准的实现方式，建议在生产环境中采用。管理员应当理解不同响应类型（REFUSED/NXDOMAIN）对客户端行为的影响，根据实际需求选择优化方案。