Added odoh-cipherdns-jb1-za server details

[rb-sys]

Added information about the odoh-cipherdns-jb1-za server, including its features and SDNS.

[jedisct1]

Thanks for the contribution!

The entry format and stamp are valid: the stamp correctly decodes as an ODoH target for:

jb1-odoh.cipherdns.co.za
/dns-query

However, I tested it as an actual ODoH target through the resolver list’s ODoH relay test path, and it currently fails with malformed responses:

FAIL: odoh-cipherdns-jb1-za
Unable to decrypt response from [test-server]: [Malformed response]
No valid network configuration for [test-server]

Existing ODoH targets pass with the same test setup, so this doesn’t appear to be a local test issue.

Could you please check the server-side ODoH implementation and ensure that it works reliably through public ODoH relays? Once the target passes ODoH resolution tests, we can reconsider merging this entry.

For now, I can’t merge this as-is.

[rb-sys]

Hi,

Thank you for the detailed feedback on the initial PR. I’ve taken your notes to heart and have worked on hardening the infrastructure.

To address the reliability and "malformed response" issues, I have migrated the entire web server stack from Nginx to Caddy. This change was specifically made to ensure the server handles the raw binary streams and HTTP/3 requirements of ODoH more transparently, without the request buffering that I suspect was causing the relay validation to fail.

Since the migration, I am seeing consistent and stable connectivity. I have attached the latest dnscrypt-proxy logs from startup, which show the following sequence:

Jun 03 19:14:34 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:34] [NOTICE] Resolving server host [jb1-odoh.cipherdns.co.za] using bootstrap resolvers over udp
Jun 03 19:14:34 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:34] [NOTICE] Anonymizing queries for [odoh-jb1-cipher] via [odohrelay-crypto-sx]
Jun 03 19:14:39 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:39] [NOTICE] dnscrypt-proxy service is not usable yet
Jun 03 19:14:39 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:39] [NOTICE] Resolving server host [odoh-relay.edgecompute.app] using bootstrap resolvers over udp
Jun 03 19:14:39 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:39] [WARNING] Unable to decrypt response from [odoh-jb1-cipher]: [Malformed response]
Jun 03 19:14:39 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:39] [NOTICE] Anonymizing queries for [odoh-jb1-cipher] via [odohrelay-numa]
Jun 03 19:14:42 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:42] [NOTICE] dnscrypt-proxy service is not usable yet
Jun 03 19:14:42 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:42] [NOTICE] Resolving server host [odoh-relay.numa.rs] using bootstrap resolvers over udp
Jun 03 19:14:44 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:44] [NOTICE] [odoh-jb1-cipher] OK (ODoH) - rtt: 344ms
Jun 03 19:14:44 cachyos-x8664 dnscrypt-proxy[9786]: [2026-06-03 19:14:44] [NOTICE] Server with the lowest initial latency: odoh-jb1-cipher (rtt: 344ms), live servers: 1

Initial bootstrapping and relay discovery.

A brief "Malformed response" warning (which seems to occur during the initial cryptographic handshake/key discovery phase).

A successful transition to [OK (ODoH)] within a few seconds, with stable RTTs.

My question regarding the logs:
Is the initial [Malformed response] warning during the first 5–10 seconds of the service startup expected behavior while the relay and target synchronize keys? It seems to clear up immediately once the tunnel is established, but I want to be certain this isn't masking a configuration oversight on my end.

If you are still seeing failures on your side, could you please share any specific debug/error codes the relay is seeing when it hits my endpoint? I want to ensure my Caddy configuration is perfectly aligned with what the public relays expect.

I believe the stack is now much more robust, and I'd appreciate it if you could re-run the relay validation tests when you have a moment.