Questions about ECH when setting up dnscrypt-proxy on OpenWRT

[beebo-1]

My plan is to run dnscrypt-proxy on my OpenWRT router, using either the anonymized or ODoH relay modes, and connecting to either quad9 or Cloudflare resolvers after the relay.

I understand that for encrypted client hello to work, the browser, router, and website all have to support it. However, I was still confused on a few things.

1. Assuming the browser and website support it, does ECH work through dnscrypt-proxy if you are using the anonymized or ODoH relay setups as I've described above?
2. I found the docs relating to ECH/local DoH for Firefox, but I was wondering if the cert and about:config setup steps were still necessary. Has Mozilla modernized the way Firefox handles ECH? I also wondered if this step was for encrypting your LAN DNS lookups for local devices behind the router, to hide them from other devices on LAN.
3. It kind of ties into the above, but is the Cloudflare resolver necessary for ECH to work with dnscrypt-proxy, or would quad9 work too? The above docs seem to imply it's not necessary for Firefox, but that it is necessary for Chrom(e|ium). The reason I just wanted to double check is because comments elsewhere said Cloudflare was always required.

I apologize if anything is wrong or easily verifiable. This project is incredibly interesting and I am still learning about it.

[wellkilo]

It helps to separate the three links involved here:

1. browser → your router / dnscrypt-proxy;
2. dnscrypt-proxy → recursive resolver;
3. browser → website (TLS, where ECH is used).

Anonymized DNSCrypt or ODoH affects link 2. ECH affects link 3. They are compatible: the relay transport does not prevent ECH as long as the final DNS answer delivered to the browser contains the site's HTTPS/SVCB record and its ECH configuration. The dnscrypt-proxy Local DoH wiki explicitly says the upstream resolver does not have to use Cloudflare or DoH, and that ECH is compatible with DNSCrypt and Anonymized DNSCrypt.

For your questions:

1. Yes, ECH can work through anonymized DNSCrypt or ODoH. The relay sees encrypted DNS traffic; the recursive resolver returns the HTTPS record; the browser performs ECH with the origin/CDN. Test the actual result rather than assuming it from transport choice, because a resolver or filtering layer can omit HTTPS records.

2. The certificate is still required only if Firefox connects to your local dnscrypt-proxy over HTTPS. A local DoH URL such as https://127.0.0.1:3000/dns-query needs a certificate Firefox trusts; otherwise the DoH TLS handshake fails. This certificate protects browser → router DNS traffic. It is unrelated to the website's ECH certificate/key.

   The old individual ECH/ESNI preference list in the wiki is dated. Mozilla documents ECH as enabled by default since Firefox 119. You should not enable the deprecated network.security.esni.enabled preference. What you still need to configure is Firefox's Secure DNS custom provider if you want Firefox to use your local DoH endpoint rather than its selected public DoH provider.

3. Cloudflare is not an ECH protocol requirement. Any recursive resolver can support the workflow if it returns the necessary HTTPS/SVCB records intact, and the target site/CDN publishes a valid ECH configuration. Cloudflare appears frequently in older instructions because early Firefox/ESNI experiments and many ECH-enabled sites used Cloudflare. Chromium's requirement is a suitable Secure DNS/ECH setup, not specifically the Cloudflare brand.

A practical verification path is:

# Query through the local dnscrypt-proxy listener and inspect HTTPS records.
dig @127.0.0.1 example.com HTTPS

# If using local DoH, verify the endpoint itself without exposing query logs.
curl -I https://127.0.0.1:3000/dns-query

Then use the browser's network/security diagnostics for a known ECH-enabled site. A successful encrypted DNS query alone does not prove ECH was negotiated, and an ECH-capable DNS response does not guarantee that every site supports ECH.

For an OpenWrt deployment, ordinary LAN DNS to port 53 is not encrypted on link 1. If hiding queries from other LAN observers matters, use a trusted local DoH endpoint (or another encrypted stub-to-router transport); the DNSCrypt/ODoH hop beginning at the router only protects traffic after it leaves the router.

If this clears up the resolver/browser boundary, please mark it as the accepted answer.