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 ‐‐‐‐‐‐‐ On Friday, September 10th, 2021 at 7:40 AM, Eric Dorland <e...@debian.org> wrote: > Control: forwarded -1 https://github.com/DNSCrypt/dnscrypt-proxy/issues/1861 > > 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 (da...@dannyvanheumen.nl) wrote: > > > Package: dnscrypt-proxy > > > > Version: 2.0.45+ds1-1+b5 > > > > Severity: normal > > > > X-Debbugs-Cc: da...@dannyvanheumen.nl > > > > 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.) > > > > -- System Information: > > > > Debian Release: 11.0 > > > > APT prefers stable-security > > > > APT policy: (500, 'stable-security'), (500, 'stable') > > > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) > > > > Kernel taint flags: TAINT_USER > > > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_US:en > > > > Shell: /bin/sh linked to /usr/bin/dash > > > > Init: systemd (via /run/systemd/system) > > > > LSM: AppArmor: enabled > > > > Versions of packages dnscrypt-proxy depends on: > > > > ii adduser 3.118 > > > > ii libc6 2.31-13 > > > > ii lsb-base 11.1.0 > > > > dnscrypt-proxy recommends no packages. > > > > Versions of packages dnscrypt-proxy suggests: > > > > pn resolvconf <none> > > > > -- Configuration Files: > > > > /etc/dnscrypt-proxy/dnscrypt-proxy.toml changed [not included] > > > > -- no debconf information > > Eric Dorland e...@kuroneko.ca > > 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
