resolution fails when the date of the server is more than 2 days late

[Stuart Henderson]

On 2020/03/02 07:59, dy1977--- via Unbound-users wrote:
> I am running unbound on SBC cards (Raspberry Pi, Tinker board, Rock64).
> These cards don't have a hardware clock. They are set to resolve to
> 127.0.0.1 so that the local processes use Unbound for DNS requests.
> Everything fine here.
> 
> But when I don't have used a card for more than 1 or 2 days (I didn't test
> the exact threshold), when I start one, I get in a vicious cycle :
> 
> The clock is 2 days or more late
> All DNS resolutions fail because of this difference
> ntp.org calls fail
> The clock is not updated
> All DNS resolutions fail
> And so on...
> 
> The way out of the cycle is to set the date manually, after that everything
> is fine again. But the user is not expected to do that in a linux command
> line.
> 
> Is there a way to prevent this behaviour from unbound, and get at least
> ntp.org resolved when there is a serious clock drift ?

Unbound is working exactly as it should.

The NTP daemon could be smarter. During initial bring-up it can set the
CD (check disabled) flag on its DNS queries, initially set the clock, and
then unset the CD flag so that later queries are protected. openntpd in
recent OpenBSD versions does this but it hasn't made it opdnntpd-portable
yet.

> I could do that by setting the ip address of ntp.org somewhere, but if this
> ip address changes one day, the system will fail again, so I don't like it.

You could set the clock initially, with a "one shot" time fetcher like
ntpdate or tlsdate, from a service with a fixed IP and then use
pool.ntp.org servers in your main NTP software. Hardcoding an IP
address from ntp.pool.org is a bad idea - their servers are more likely
to come and go - but there are other NTP servers on stable addresses.
For example you could use one or more of the addresses behind
time.cloudflare.com or time.google.com.

If you really don't want to hardcode an NTP server IP address, you
could use an external public DNS resolver (9.9.9.9, 1.1.1.1,
8.8.8.8, etc) initially to find the IP address for the "one shot"
fetcher. Either lookup using dig(1) or similar pointed directly at
that server and use the result in the command, or switch out the
resolv.conf file. Or if you prefer to use your own resolver for
this, you could use dig +cdflag.