search

getdnsapi / stubby

Stubby is the name given to a mode of using getdns which enables it to act as a local DNS Privacy stub resolver (using DNS-over-TLS).
https://dnsprivacy.org/dns_privacy_daemon_-_stubby/
BSD 3-Clause "New" or "Revised" License
1.17k stars 97 forks source link

Feature Request: fallback resolver. #146

Open odkrys opened 5 years ago

odkrys commented 5 years ago

Normally embedded devices don't have battery to save system time. For this reason, the devices fail to get auth of tls resolver so they fail to resolve ntp server name when start or restart with stubby. We can configure ntp server name go through specific server like "server=/pool.ntp.org/1.1.1.1" but it would be better if stubby support solution itself.

Another dns encryption package dnscrypt-proxy2 has fallback_resolver option. Can this feature implement in stubby ?

## Fallback resolver
## This is a normal, non-encrypted DNS resolver, that will be only used
## for one-shot queries when retrieving the initial resolvers list, and
## only if the system DNS configuration doesn't work.
## No user application queries will ever be leaked through this resolver,
## and it will not be used after IP addresses of resolvers URLs have been found.
## It will never be used if lists have already been cached, and if stamps
## don't include host names without IP addresses.
## It will not be used if the configured system DNS works.
## A resolver supporting DNSSEC is recommended. This may become mandatory.
##
## People in China may need to use 114.114.114.114:53 here.
## Other popular options include 8.8.8.8 and 1.1.1.1.

fallback_resolver = '9.9.9.9:53'
odkrys commented 5 years ago

It looks dnscrypt-proxy2 accept 9 months difference while stubby only accept 2 months difference of system time. fallback_resolver of dnscrypt-proxy2 is not designed to resolve the problem described above.

I still hope to find something solution what handle this problem as well. Right now, manual configuration or fake-hwclock would be helped.

ArchangeGabriel commented 5 years ago

The limit in system time difference only depends on upstream certificates validity. What you observed is that the upstream you’ve used in stubby have certificates valid for two more months (likely Let’s Encrypt, or just close to EOL certificates), while the one(s) used in dnscrypt-proxy are for nine more months. Retrying that latter would give different results.

odkrys commented 5 years ago

You are right. Before ntp sync, my system time was May 05 2018. Cloudflare DoH cert valid at Mar 22 2018 - Mar 25 2020. And DoT cert valid at Nov 02 2018 - Nov 06 2020.

When I set system time at Mar 05 2018, both services didn't work at all.

Mar  5 20:00:51 dnscrypt-proxy[28642]: Get https://dns.cloudflare.com/dns-query?ct=&dns=yv4BAAABAAAAAAABAAACAAEAACkQAAAAgAAAAA: x509: certificate has expired or is not yet valid
Mar  5 20:00:51 dnscrypt-proxy[28642]: dnscrypt-proxy is waiting for at least one server to be reachable
[11:01:37.366763] STUBBY:    *FAILURE* no valid transports or upstreams available!
Could not schedule query: None of the configured upstreams could be used to send queries on the specified transports

Anyway fallback_resolver didn't work. So both services required special setting to handle initial ntp sync. I reopen this and will wait for the opinion.

tomdov commented 5 years ago

Hello, from your query it seems like the Opportunistic profile is what's needed for this case: if the authentication isn't succeeding, it will fail back to clear - then allow the ntp to be resolved, ntp will sync the system. Have you tried it?