Separate OPNsense Dnsmasq reservations from reservation-only ranges

Bottom line: Write whether unknown dynamic clients may receive an address before selecting range mode. Treat a reservation as a client-specific allocation decision, then review the separate IPv4 and IPv6 identification requirements.

Source fact: what the authority says

The OPNsense Dnsmasq guide says a reservation reserves its address inside a dynamic range, preventing that address from being offered to dynamic clients. Setting the range mode to static is not required for reservations; that mode serves the separate case where a range should not serve unknown dynamic clients. For an IPv6 reservation, the guide requires a DHCPv6 range with the slaac Router Advertisement option, or Assisted mode when using a different RA daemon. It says a hardware address does not work for IPv6 reservations and the device unique identifier, or DUID, must be used instead.

What the source does not establish

This article covers the documented distinction between range eligibility and client reservations. It does not turn a DHCP reservation into an authorization policy or establish that every client will use the intended address, DNS record or advertisement settings.

Applicability questions

• Should the range serve approved reservations only or also unknown dynamic clients?
• Which intended addresses fall inside the configured dynamic range?
• What IPv4 hardware identifier and IPv6 DUID belong to the actual test device?
• Which service owns Router Advertisements on the test segment?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends an address worksheet with separate columns for range mode, dynamic eligibility, reserved address and client identity. For a proposed ordinary dynamic pool, mark the reserved device explicitly without changing the whole range to static merely because a reservation has been added.

Prepare a second proposed reservation-only case where unknown clients must not receive a dynamic address from that range. Have the network owner approve that requirement before selecting static mode. Keep switch or network authorization requirements in their own design rather than treating the DHCP choice as the complete access boundary.

For a dual-stack pilot, obtain the identifiers from the approved test device and record where each was observed. Review the IPv6 range and advertisement owner together. Do not copy an example identifier or substitute the Ethernet address for an unverified DUID.

Preserve the existing ranges and host entries before the change. Limit the initial trial to a harmless test segment with a known reserved device and a separate unknown client. Agree how to restore the previous address service if the intended population cannot obtain its required configuration.

Verification and evidence

Proposed verification: in the dynamic-pool case, request an address from the reserved device and from a permitted dynamic control client. Compare the resulting leases with the worksheet. In the separately approved static-range case, record what happens to the unknown client without assuming its outcome from the reservation entry alone.

Check IPv4 and IPv6 observations independently, including the actual DUID and selected advertisement service. Retain the resulting addresses, lease evidence and relevant range settings without unnecessary device identifiers in public records. Investigate a mismatch before extending the design to an operational subnet.

Official references

• OPNsense — Dnsmasq DNS & DHCP — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.