use monotonic time

changed the description

added minor and removed bug labels

The only thing I'm unsure of is TTL handling in cache. This MR changes it from "real time" to a hybrid of real and monotonic time.

As I find it impossible to have it always follow purely monotonic time, I would slightly lean to keep it purely on "real time", just as DNSSEC. One reason for that is that we currently do not re-check the DNSSEC stamp when loading data from cache, only relying on the cache stamp. But still, I can't see way to avoid all bad influence of (significantly) skewed real time on DNSSEC, so it only makes a difference in cases that are bad already...

Personally I like the hybrid approach because it prevents weird stuff from happening when admin moves time for some reason. Example: Image that "real time" on the machine is one hour ahead and causing issues with particular domain. Admin will fix this problem by moving time "back" so real time is now okay. Side-effect of this change would be that all cached records will stay in cache for +1 hour, and this might break some other stuff.

On daemon restart we could detect this and flush cache if (real time now < real time recorded in cache).

What do you think?

Flushing cache is certainly a good precaution whenever we do detect a larger time shift (a couple minutes, perhaps). What remains is how to detect it.

I wonder what the monotonic clock syscalls actually return, and whether it's system-wide consistent until reboot (e.g. number of seconds since boot).

Well, if we didn't care about cache persistence being consistent wrt. time shifts, we could simply use the monotonic timestamps for all TTL computations.

If I remember correctly @vkriz wanted to store real time somewhere and use monotonic clock during lifetime of process. This would allow us to detect that time was rewound back before the time when process was started, which is likely insufficient resolution...

I feel that it is getting way too complicated and we might revert to real time for cache+DNSSEC and use monotonic time for everything else.

During runtime it's easy: store a pair of real and monotonic time taken at once, and periodically check if their difference is roughly the same.

Across system reboots it's probably impossible, on the other hand.

Yes, we are out of luck accross system reboots. As a result, it would make impossibe to persist cache across reboots, which is certainly undesirable.

We can certainly have both, without much complexity: detection of time change without restarting kresd/system (depending on how monotonic time behaves) and persistent cache that might get bad TTLs across those restarts.

Let's do this:

keep using real time for cache stamps, so that it simply works across reboots if the time doesn't skew;
detect (significant) time skew during kresd runtime, and clear cache whenever it happens.

Detection: https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/392#note_61756 – it's not perfect, as we might theoretically get preempted between syscalls for a longer time interval, but with some tolerance of a few seconds I expect that to be reliable enough. We might get more advanced and e.g. do a "sandwich" of three syscalls to detect the long-term preemption: monotonic, real, monotonic + check that the two monotonic don't differ much.

Doing this mix, we should explicitly annotate the meaning of struct kr_query::timestamp and maybe have both times cached in there, too...