{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/test-the-most-specific-opnsense-unbound-access-list/", "item": { "id": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/", "slug": "test-the-most-specific-opnsense-unbound-access-list", "url": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list.md", "json": "https://update.dsesecurity.com/api/v1/posts/test-the-most-specific-opnsense-unbound-access-list/" }, "title": "Test the most specific OPNsense Unbound access list", "summary": "Evaluate overlapping resolver client networks by prefix specificity and distinguish a dropped request from a REFUSED response.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-29T17:41:12+00:00", "modified_at": "2026-10-29T17:41:38+00:00", "reviewed_on": "2026-10-29", "reading_minutes": 3, "word_count": 501, "potentially_affected": "OPNsense Unbound DNS administrators reviewing resolver access lists.", "dse_recommendation": "Predict the winning netblock for each approved client and verify response behavior from both allowed and excluded locations.", "primary_source": { "name": "OPNsense — Unbound DNS", "url": "https://docs.opnsense.org/manual/unbound.html", "published_on": null, "authority": "docs.opnsense.org" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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.

\n

Source fact: what the authority says

\n

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.

\n

What the source does not establish

\n

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.

\n

Applicability questions

\n\n

DSE recommendation: controlled next steps

\n

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

\n

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.

\n

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.

\n

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.

\n

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.

\n

Verification and evidence

\n

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.

\n

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.

\n

Official references

\n\n

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

\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich address does Unbound observe for each client being tested?\nWhich assigned-interface and custom netblocks overlap that address?\nShould an excluded client receive REFUSED or a dropped request?\nIs any snooping permission intentional and restricted to the approved administrative scope?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nReview 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.\nDecide 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.\nReview 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.\nVerification and evidence\nProposed 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.\nWhere 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.\nOfficial references\n\nOPNsense — Unbound DNS — 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: 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.\n\n## Source fact: what the authority says\n\nThe [OPNsense Unbound guide](https://docs.opnsense.org/manual/unbound.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which address does Unbound observe for each client being tested?\n\n- Which assigned-interface and custom netblocks overlap that address?\n\n- Should an excluded client receive REFUSED or a dropped request?\n\n- Is any snooping permission intentional and restricted to the approved administrative scope?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nReview 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.\n\nDecide 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.\n\nReview 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.\n\n## Verification and evidence\n\nProposed 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.\n\nWhere 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.\n\n## Official references\n\n- [OPNsense — Unbound DNS](https://docs.opnsense.org/manual/unbound.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/test-the-most-specific-opnsense-unbound-access-list/", "url": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Test the most specific OPNsense Unbound access list", "item": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/#article", "identifier": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/", "url": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/", "headline": "Test the most specific OPNsense Unbound access list", "description": "Evaluate overlapping resolver client networks by prefix specificity and distinguish a dropped request from a REFUSED response.", "abstract": "Evaluate overlapping resolver client networks by prefix specificity and distinguish a dropped request from a REFUSED response.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich address does Unbound observe for each client being tested?\nWhich assigned-interface and custom netblocks overlap that address?\nShould an excluded client receive REFUSED or a dropped request?\nIs any snooping permission intentional and restricted to the approved administrative scope?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nReview 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.\nDecide 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.\nReview 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.\nVerification and evidence\nProposed 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.\nWhere 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.\nOfficial references\n\nOPNsense — Unbound DNS — 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-29T17:41:12+00:00", "dateModified": "2026-10-29T17:41:38+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/test-the-most-specific-opnsense-unbound-access-list/" }, "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/test-the-most-specific-opnsense-unbound-access-list/#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": "Test the most specific OPNsense Unbound access list" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 501, "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 — Unbound DNS", "url": "https://docs.opnsense.org/manual/unbound.html" } } ] } }