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.
\nThe 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.
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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nPrepare 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.
\nFor 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.
\nPreserve 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.
\nProposed 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.
\nCheck 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nShould the range serve approved reservations only or also unknown dynamic clients?\nWhich intended addresses fall inside the configured dynamic range?\nWhat IPv4 hardware identifier and IPv6 DUID belong to the actual test device?\nWhich service owns Router Advertisements on the test segment?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nFor 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nOPNsense — Dnsmasq DNS & DHCP — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [OPNsense Dnsmasq guide](https://docs.opnsense.org/manual/dnsmasq.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Should the range serve approved reservations only or also unknown dynamic clients?\n\n- Which intended addresses fall inside the configured dynamic range?\n\n- What IPv4 hardware identifier and IPv6 DUID belong to the actual test device?\n\n- Which service owns Router Advertisements on the test segment?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nPrepare 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.\n\nFor 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.\n\nPreserve 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCheck 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.\n\n## Official references\n\n- [OPNsense — Dnsmasq DNS & DHCP](https://docs.opnsense.org/manual/dnsmasq.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Separate OPNsense Dnsmasq reservations from reservation-only ranges", "item": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/#article", "identifier": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/", "headline": "Separate OPNsense Dnsmasq reservations from reservation-only ranges", "description": "The OPNsense Dnsmasq guide distinguishes a static reservation from static range mode.", "abstract": "The OPNsense Dnsmasq guide distinguishes a static reservation from static range mode. Review dynamic-client eligibility separately, including the documented DUID requirement for IPv6 reservations.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nShould the range serve approved reservations only or also unknown dynamic clients?\nWhich intended addresses fall inside the configured dynamic range?\nWhat IPv4 hardware identifier and IPv6 DUID belong to the actual test device?\nWhich service owns Router Advertisements on the test segment?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nFor 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nOPNsense — Dnsmasq DNS & DHCP — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:41+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-dnsmasq-reservations-from-reservation-only-ranges/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate OPNsense Dnsmasq reservations from reservation-only ranges" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 544, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Dnsmasq DNS & DHCP", "url": "https://docs.opnsense.org/manual/dnsmasq.html" } } ] } }