Distinguish OPNsense DNSCrypt bootstrap fallback from normal resolution

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.

Source fact: what the authority says

The 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.

What the source does not establish

This 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.

Applicability questions

• How will the system obtain its initial resolver list after startup?
• Which resolver and network path are approved for the fallback condition?
• What process sends ordinary client queries to the selected listener?
• Does the proposed listener need a privileged port, and on which addresses should it listen?

DSE recommendation: controlled next steps

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

DSE 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.

Review 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.

Choose 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.

Use 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.

Verification and evidence

Proposed 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.

Then 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.

Official references

• OPNsense — DNSCrypt-Proxy — 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.