Indiscriminate fallback to system-/bootstrap-resolvers in case of error/interference/disruption?

[cobratbq]

It seems that the normal code-path for name-resolution always falls back to system- and/or bootstrap-resolvers in case of failure when using the configured (secure) DNS-resolution.

dnscrypt-proxy/dnscrypt-proxy/xtransport.go

Line 580 in 64edfa3

ips, ttl, err = xTransport.resolveUsingServers(proto, host, xTransport.bootstrapResolvers, returnIPv4, returnIPv6)

This is a silent drop of privacy and confidentiality that, in case of DNSCrypt, would be trivial to detect and abuse. Am I reading this wrong? (Case err is non-nil.)

[github-actions]

This issue was automatically closed because it did not follow the issue template. We use the issue tracker exclusively for bug reports and feature additions that have been previously discussed. However, this issue appears to be a support request. Please use the discussion forums for support requests.

[cobratbq]

I referenced a code-line in a new issue. You didn't give me an issue template. That's on you! #3165 (comment)

[jedisct1]

Thanks for taking the time to trace this through the code. I think there’s a mix-up here between the path that handles user DNS queries and the path that resolves dnscrypt-proxy’s own upstream/source hostnames during bootstrap. The line you linked is in the latter path, not the former. 

The sample config is explicit that bootstrap_resolvers are only for internal one-shot lookups, and that no user queries are leaked through them. It also notes that they stop being relevant once resolver IPs are known, and for DNSCrypt servers/relays the stamps already contain IP addresses anyway. 

So while there is a last-resort fallback for internal resolution, describing this as a “silent drop of privacy/confidentiality” for DNSCrypt traffic is not accurate. This is not the query-forwarding path, and it is not downgrading application DNS traffic from encrypted transport to plaintext.

[cobratbq]

Thanks for taking the time to trace this through the code. I think there’s a mix-up here between the path that handles user DNS queries and the path that resolves dnscrypt-proxy’s own upstream/source hostnames during bootstrap. The line you linked is in the latter path, not the former.

Will look into this further.

The sample config is explicit that bootstrap_resolvers are only for internal one-shot lookups, and that no user queries are leaked through them.

This is indeed how I would expect it to be.

It also notes that they stop being relevant once resolver IPs are known, and for DNSCrypt servers/relays the stamps already contain IP addresses anyway.

Indeed. I am aware of that.

So while there is a last-resort fallback for internal resolution, describing this as a “silent drop of privacy/confidentiality” for DNSCrypt traffic is not accurate.

I will look into this further. But let's be realistic. If I misread, then that statement is simply wrong. There is something suspicious though, in some recent issues and circumstances on my side, so I will look into this further.

As a side-note: I created the issue from "reference this line in new issue" in the source-code, and then it immediately presents an empty issue, instead of the predefined template choices.