Consider adding 'After=time-sync.target' to systemd service unit files

[kpfleming]

• Program: Authoritative, Recursor, dnsdist
• Issue type: Feature request

Short description

Ensure that the system's clock is synchronized before starting PowerDNS services.

Usecase

Allow PowerDNS services to operate correctly on machines where the hardware clock is faulty (or non-existent). Failure to have a proper real-time clock on the machine can result in hard-to-diagnose DNS failures when DNSSEC is in use.

Description

See https://www.freedesktop.org/software/systemd/man/systemd.special.html#time-sync.target for a description of this target.

Adding 'After=time-sync.target' to the service unit files will not have any immediate effect, unless the system administrator has also enabled some sort of service which has a 'Before' dependency on that target; there are none of those services in a default configuration. systemd itself adds such an 'After' dependency to all timer units with OnCalendar settings, and to some other units.

However, in a system which makes use of systemd-timesyncd, the admin can enable systemd-time-wait-sync.service, which has such a dependency. The result would be that none of the PowerDNS services on the system would be started until after systemd-timesyncd is certain that the system's clock is synchronized with some external source.

A similar configuration can be achieved on systems which use ntpd, chronyd, or other time synchronization tools.

[rgacogne]

Does that work if the time synchronization service needs DNS resolution, like if it is using one of the ntp.org pools for example?

[mnordhoff]

For Auth, it seems best to start immediately if live DNSSEC is not in use. But that's too tricky to try implementing.

(There's also SOA-EDIT, but that's less critical...)

Since dnsdist doesn't implement DNSSEC signing or validation, maybe it should be excluded from this feature request?

[omoerbeek]

For rec: that's my worry too. With extended errors we do have the reason for DNSSEC validation failures. We could log the time related ones more prominently to hint to admins that the time is likely wrong?

[mnordhoff]

Tackling this from another direction, Auth/Rec could detect significant time jumps and flush most of their caches.

But if your Auth was serving invalid RRSIGs, and other servers have already seen them, you have a problem you can't fix unilaterally.

[omoerbeek]

Off topic: we managed to solve the DNSSEC validation with RTC is wrong bootstrap issue on OpenBSD but it required careful handling in openntpd, which falls back to CD=1 queries if it suspects a time related validation issues and then goes back to CD=0 queries once it is synced.

[kpfleming]

Does that work if the time synchronization service needs DNS resolution, like if it is using one of the ntp.org pools for example?

No, it will be a problem in that case. If time sync on the system is dependent on DNS resolution, and the resolution happens on the machine (or even DNSSEC validation happens on the machine), then the admin should not enable any service which triggers 'time-sync.target'. Of course if the DNS names required for time sync are located in a DNSSEC-signed zone, or resolving them requires use of DoH/DOT, then there's a more serious problem if the machine doesn't have a reliable RTC.

If we had a 'time sync on machines running PowerDNS' best practices guide, we could address this there :)

Since dnsdist doesn't implement DNSSEC signing or validation, maybe it should be excluded from this feature request?

If it is configured to make any TLS 'client' requests (DoT, DoH, {future} DoQ), then having time sync is still important, although the window for validity is probably larger than with DNSSEC signatures since server certs don't change as often.

Please keep in mind that adding this dependency is necessary, but not sufficient, to actually delay the service startup until time sync has been achieved. The admin also has to enable some service which has a 'Before' dependency on time-sync.target.

[omoerbeek]

We would welcome a PR for this.