Bottom line: Separate initial resolver-list retrieval from normal DNS query handling. Record exactly when the fallback is permitted and test that condition without calling the whole design private DNS.
\nThe OPNsense DNSCrypt-Proxy guide describes Fallback Resolver as a normal, unencrypted DNS resolver. The fallback is used only for one-shot queries to retrieve the initial resolver list, and only if the system DNS configuration does not work. The guide’s Listen Address default is localhost port 5353. Allow Privileged Ports permits binding to ports below 1024.
\nThis article covers the documented bootstrap fallback and listener choices, not a guarantee about resolver logging or anonymity. It does not recommend exposing a resolver on all interfaces or replacing an existing forwarding design without a separate review.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a short sequence diagram for startup and a separate diagram for an ordinary client lookup. Identify system DNS, the initial resolver-list request and the intended encrypted resolver path. Give the fallback its own purpose and owner rather than labeling it as a general emergency DNS service.
\nReview the organization’s rules for any unencrypted bootstrap request. If that traffic is unacceptable, pause the deployment decision and obtain a supported alternative design. Do not describe a selected no-log resolver filter as proof that every request in the complete startup sequence is encrypted or unrecorded.
\nChoose the listener address and port from the actual forwarding arrangement. Preserve existing resolver and client settings before a pilot. Keep privileged-port permission as a deliberate setting tied to that listener; avoid enabling it just to eliminate an error before understanding which service owns the intended port.
\nUse an isolated or otherwise approved test arrangement for the unavailable-system-DNS case. Name the monitoring point and narrowly scoped traffic capture in advance. Protect any recorded query names and keep the fallback destination out of an unrelated production DNS change until the privacy and availability owners have reviewed it.
\nProposed verification: observe an initial startup with the approved system DNS available and record the resolver-list retrieval path. In the separate authorized failure case, make the test system DNS unavailable and observe whether the documented fallback condition is exercised. Restore the starting configuration immediately after that case.
\nThen issue a harmless ordinary lookup through the intended client path and compare its destination with the bootstrap observation. Inspect the effective listening address and port independently. Retain timings and redacted network evidence; an unexplained unencrypted query should remain a finding rather than being dismissed as normal fallback.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Separate initial resolver-list retrieval from normal DNS query handling. Record exactly when the fallback is permitted and test that condition without calling the whole design private DNS.\nSource fact: what the authority says\nThe OPNsense DNSCrypt-Proxy guide describes Fallback Resolver as a normal, unencrypted DNS resolver. The fallback is used only for one-shot queries to retrieve the initial resolver list, and only if the system DNS configuration does not work. The guide’s Listen Address default is localhost port 5353. Allow Privileged Ports permits binding to ports below 1024.\nWhat the source does not establish\nThis article covers the documented bootstrap fallback and listener choices, not a guarantee about resolver logging or anonymity. It does not recommend exposing a resolver on all interfaces or replacing an existing forwarding design without a separate review.\nApplicability questions\n\nHow will the system obtain its initial resolver list after startup?\nWhich resolver and network path are approved for the fallback condition?\nWhat process sends ordinary client queries to the selected listener?\nDoes the proposed listener need a privileged port, and on which addresses should it listen?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a short sequence diagram for startup and a separate diagram for an ordinary client lookup. Identify system DNS, the initial resolver-list request and the intended encrypted resolver path. Give the fallback its own purpose and owner rather than labeling it as a general emergency DNS service.\nReview the organization’s rules for any unencrypted bootstrap request. If that traffic is unacceptable, pause the deployment decision and obtain a supported alternative design. Do not describe a selected no-log resolver filter as proof that every request in the complete startup sequence is encrypted or unrecorded.\nChoose the listener address and port from the actual forwarding arrangement. Preserve existing resolver and client settings before a pilot. Keep privileged-port permission as a deliberate setting tied to that listener; avoid enabling it just to eliminate an error before understanding which service owns the intended port.\nUse an isolated or otherwise approved test arrangement for the unavailable-system-DNS case. Name the monitoring point and narrowly scoped traffic capture in advance. Protect any recorded query names and keep the fallback destination out of an unrelated production DNS change until the privacy and availability owners have reviewed it.\nVerification and evidence\nProposed verification: observe an initial startup with the approved system DNS available and record the resolver-list retrieval path. In the separate authorized failure case, make the test system DNS unavailable and observe whether the documented fallback condition is exercised. Restore the starting configuration immediately after that case.\nThen issue a harmless ordinary lookup through the intended client path and compare its destination with the bootstrap observation. Inspect the effective listening address and port independently. Retain timings and redacted network evidence; an unexplained unencrypted query should remain a finding rather than being dismissed as normal fallback.\nOfficial references\n\nOPNsense — DNSCrypt-Proxy — 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: Separate initial resolver-list retrieval from normal DNS query handling. Record exactly when the fallback is permitted and test that condition without calling the whole design private DNS.\n\n## Source fact: what the authority says\n\nThe [OPNsense DNSCrypt-Proxy guide](https://docs.opnsense.org/manual/how-tos/dnscrypt-proxy.html) describes Fallback Resolver as a normal, unencrypted DNS resolver. The fallback is used only for one-shot queries to retrieve the initial resolver list, and only if the system DNS configuration does not work. The guide’s Listen Address default is localhost port 5353. Allow Privileged Ports permits binding to ports below 1024.\n\n## What the source does not establish\n\nThis article covers the documented bootstrap fallback and listener choices, not a guarantee about resolver logging or anonymity. It does not recommend exposing a resolver on all interfaces or replacing an existing forwarding design without a separate review.\n\n## Applicability questions\n\n- How will the system obtain its initial resolver list after startup?\n\n- Which resolver and network path are approved for the fallback condition?\n\n- What process sends ordinary client queries to the selected listener?\n\n- Does the proposed listener need a privileged port, and on which addresses should it listen?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a short sequence diagram for startup and a separate diagram for an ordinary client lookup. Identify system DNS, the initial resolver-list request and the intended encrypted resolver path. Give the fallback its own purpose and owner rather than labeling it as a general emergency DNS service.\n\nReview the organization’s rules for any unencrypted bootstrap request. If that traffic is unacceptable, pause the deployment decision and obtain a supported alternative design. Do not describe a selected no-log resolver filter as proof that every request in the complete startup sequence is encrypted or unrecorded.\n\nChoose the listener address and port from the actual forwarding arrangement. Preserve existing resolver and client settings before a pilot. Keep privileged-port permission as a deliberate setting tied to that listener; avoid enabling it just to eliminate an error before understanding which service owns the intended port.\n\nUse an isolated or otherwise approved test arrangement for the unavailable-system-DNS case. Name the monitoring point and narrowly scoped traffic capture in advance. Protect any recorded query names and keep the fallback destination out of an unrelated production DNS change until the privacy and availability owners have reviewed it.\n\n## Verification and evidence\n\nProposed verification: observe an initial startup with the approved system DNS available and record the resolver-list retrieval path. In the separate authorized failure case, make the test system DNS unavailable and observe whether the documented fallback condition is exercised. Restore the starting configuration immediately after that case.\n\nThen issue a harmless ordinary lookup through the intended client path and compare its destination with the bootstrap observation. Inspect the effective listening address and port independently. Retain timings and redacted network evidence; an unexplained unencrypted query should remain a finding rather than being dismissed as normal fallback.\n\n## Official references\n\n- [OPNsense — DNSCrypt-Proxy](https://docs.opnsense.org/manual/how-tos/dnscrypt-proxy.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/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/", "url": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/#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": "Distinguish OPNsense DNSCrypt bootstrap fallback from normal resolution", "item": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/#article", "identifier": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/", "url": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/", "headline": "Distinguish OPNsense DNSCrypt bootstrap fallback from normal resolution", "description": "Review the limited unencrypted fallback used to obtain the initial resolver list separately from the normal encrypted DNS service.", "abstract": "Review the limited unencrypted fallback used to obtain the initial resolver list separately from the normal encrypted DNS service.", "articleBody": "Bottom line: Separate initial resolver-list retrieval from normal DNS query handling. Record exactly when the fallback is permitted and test that condition without calling the whole design private DNS.\nSource fact: what the authority says\nThe OPNsense DNSCrypt-Proxy guide describes Fallback Resolver as a normal, unencrypted DNS resolver. The fallback is used only for one-shot queries to retrieve the initial resolver list, and only if the system DNS configuration does not work. The guide’s Listen Address default is localhost port 5353. Allow Privileged Ports permits binding to ports below 1024.\nWhat the source does not establish\nThis article covers the documented bootstrap fallback and listener choices, not a guarantee about resolver logging or anonymity. It does not recommend exposing a resolver on all interfaces or replacing an existing forwarding design without a separate review.\nApplicability questions\n\nHow will the system obtain its initial resolver list after startup?\nWhich resolver and network path are approved for the fallback condition?\nWhat process sends ordinary client queries to the selected listener?\nDoes the proposed listener need a privileged port, and on which addresses should it listen?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a short sequence diagram for startup and a separate diagram for an ordinary client lookup. Identify system DNS, the initial resolver-list request and the intended encrypted resolver path. Give the fallback its own purpose and owner rather than labeling it as a general emergency DNS service.\nReview the organization’s rules for any unencrypted bootstrap request. If that traffic is unacceptable, pause the deployment decision and obtain a supported alternative design. Do not describe a selected no-log resolver filter as proof that every request in the complete startup sequence is encrypted or unrecorded.\nChoose the listener address and port from the actual forwarding arrangement. Preserve existing resolver and client settings before a pilot. Keep privileged-port permission as a deliberate setting tied to that listener; avoid enabling it just to eliminate an error before understanding which service owns the intended port.\nUse an isolated or otherwise approved test arrangement for the unavailable-system-DNS case. Name the monitoring point and narrowly scoped traffic capture in advance. Protect any recorded query names and keep the fallback destination out of an unrelated production DNS change until the privacy and availability owners have reviewed it.\nVerification and evidence\nProposed verification: observe an initial startup with the approved system DNS available and record the resolver-list retrieval path. In the separate authorized failure case, make the test system DNS unavailable and observe whether the documented fallback condition is exercised. Restore the starting configuration immediately after that case.\nThen issue a harmless ordinary lookup through the intended client path and compare its destination with the bootstrap observation. Inspect the effective listening address and port independently. Retain timings and redacted network evidence; an unexplained unencrypted query should remain a finding rather than being dismissed as normal fallback.\nOfficial references\n\nOPNsense — DNSCrypt-Proxy — 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-29T20:33:08+00:00", "dateModified": "2026-10-29T20:33:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/" }, "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/distinguish-opnsense-dnscrypt-bootstrap-fallback-from-normal-resolution/#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": "Distinguish OPNsense DNSCrypt bootstrap fallback from normal resolution" }, "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": 515, "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 — DNSCrypt-Proxy", "url": "https://docs.opnsense.org/manual/how-tos/dnscrypt-proxy.html" } } ] } }