Bug 787399

In my opinion this is more generic than DNSSEC issue.

When your machine has incorrect time then everything secure, like DNSSEC and https/imaps (outdated certificates) won't work correctly. I think default assumption is that every system has correct time and if doesn't, administrator must adjust service's configurations.

Since DNSSEC is widely deployed, I'm not going to disable validation because it would be step backward. I also don't want to introduce dependency on ntp because some administrators don't want to use it. If production server has roughly accurate time (+- 1 hour), DNSSEC works correctly.

Closing as notabug.

<< When your machine has incorrect time then everything secure, like DNSSEC and
https/imaps (outdated certificates) won't work correctly. I think default
assumption is that every system has correct time >>

Problem is that even on systems that had ntp installed to make sure the time is correct, we noticed this problem.
Likely because NTP depends on DNS to lookup pool.ntp.org...

That makes the consequences a little more serious than in your https/imaps example.

Problem also occurs with VPS servers.

When a VPS is started, the system time on startup will always be that of the host system, which may have a different time zone configuration than the VPS, and therefore may be several hours off.

The time is then normally synchronized through ntpdate, except that will not work without a functioning DNS.

You are right, this more serious than my https example. However the only way how to solve this chicken-and-egg problem is to disable DNSSEC. Unfortunately this change is step backward from my point of view so please either disable DNSSEC yourself or keep time on your machine accurate (+- 1 hour, which is definitely possible with current hardware + software).

Note about time zones. DNSSEC knows nothing about time zones and it works only with UTC time. So if UTC time is correct on your virtual server then change of time zone has no effect on DNSSEC validation because UTC time is still same.

<< So if UTC time is correct on your virtual server >>

And there is the problem.
In a VPS environment it is usually not possible to SAVE the time to the hardware clock, like you can do on a real system.

Instead on each and every boot it retrieves the system time from the host system as initial time setting.
Some hypervisor software provides the initial system time as UTC in which case there is no problem, but some others provide the time in the local time zone of the host system because certain other operating systems like Windows expect that.


So on system startup the virtual machine retrieves the time from the virtual hardware clock provided by the host system.
Which may have the time in say EST if the VPS was provided by an American cloud provider.
But the VPS itself may have a different timezone configured, e.g. CET because it belongs to an European customer.


<< However the only way how to solve this chicken-and-egg problem is to disable DNSSEC. >>

Or at least temporarily during system startup.
A startup scripts that runs at boot before ntp with a configuration file without dnssec, and a second startup script that runs afterwards and loads the real configuration file.