Test the most specific OPNsense Unbound access list

Bottom line: Evaluate the client’s most specific matching network before rearranging access-list rows. Write the expected result for each approved test location, including whether a rejected query should receive a refusal or no answer.

Source fact: what the authority says

The OPNsense Unbound guide says access lists define which clients may query the resolver and automatically creates records for assigned interfaces. The most specific netblock wins; no match uses deny, and statement order does not matter. Deny stops queries, whereas Refuse stops them and returns the DNS REFUSED response code. Allow Snoop permits recursive and nonrecursive access and is intended ideally only for an administrative host.

What the source does not establish

This article addresses Unbound client access-list selection, not a complete firewall exposure assessment or DNS filtering policy. The guide’s blocklist, forwarding and transport settings are separate decisions and must not be inferred from an access-list result.

Applicability questions

• Which address does Unbound observe for each client being tested?
• Which assigned-interface and custom netblocks overlap that address?
• Should an excluded client receive REFUSED or a dropped request?
• Is any snooping permission intentional and restricted to the approved administrative scope?

DSE recommendation: controlled next steps

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

DSE recommends an address-to-policy worksheet. Include a proposed client inside a broad allowed network, a client inside a narrower excluded network and a client outside all intended entries. Determine the most specific match on paper before changing the configuration.

Review automatically generated interface records as well as custom policies. Keep the client address, prefix and chosen action together. Do not assume that moving a broad allow row below a narrow restriction changes the documented selection rule.

Decide which rejection behavior the troubleshooting workflow should expect. Ask operations to distinguish an explicit refusal from an unanswered request in the test record. Keep the resolver’s observed source separate from the user’s workstation identity where another network component is involved.

Review any Allow Snoop entry as an explicit exception with an owner and named administrative host. Do not broaden it merely to make a diagnostic client work. Preserve the previous policy and limit the pilot to the agreed client population before considering a wider access change.

Verification and evidence

Proposed verification: send the same approved harmless recursive query from each worksheet location and record the client address, response code or absence of response, resolver and time. Compare the observed result with the predicted winning prefix. Investigate an unexpected observation rather than immediately changing multiple overlapping entries.

Where an isolated test configuration is available, compare equivalent policy rows in a different order while preserving their actual prefixes and actions. Use this only as a controlled check of the documented selection model. Retain the effective access-list configuration and separate network reachability checks from the resolver policy conclusion.

Official references

• OPNsense — Unbound DNS — 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.