DNSSEC validating resolver on machines without RTC or wrong date

[Petr Menšík]

Hi unbound users,

I maintain unbound on Fedora and RHEL. I met some question on some 
Fedora channel about problems with NTP service. It turned out the 
problem of that user lied were in DNSSEC validating resolver and wrong 
time on his machine. Like significantly wrong date, which made DNSSEC 
validation fail because some timestamp on RRSIG did not fail.

I would like to have DNSSEC validation on a machine good default choice. 
Or at least possible. I consider it a problem that this wrong date will 
*not* fix automatically in otherwise default configuration.

Like many other systems, Fedora tries to use chrony service to use NTP 
to synchronize and correct the time. Problem is unless the user has 
configured fixed IP or NTP servers were provided by DHCP, it needs to do 
DNS resolution. Fedora uses 2.fedora.pool.ntp.org. ntp.org is not 
signed, but org. has to pass validation. It will never success if the 
date is wrong and the cache is already up, therefore the system relies 
on it.

I think it is a technical problem there is dependency loop. DNSSEC needs 
at least roughly correct time in for unbound (or any validating 
resolver) to deliver IP for NTP server. It would fix the system time, 
fixing the validation failures. But until someone fixes the system time 
to pass root and org. domains validation, it cannot contact configured 
ntp service to obtain current time.

I would like to ask opinions how this should be fixed to autocorrect 
auto-magically. I am aware unbound is more usually used on servers, 
which should keep time synced on boot and are not powered off for 
extended time. But I think it is a good choice also for workstations.

* should initial NTP service request names with CD flag set, requesting 
any validation ignored for its queries? The problem I see those services 
use getaddrinfo() calls, which do not offer a way to set CD flags only 
for some request. It seems to me DNS-only resolution library should not 
be required in time synchronization service

* should system resolver always disable DNSSEC validation on early start 
and enable it only after initial time synchronization passed? I think it 
makes it possible by insecure domain . defined on start. Then when time 
is successfully obtained, it can switch validation on by 
"unbound-control insecure_remove ." command. I think it would be risky, 
because initial cache should be revalidated on such switch and bogus 
answers should be flushed. Not sure it is possible with current code.

* possible workaround would be time synchronization service having fixed 
IP address instead of name. It might save last used addresses on 
shutdown and use it in case initial name query failed. That might work 
on raspberry-pi like devices, but does not solve the first boot after 
the installation. That should be good compromise between fixed address.

I think even if we choose to use DNS over TLS without DNSSEC, the 
problem with initial wrong time stays on its certificate check. Is there 
a way to fix it in that case?

Do you have other ideas how should DNSSEC validation fixed on end 
workstations? How it should obtain time in secure way and not dropping 
validation entirely? Is there already a best practice for it? Should 
unbound support mode where it would check just signatures, but not 
timestamps?

Please share any comments you may have, thank you.

Best Regards,
Petr

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB