DNSSEC validating resolver on machines without RTC or wrong date

[Petr Menšík]

Oh great, I were not aware there is something similar. I would like to 
avoid the need for a restart. dnsmasq has similar special knob, but I 
were not aware unbound has something like it too.

I have tested it even on older unbound, it is possible to manipulate 
this properly via unbound-control set_option "val-override-date: -1"

And indeed, if I set the clock to wrong value and flush org zone, it 
fails until I call above unbound-control command. It is a bit concerning 
in that case it still has ad bit, even though it were not full 
validated. And I expect no other indication to client hints not full 
validation were done. But yes, starting with val-override-date: -1 in 
configuration and setting "val-override-date: 0" with cache flush once 
time is set initially after boot would be the best solution I can find.

The cache flush could be avoided if it were possible to flush just 
records, which do not pass only time checks. Since we have already done 
crypto validation, we have already the most CPU intensive work done. 
Better to not waste it by full cache flush again.

On 17. 04. 23 16:45, Daisuke HIGASHI wrote:
>
>   Run Unbound in "val-override-date: -1" mode at very short term after 
> boot, and once your machine gets good datetime[1], restart Unbound in 
> normal mode.
>
>   In this mode, Unbound performs DNSSEC validation without RRSIG 
> expiration check. The only risk you must take here is the possibility 
> of accepting expired signatures.
>
> [1] The next problem is to get datetime by secure method. Your company 
> should run DNS server publishing datetime in signed zone like:
> time.redhat.com <http://time.redhat.com>.  IN TXT "1687842121"

No, I really do not think we should make methods alternative to NTP in 
the DNS itself. Besides fetching such name still requires valid time to 
check com. zone (redhat.com is not signed at the moment).

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20230420/0a323394/attachment.htm>