http3_probe might make you think DNSCrypt is broken

[sergeevabc]

DNSCrypt version 2.1.15 and master as of 2026-04-21.

Let's say user has enabled http3 and http3_probe, you know, to touch the progress.
But there are no fresh public-resolvers.md and relays.md in the app's folder yet.
This is what happens

[2026-04-21 05:09:42] [NOTICE] dnscrypt-proxy 2.1.15
[2026-04-21 05:09:42] [NOTICE] Using default Weighted Power of Two (WP2) load balancing strategy
[2026-04-21 05:09:42] [NOTICE] Network connectivity detected
[2026-04-21 05:09:42] [NOTICE] Now listening to 127.0.0.1:53 [UDP]
[2026-04-21 05:09:42] [NOTICE] Now listening to 127.0.0.1:53 [TCP]
[2026-04-21 05:09:42] [NOTICE] dnscrypt-proxy service is not usable yet
[2026-04-21 05:09:42] [NOTICE] Resolving server host [raw.githubusercontent.com] using bootstrap resolvers over udp
[2026-04-21 05:10:22] [NOTICE] Source [public-resolvers] loaded
[2026-04-21 05:11:02] [NOTICE] Source [relays] loaded
[2026-04-21 05:11:02] [NOTICE] Firefox workaround initialized
[2026-04-21 05:11:02] [NOTICE] Hot reload is disabled
...

It took 40 (!!!) seconds to get resolvers (160 KB) and then 40 (!!!) more seconds to get relays (60 KB). At first, I did not wait that long and stopped it manually, then went through the entire OS stack from the network card settings to UDP settings of the firewall looking for some error. I was confused, lost and frustrated.

Right now the developer's comment says 'when http3 is true, always try HTTP/3 first for DoH servers'. Then there is some warning that says it would be 'significantly slower for servers that don't support HTTP/3' but again, it is perceived in relation to DoH, and not to Github, from where the service files are downloaded.

When http3_probe is turned off, downloading both files takes… a second!

To isolate whether the issue is network-level or application-level, I tested with curl 8.19.0:

• curl -v -I --http3-only https://raw.githubusercontent.com/… ends with handshake timeout in 10s
• curl -v -I --http3 https://raw.githubusercontent.com/… falls back to HTTP/2 within 2s, then 200 OK

I see a few ways to address this:

• bring the code in line with the comment and do not use http3 when downloading service files
• expand the comment by explaining that this setting has a global effect, Github included
• use http3-capable mirror https://cdn.jsdelivr.net/gh/DNSCrypt/dnscrypt-resolvers@master/v3/public-resolvers.md

[jedisct1]

Thanks! 41d01fd should mitigate this, even though I expect https://download.dnscrypt.info to support HTTP/3.

[sergeevabc]

Your fix works indeed, public-resolvers.md is downloaded from Github instantly now.
However, checking some resolvers still takes a noticeable time.
For example, multiple resolvers (DoH included) are checked here within 1s, then suddenly 5s delay.

...
[2026-04-21 16:51:33] [NOTICE] [dnsforfamily-no-safe-search] OK (DNSCrypt) - rtt: 15ms
[2026-04-21 16:51:33] [NOTICE] [saldns02-conoha-ipv4] OK (DNSCrypt) - rtt: 289ms
[2026-04-21 16:51:33] [NOTICE] [controld-uncensored] OK (DoH) - rtt: 15ms
[2026-04-21 16:51:33] [NOTICE] [doh.tiar.app] should upgrade to XChaCha20 for encryption
[2026-04-21 16:51:33] [NOTICE] [doh.tiar.app] OK (DNSCrypt) - rtt: 330ms
[2026-04-21 16:51:33] [NOTICE] [iij] OK (DoH) - rtt: 59ms
[2026-04-21 16:51:33] [NOTICE] [cleanbrowsing-family] should upgrade to XChaCha20 for encryption
[2026-04-21 16:51:33] [NOTICE] [cleanbrowsing-family] OK (DNSCrypt) - rtt: 19ms
[2026-04-21 16:51:33] [NOTICE] [jp.tiar.app] should upgrade to XChaCha20 for encryption
[2026-04-21 16:51:33] [NOTICE] [jp.tiar.app] OK (DNSCrypt) - rtt: 278ms
[2026-04-21 16:51:33] [NOTICE] [jp.tiar.app] OK (DNSCrypt) - rtt: 278ms
[2026-04-21 16:51:38] [NOTICE] [doh-cleanbrowsing-adult] OK (DoH) - rtt: 12ms
...

even though I expect https://download.dnscrypt.info to support HTTP/3.

Dnscrypt.info is hosted on BunnyCDN, which uses CDN77 infrastructure, which is banned in Russia: 16 KB of data are transferred fine, but then the connection freezes. They are hesitant to do the same with Github and jsDelivr (both hosted on Fastly).

[jedisct1]

For resolvers, this is expected and documented. Solution is to use DNSCrypt, or tell the resolver operator to fix their server.
Or just don't use that option. It's disabled by default for a reason.

It's sad news that BunnyCDN has been banned in Russia :(

jsdelivr seems to be using 4 different CDNs including Bunny, so it may be unreliable. It's also designed for javascript, so abusing it to deliver something else may led to being nuked.

[sergeevabc]

jsdelivr seems to be using 4 different CDNs including Bunny, so it may be unreliable

Unless you specify the required CDN in URL, for example:
https://fastly.jsdelivr.net/gh/DNSCrypt/dnscrypt-resolvers@master/v3/public-resolvers.md
https://gcore.jsdelivr.net/gh/DNSCrypt/dnscrypt-resolvers@master/v3/public-resolvers.md

it's designed for javascript, so abusing it to deliver something else may led to being nuked

cc: @jimaek

Dear Dmitriy, you're founder of jsDelivr, it has an official tool to convert Github resources links. Can we use this service to distribute non-Javascript resources such as a list of public DNSCrypt resolvers?

[jimaek]

Hey, of course. We serve plenty of adblock lists for example

[sergeevabc]

@jedisct1
It seems you now have the official permission to use jsDelivr to distribute DNSCrypt resolvers data.
Since Github already utilizes Fastly, I'd add Gcore mirror (see link above) to dnscrypt-proxy.toml.
It would make the application more robust and resilient.

[sergeevabc]

@jedisct1
By the way, I noticed a ~5s delay with http3_probe=true when connecting to dns4all-ipv4 resolver.

• But they claim to support HTTP/3 and Curl output confirms that Alt-Svc header is present and in order.

$ curl -I https://doh.dns4all.eu/dns-query
HTTP/2 400
content-type: text/plain; charset=utf-8
content-length: 56
x-dns4all: arn1-1_v4
alt-svc: h3=":443"

• So I started examining the stamp of that resolver in public-resolvers.md: sdns://AgMAAAAAAAAACTE5NC4wLjUuMwAOZG9xLmRuczRhbGwuZXUKL2Rucy1xdWVyeQ

• Oh my gosh, someone put doq.dns4all.eu (DNS over QUIC) in host name instead of doh.dns4all.eu.

• I fixed the stamp as follows
  sdns://AgMAAAAAAAAACTE5NC4wLjUuMyBS3thgfYKHCK7yYZ5IyaYhcJOJNYr2BDrEQ1rVVyCmsQ5kb2guZG5zNGFsbC5ldQovZG5zLXF1ZXJ5

Now I see a delay, then the next time I don’t, it’s so strange.