Use encrypted dns for bootstrap_resolvers

[linsui]

Though that's not a privacy problem to use a plain text dns for bootstrap, the results can be polluted and then dnsctypt-proxy won't work. Could you please support resolve the two domains with an encrypted dns server or even set static ips for them? Thanks!

[lessload]

Good ideas.!! I already ask them long time ago. seem liken they not care about it. I solve by disable netprobe.

[cobratbq]

There is an important difference here. IIUC netprobe is only used to check if there is a network path to the internet. It does not query/send any relevant information there. If you "fixed" the issue with netprobe, then there was not really an issue, AFAICT.

[cobratbq]

Do I understand correctly that your concern is that a normal ("old-style", plain text) DNS resolver is used during initialization of dnscrypt-proxy? If so, the DNS stamps that are used in the list of DNS servers used by dnscrypt-proxy also contains an address (IPv4/IPv6) for each of the available servers. Although optional, these addresses are provided in most cases. If provided (and correct), the fallback/bootstrap resolvers are not necessary anymore. (IIUC)

[linsui]

Yes. But the list itself is hosted on github and dnscrypt.info and dnscrypt-proxy need to resolve the two domains first.

[cobratbq]

Good point. That list is signed, so authenticity is not (shouldn't be) a problem. Your concern is with denying access to the list? (Hence not being able to get the first-time data needed to get started.)

[linsui]

Yes, that's my point.

[linsui]

And it make sense to use available servers to resolve those servers without an ip in the stamp.

[Horizonbli]

2021... 2023... Isn't it possible to first make the connection to the encrypted DNS servers, and only then fetch those lists?

#2362

[jedisct1]

Those lists describe how to connect to encrypted DNS servers.

[linsui]

Yes, bootstrap. But I hope that I can provide a encrypted server for bootstrap.

[lifenjoiner]

b3318a9 has been merged.

[ghost]

Thanks, but the new description doesn't make any sense to me. What happens when now? What changes when I flip the pref?

## This is a switch for prior bootstrap resolvers.
##
## Most of the time, the system DNS leads to dnscrypt-proxy itself,
## if you set up dnscrypt-proxy in the system DNS chain.
##
## If true, dnscrypt-proxy will directly try on its own service instead.
## Together with bootstrap resolvers, upstream hosts will be resolved most
## of the time.
## The system DNS still will be a last resort, if it has been ignored.

[lifenjoiner]

The description has been improved by b9f8f78.

The new behavior only takes effect when ignore_system_dns = true.
If ignore_system_dns = false, it tries the system DNS instead. And the queries are very likely forwarded to dnscrypt-proxy finally, I guess.

[ghost]

Thanks, I understand it now. However the new description makes it sound as if it's a 3 step process with the last one being controlled by the pref. But it's actually only the first 2 steps when pref is true and only the 3rd step when pref is false, right?

[lifenjoiner]

The 3rd one will be tried, if ignore_system_dns = true, like plan C.

Query on	Alias
listen_addresses	A
bootstrap_resolvers	B
System DNS	C

ignore_system_dns:

true	false
A -> B -> C	C -> B

B -> C:

The system DNS still will be a last resort, if it has been ignored.