Three ways to set up your DNS — every click shown.

Each setup below is fully encrypted and works behind the kill switch. They differ only in how much the resolver learns about you. Start with the two-minute first run, then pick a setup — every step comes with a real screenshot of the app, and the amber ring marks exactly where to click.

Open DnsCryptControl from the Start menu — it opens on the Dashboard. (If no window appears, it started minimised to the system tray: click the shield icon near the clock, bottom-right.) The kill switch is on by default (recommended — it’s fail-closed), so first run is just two clicks:

1. Turn the main switch On. This sends your DNS through the encrypted proxy — and because the kill switch is already on, nothing can quietly fall back to unprotected DNS if the proxy ever stops. The badge turns green “You’re protected” only after a live leak check actually passes — you may briefly see Verifying… first. The first time, Windows recommends a one-time reboot to finish a related leak fix (Smart Multi-Homed Name Resolution) — that reboot comes from enabling protection, and your encrypted DNS is already active before you reboot.
2. Set Browser DoH (DNS-over-HTTPS — the browser’s own built-in encrypted DNS) to blocked, so Chrome, Edge and Firefox can’t quietly bypass the app with it.

DNS is always a round trip — the question goes out and the answer comes back, both inside the same encrypted connection. Anyone watching the network sees only that your PC talked to 9.9.9.9 over an encrypted channel — never what you asked or what came back.

There are no extra steps: First run above is Setup 1, using the default quad9-doh-ip4-port443-filter-pri. Prefer a different resolver? Use the moves shown in Setup 2, steps 1–3 (Resolvers tab → search → select → Use only this server → Save & apply) and skip the relay part — used directly like this, any protocol is fine (the “must be a DNSCrypt server” note in Setup 2 only applies when you route through a relay).

Both directions pass through the relay, and the relay can read neither: the question is encrypted end-to-end for the resolver, and the answer is encrypted end-to-end for you. The resolver answers a question that arrives from the relay’s address — it never learns yours. For this to mean anything, the relay and resolver should be run by different operators.

1

Resolvers tab → search. Type a DNSCrypt server’s name — here quad9-dnscrypt-ip4-filter-pri. It must be a DNSCrypt server (or an ODoH one, Setup 3): plain DoH can’t travel through these relays.

2

Select the server, then click “Use only this server” in the detail pane on the right. (Or “Add to pool” if you want to keep your current servers too.)

3

Click “Save & apply” (top right). The “only resolver” notice is expected — it’s just telling you there’s no fallback server.

4

Anonymized DNS tab → the “Add a route” bar at the bottom: pick your server (1), pick a relay (2), and click Add route (3). Then Save & apply once more. For real anonymity, prefer a named relay run by a different company than your resolver (the relay name carries its operator); * picks any compatible relay but can’t guarantee the operators differ.

Route applied but nothing resolves? A few networks (some VMs, NATs and strict firewalls) silently drop the larger UDP packets anonymized DNSCrypt uses — the app shows an amber “DNS not resolving through this route” notice. Fix it with Always use TCP (force_tcp) in Configuration → Connection. Leave it off for ODoH (Setup 3), where it can break the bootstrap anchor.

5

Check the result. The Coverage bar turns green: every anonymizable server in your pool now has a route. Use Edit / Remove on the row to change it later.

6

Back on the Dashboard, the active resolver now shows the DNSCrypt server — verified by a live leak check, reached only through the relay.

The same who/what split as Setup 2, but the relayed ODoH queries ride ordinary HTTPS (port 443), so they blend in with regular web traffic (the bootstrap anchor’s DNSCrypt traffic on port 8443 doesn’t). The round trip happens inside a single HTTPS request: the relay posts your sealed question to the target and hands you back the sealed answer. As with Setup 2, this only holds if the relay and target are run by different operators. One plain DNSCrypt server stays unrouted in your pool as the bootstrap anchor — the proxy uses it (over the app’s own local connection, which the kill switch deliberately leaves open) to fetch and refresh the ODoH server/relay lists.

1

Resolvers tab → tick the ODoH filter. This shows only ODoH-capable entries.

2

First time, the list is empty — click “Add ODoH server lists”. ODoH servers live in two extra lists that aren’t configured out of the box.

3

Confirm with “Add lists”. The dialog shows the two official DNSCrypt-project URLs. The app itself makes no network connection — it places its own bundled, signature-verified copies, and the dnscrypt-proxy service keeps them updated from the official source.

4

Search odoh-cloudflare → select it → “Add to pool” → Save & apply.

Keep one plain DNSCrypt server in the pool, unrouted. An ODoH target can’t bootstrap itself — the proxy needs a working resolver to fetch the relay/target lists.
• From Setup 2 (a DNSCrypt server already routed): just Remove its route on the Anonymized DNS tab so it becomes the anchor.
• From First run / Setup 1 (only a DoH server): a DoH server can’t be the anchor — first add a plain DNSCrypt server with Setup 2 steps 1–2, but click Add to pool (not “Use only”) and give it no route.

5

Anonymized DNS tab: pick odoh-cloudflare (1), pick an odohrelay-* relay (2), click Add route (3), then Save & apply. An ODoH target only works through a relay — without a route it simply stays unused.

6

Check the result. The route row shows odoh-cloudflare via your relay. The amber coverage note about one server having no route is expected — that’s your bootstrap anchor resolving directly, by design.

7

Dashboard: protected. The proxy’s own log confirms the ODoH target came up (OK (ODoH) in Logs & Diagnostics), verified by the same live leak check as every other setup.

Honest note on privacy. Day to day the proxy load-balances across your pool, and it tends to favour the faster direct anchor over the slower relayed ODoH path — so a share of everyday queries is answered directly by the anchor, which sees both your IP and your question. So Setup 3 is not strictly more private than Setup 2 as configured — choose it for the HTTPS transport (traffic blending), not for extra anonymity. If you want every query relayed, Setup 2 is the stronger choice.

Most of the ~118 settings in the Configuration tab are internal dnscrypt-proxy knobs (timeouts, TLS options, cache sizes) that already ship with good defaults. A small “(default)” marker sits next to any setting you haven’t changed — if it says (default), the proxy is already using its recommended value. Don’t tweak these without a specific reason.