Dear Maintainer,

A bug was recently found where DNS stamp information is used
incorrectly to fill the resolver cache on initialization.

In short, DNS stamps of the various DNSCrypt/DoH/etc. resolvers include
hostname and port information for finding the server. Additionally, it
(optionally) includes an IPv4/IPv6 address to find the server without
nameserver resolution for bootstrapping/initialization purposes, in such
cases where it is unreliable or unavailable.

dnscrypt-proxy intends to use this address in all cases - caching the
address with unlimited lifetime, but accidentally stored it with incorrect
key "hostname with optional port number". Subsequently loading from a key
"hostname" will fail to load the address from the cache.

Consequently, in all cases of DoH servers that include a port number,
the bootstrapping address could not be loaded and dnscrypt-proxy needs to
rely on the system resolver to look up the address anyways.

The details can be found in
https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861
and a side-effect was under discussion at
https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1828

It is beneficial to use the DNS stamp information both for speed and
reliability of resolution.

Kind regards,
Danny


PS: I am not familiar with bug reporting or bug handling in Debian. Please
let me know if I should do things differently. I may be able to help if
you want to cherry-pick the bugfix from upstream. (Although I am not
affiliated with the project in any way.)

Thanks for the report. I've marked it forwarded upstream, and the fix
appears to be in
https://github.com/DNSCrypt/dnscrypt-proxy/commit/0f00cd27f92cee434336c6d6cde9df26286d8dbe. Do
you think this is serious enough to warrant cherrypicking into the
package or should we just wait for the next upstream release?

* Danny van Heumen (danny@dannyvanheumen.nl) wrote:

Hi Eric,

Indeed, a fix was implemented.

Yes. I think that the address from the public-resolvers document should take precedence over the address from an arbitrary resolver.

Kind regards,
Danny

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Actually, what I said below is meaningless. The fact is, that precedence was chosen by design. The fix we're talking about here merely ensures consistent behavior under all circumstances. (Correcting mainly because I'm annoyed by my own inaccurate response.)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Hi Eric,

It has been quiet for a while. I'd like to hear what your thoughts are on this.

Kind regards,
Danny

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐