OPNsense中Dnsmasq DHCP域名分配机制深度解析

核心问题现象

在OPNsense防火墙系统中，用户发现当使用Dnsmasq作为DHCP服务时，客户端设备无法自动获取预设的域名信息。具体表现为：

1. 静态地址保留池（reservations）中的客户端无法继承全局默认域名
2. 仅当在DHCP选项中显式配置domain-name[15]参数时才能生效
3. 域名设置存在作用域边界效应

技术背景分析

Dnsmasq作为轻量级DNS和DHCP服务，其域名分配机制与传统ISC DHCP存在显著差异：

1. 三层域名配置层级：

   • 全局默认域名（General → DHCP default domain）
   • DHCP范围域（DHCP Ranges中的domain设置）
   • 主机保留记录域（Hosts中的Domain字段）

2. 作用域继承规则：

   • 主机保留记录必须包含在DHCP范围（pool）内才能继承域名配置
   • 独立于DHCP范围外的静态地址不会自动获取任何域名参数
   • 全局默认域名仅对未配置特定域的DHCP范围生效

最佳实践方案

经过验证的可靠配置方法：

1. 地址池规划原则：

# 推荐做法（包含静态地址）
dhcp-range=192.168.1.100,192.168.1.200,12h
dhcp-host=AA:BB:CC:DD:EE:FF,192.168.1.150

# 不推荐做法（排除静态地址）
dhcp-range=192.168.1.100,192.168.1.149,12h
dhcp-range=192.168.1.151,192.168.1.200,12h

2. 域名配置优先级：

   • 第一优先级：DHCP选项中的显式domain-name[15]
   • 第二优先级：DHCP范围域（当客户端IP在范围内）
   • 第三优先级：全局默认域（仅适用于无域配置的范围）

3. 特殊注意事项：

   • 主机保留记录中的Domain字段仅用于DNS正向解析
   • Windows客户端会主动请求option 15而Linux客户端可能不会
   • 建议对所有接口启用domain-name[15]选项保证兼容性

底层机制解析

通过数据包抓取分析发现：

1. DHCP协议交互过程中，客户端需在DHCPREQUEST中明确请求option 15参数
2. Dnsmasq对地址保留池实施强隔离机制，范围外的地址不会继承任何DHCP属性
3. 动态DNS注册发生在租约分配之后，与静态主机记录的预注册形成互补

配置建议

对于企业级网络环境：

1. 采用包含式地址池设计，将静态地址纳入动态范围
2. 在接口级别统一配置domain-name[15]选项
3. 通过DHCP范围域实现部门级域名隔离
4. 使用dhcp-option=option:domain-name,example.com语法增强可读性

该解决方案已通过Ubuntu和Windows系统的兼容性验证，适用于OPNsense 25.1及后续版本。网络管理员应当特别注意Dnsmasq与传统DHCP服务的行为差异，合理规划IP地址分配策略。