Most dnscry.pt ODoH servers return malformed response

[syphyr]

I am testing ODoH with dnscrypt-proxy 2.1.17 on Ubuntu x86_64. Everything seems to work fine, except most of the ODoH servers starting with "dnscry.pt" return a malformed response. The only one that I could get working so far is dnscry.pt-odoh-munich. Are most of those "dnscry.pt" servers not being maintained?

This is the only "dnscry.pt" server route that seems to work:

routes = [
{ server_name='dnscry.pt-odoh-munich', via=['odohrelay-crypto-sx', 'odohrelay-numa'] }
]

I see messages like this:

[2026-07-13 21:50:28] [NOTICE] Anonymizing queries for [dnscry.pt-odoh-zurich] via [odohrelay-crypto-sx]
[2026-07-13 21:50:31] [WARNING] Unable to decrypt response from [dnscry.pt-odoh-zurich]: [Malformed response]

[CoderDeltaLAN]

I may be wrong, but if Munich works with the same kind of route and the others fail with Malformed response, I’d suspect the dnscry.pt ODoH targets rather than your config. I’d try one failing target with a couple of different relays just to rule that out, then report the failing names upstream if they still break

[syphyr]

There are only two available ODoH relays (odohrelay-crypto-sx and odohrelay-numa). I do not think the problem is with the relays because they both work with odoh-crypto-sx, odoh-cloudflare, and odoh-snowstorm. There is just an issue with most of the dnscry.pt* ODoH servers returning malformed responses.

[welwood08]

Included in 2.1.17 was a change to validate ODoH padding length "to spot broken server implementations" (43bd978). If this stricter validation is the cause and those servers "work" with older versions, then it would seem the change has done its job.

Since 2.1.17 (and indeed the change to validation) has been available for less than 1 day, I would allow the maintainer of those servers time to react rather than jump to any conclusions just yet. I read last week regarding dnscry.pt a long post about the service and the problems of over-expansion, increased costs, unreliable hosts, fake abuse reports, AI-generated support requests, etc. I don't want to add to that maintainer's burden unnecessarily, I'm sure if they're not already aware of this issue they will be soon as users begin to upgrade, so I'll just forward this quote from their post to hopefully assuage any concerns here of lack of maintenance:

the future of dnscry.pt is not about endless expansion anymore. It is about keeping the project useful, privacy-respecting, and sustainable without burning out the person maintaining it.

dnscry.pt is not going away.

[jedisct1]

I don't think the padding-length check is related.

Many dnscry.pt ODoH servers take a long time to respond, longer than the relay timeout.

A number of them have been removed until the issue is resolved.

[Romulo-Romero]

There seems to be some serious issues with the latest version as it combines tcp and udp even if force_tcp is set to false. Long delays and some resolvers time out randomly. Ip packet fragmentation issues such as tiny fragments which my IPS drops and therefore I cannot get only the legitimate traffic. The servers delay shows the same as if I were using force_tcp option, which explains why it is using tcp in wireshark. Terrible update !

[jedisct1]

What does that have to do with ODoH?

[Romulo-Romero]

I assume maybe nothing, but the new changes look sketchy to say the least, not behaving normal as it used to be, I took advantage of this thread to expose the current issues as I found it suited.

[CoderDeltaLAN]

Thanks, that explains it. There doesn’t seem to be anything wrong with @syphyr’s route. For now, I’d stick with Munich or another target that completes through the relay. It might also be worth adding an end-to-end ODoH check before targets are added back, since fetching /.well-known/odohconfigs alone won’t catch a slow query path. Just a thought