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

Talkabout talk.about at gmx.de
Mon Mar 2 07:12:09 UTC 2020


Hi,

if you are using such a configuration I would suggest to go with something like this:

https://thepihut.com/blogs/raspberry-pi-tutorials/17209332-adding-a-real-time-clock-to-your-raspberry-pi

That way you won’t have that Problem any more. Everything else I can think of is not reliable.

Bye

Gesendet von Mail für Windows 10

Von: dy1977--- via Unbound-users
Gesendet: Montag, 2. März 2020 07:59
An: unbound-users at nlnetlabs.nl
Betreff: resolution fails when the date of the server is more than 2 days late

Hello,

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 ?

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.

There is a ticket here about this question : 
https://github.com/RefugeeHotspot/RefugeeHotspot/issues/74

If the answer is not obvious, I will provide more details about unbound 
answers in this situation.

Thanks.

Dysmas



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20200302/f0bdb406/attachment.htm>


More information about the Unbound-users mailing list