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.

[ACEx86]

Yes case err != nil.
On error the code bypasses the toml config that ignores the system dns

[ACEx86]

I wonder of 1 things from when i said this.
Internal resolver is not ready -> BootStrapFailled -> SystemDns is listen address when is not ready?
Isn't that a dead lock?

[ACEx86]

Add comments to the code. Abra Katabra
I use this

func (xTransport *XTransport) resolve(host string, is_STAMP, returnIPv4, returnIPv6 bool) (ips []net.IP, ttl time.Duration, err error) {
	dlog.Info("Resolving")
	protos := []string{"udp", "tcp"}
	if xTransport.mainProto == "tcp" {
		protos = []string{"tcp", "udp"}
	}
	if xTransport.internalResolverReady {
		for _, proto := range protos {
			ips, ttl, err = xTransport.resolveUsingServers(proto, host, xTransport.internalResolvers, xTransport.useIPv4, xTransport.useIPv6)
			if err == nil {
				dlog.Infof("- - - Updating complete with protocol: %v   || IP Address: %v", proto, ips)
				break
			}
		}
	} else {
		err = errors.New(" [ ! ] Service is not usable yet")
		dlog.Notice(err)
	}
	if err != nil {
		if xTransport.NoFallback == false || is_STAMP {
			if xTransport.bootstrapResolvers != nil && len(xTransport.bootstrapResolvers) > 0 {
				for _, proto := range protos {
					dlog.Noticef(
						"Resolving server host [%s] using bootstrap resolvers over %s",
						host,
						proto,
					)
					ips, ttl, err = xTransport.resolveUsingServers(proto, host, xTransport.bootstrapResolvers, xTransport.useIPv4, xTransport.useIPv6)
					if err == nil {
						break
					}
				}
			} else {
				if is_STAMP {
					err = errors.New("( ! ) Bootstrap resolvers is empty and STAMP is not available")
				} else {
					err = errors.New("( ! ) Bootstrap resolvers is empty")
				}
				dlog.Notice(err)
			}
		} else if xTransport.NoFallback == true {
			err = errors.New("( ! ) Bootstrap resolver is disabled")
			dlog.Notice(err)
		}

		if err != nil {
			if xTransport.NoFallback == false && xTransport.ignoreSystemDNS == false {
				dlog.Noticef(" ( + ) Bootstrap resolvers didn't respond - Trying with the system resolver as a last resort")
			}
			if xTransport.ignoreSystemDNS == false {
				err = nil
				ips, ttl, err = xTransport.resolveUsingSystem(host, xTransport.useIPv4, xTransport.useIPv6)
				if err != nil {
					err = errors.New("( ! ) System DNS error")
					dlog.Notice(err)
				}
			}
			if xTransport.ignoreSystemDNS == true {
				if len(xTransport.bootstrapResolvers) > 0 {
					dlog.Noticef(" ( ! ) Bootstrap resolver failled and system dns is ignored")
				} else {
					dlog.Noticef(" ( ! ) Bootstrap resolvers is not set and system dns is ignored")
				}
			}
		}
	}
	return ips, ttl, err
}

[cobratbq]

@ACEx86 sure, but his commentary points to the fact that clients connecting to dnscrypt-proxy go through the path of handleDNSExchange in query_processing.go. I was mistaken in my read. That doesn't mean that there isn't something bothering me, but it likely has nothing to do with this. I was simply mistaken. (Even if I do still have the source-code open as I was wondering if there was another code-path that might end up as such. E.g. when anonymization-relay is in use.)

[ACEx86]

I wonder what you mean by This is not the query-forwarding path, this isn't the resolve for DoH i kinda forgot?
Cause it seems like you kinda passing the query to listen address to send it to the DNSCrypt so what?

// If a name is not present in the cache, resolve the name and update the cache
func (xTransport *XTransport) resolveAndUpdateCache(host string) error {
	if xTransport.proxyDialer != nil || xTransport.httpProxyFunction != nil {
		return nil
	}
	if ParseIP(host) != nil {
		return nil
	}
	cachedIPs, expired, updating := xTransport.loadCachedIPs(host)
	if len(cachedIPs) > 0 && (!expired || updating) {
		return nil
	}
	xTransport.markUpdatingCachedIP(host)

	ips, ttl, err := xTransport.resolve(host, xTransport.useIPv4, xTransport.useIPv6)
	if ttl < MinResolverIPTTL {
		ttl = MinResolverIPTTL
	}

if xTransport.ignoreSystemDNS {
		if xTransport.internalResolverReady {
			for _, proto := range protos {
				ips, ttl, err = xTransport.resolveUsingServers(proto, host, xTransport.internalResolvers, returnIPv4, returnIPv6)
				if err == nil {
					break
				}
			}
		} else {
			err = errors.New("dnscrypt-proxy service is not usable yet")
			dlog.Notice(err)
		}
	} else {
		ips, ttl, err = xTransport.resolveUsingSystem(host, returnIPv4, returnIPv6)
		if err != nil {
			err = errors.New("System DNS is not usable yet")
			dlog.Notice(err)
		}
	}

[cobratbq]

No, you're right in your reasoning. You're going at it in exactly the same way as I did. However, supposedly, i.e. I haven't explicitly checked, that code is only used when dnscrypt-proxy starts and no information on DNS-servers is available. That's when it needs some DNS-servers to acquire first information on DNSCrypt-servers. Then, from the downloaded DNSCrypt-servers and -relays (https://github.com/DNSCrypt/dnscrypt-resolvers), it starts the server-process that calls into query_processing.go.

[ACEx86]

That is not true it used at least on DoH querys see the resolveAndUpdateCache is the function that updates the cache.
Fetch is called always unless changed in the latest version i haven't used DoH some months now.

[cobratbq]

I can indeed trace it from processIncomingQuery to resolveAndUpdateCache. You are correct.
I am also checking the DNSCrypt code-path, as that invariably also ends up in xtransport.go, just in case.

I cannot re-open the issue. Otherwise I would've.

[ACEx86]

the xTransport logic is not called only at start up from what i remember, but it is used to get the resolvers file for sure.
For me it seems from watching it that resolve, querys the listen address when system dns is not ignored so prolly a double query happens to pass the dns query to the resolver from that fast look rn.

[ACEx86]

Unless ignoresystemdns is set to true after getting resolvers by the program at start up.
But i think that this

if err != nil && xTransport.ignoreSystemDNS {
		dlog.Noticef("Bootstrap resolvers didn't respond - Trying with the system resolver as a last resort")
		ips, ttl, err = xTransport.resolveUsingSystem(host, returnIPv4, returnIPv6)
	}

bypasses the trust logic of the program for a dns leak. Because if you remove the bootstrap and the program fails, it will do a system query without caring for the option.
So it is a leak because it is using another resolver server also after startup success on a failure when we decide to no matter what ignore it. A small dos, failure, is dropping the query to the system.
The bootsrap resolvers from what i see it is to be used last when resolver and system fails

These are normal, non-encrypted DNS resolvers, that will be only used
for one-shot queries when retrieving the initial resolvers list and if
the system DNS configuration doesn't work.

This here should at least be
if err != nil && !xTransport.ignoreSystemDNS AND STAMP_SERVER_AT_STARTUP { <- to only do this at start up.
and IMPORTANT after successfull retrival of resolver at start up set the ignore system to true to use the internal resolver by default! Else it seems like it is handled by the system taking care sending back the query to the program in some way.

So if im not wrong:
:: Config Default ::
Start up:
Trying the system -> Drops to bootstrap -> End. (Dead lock when no bootstrap and system dns = listen address) < Expected
After:
Trying the system -> Drops to bootstrap -> End. (Prolly system sends query back to program if it is the only listen address) < Usage seems unexpected like leak
:: Ignoring System Dns ::
Start up:
Internal resolver is not ready -> Drops to bootstrap -> Trying the system < Unexpected TOML says otherwise!
After:
Internal resolver fails -> Drops to bootstrap (empty) -> Trying the system when option is ignore (NOT NEEDED TO GET RESOLVERS FILE COULD HAVE FALLEN AFTER FAILURE INSTEAD OF RETRYING) < 1000% leak doesn't follow expectance and option logic the program should just fail it is not THE STARUP!

This at the end is an inverted state usage when not wanted! Should only happen at start up or at serious and resolver only status grabbing errors.
#3166

dnscrypt-proxy/dnscrypt-proxy/xtransport.go

Lines 586 to 589 in 64edfa3

	if err != nil && xTransport.ignoreSystemDNS {
	dlog.Noticef("Bootstrap resolvers didn't respond - Trying with the system resolver as a last resort")
	ips, ttl, err = xTransport.resolveUsingSystem(host, returnIPv4, returnIPv6)
	}