About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Establish clock accuracy and uncertainty before making cross-machine timestamp or recovery-point decisions. DHCP lease durations need stable elapsed-time handling; they do not require client and server wall clocks to show the same time. A host that has just booted can pass every other test and still be hours off. Nothing in the login screen says so.
RFC 5905 defines NTP version 4, which synchronises clocks among distributed time servers and clients. Its purpose is to convey time from primary servers, themselves synchronised by wire or radio to national standards, through secondary servers, to clients, over private networks and the public Internet. Before current synchronisation is established, the host may rely on hardware time, saved clock discipline or another platform source; verify which source and accuracy are actually in use. The packet format has a way to say so. The leap-indicator value 3 means "unknown (clock unsynchronized)". A timestamp value of zero is a special case for unknown or unsynchronised time.
This article does not tell you how to configure a time daemon. It says where time sits in the order of a recovery, and which failures are actually clock failures.
Why it matters
NIST SP 800-34 Rev. 1 times a shared resource by the harm its absence does to everything else. Time is shared and almost invisible. Logs from disagreeing clocks need measured offsets and uncertainty before a reliable shared timeline can be inferred. A backup catalogue sorted by "newest" follows the clock of the system that wrote the label. A lease, a token or a certificate that is checked against the local clock will be treated as expired or as not yet valid, and the error will be reported as an authentication or a network fault.
DHCP already documents one of those faults. RFC 2131 says clients and servers may not have synchronised clocks, so DHCP represents times as relative times interpreted against the client's local clock. The lease algorithm assumes the two clocks are stable relative to each other. If they drift, the server may consider the lease expired before the client does. The server may hand out a shorter lease than the one it stores, as compensation. Clock offset and clock drift are different. Two clocks can disagree by an hour yet measure a lease’s elapsed duration consistently. Drift means their rates differ; a wall-clock step may also affect an implementation’s timers, but that requires product-specific evidence. The RFC warning does not justify treating all unsynchronised hosts as having unsafe leases.
How it works
Where correct time is supposed to come from
RFC 5905 describes a hierarchy selected from time-server associations, which may include redundant peers. Primary servers are stratum one. Each level of secondary server takes a stratum number one greater than the level above it. As the stratum number increases, accuracy degrades, depending on the path and on how stable the system clock is. Errors, measured as synchronisation distance, grow roughly with the stratum and with the round-trip delay. The usual practice, the RFC says, is to organise the topology to avoid timing loops and to minimise that distance. NTP chooses the subnet with a variant of a shortest-path algorithm rooted on the primary servers, and it will reorganise when the timing network has failures, so as to produce the most accurate and reliable time it can.
That reorganisation is not permission for every recovered virtual machine to offer time to the others. A timing loop is what the RFC tells you to avoid. A set of hosts that have only each other, all of them free-running since boot, can agree and still be wrong. Agreement is not national time. The purpose statement is conveyance from primary servers that are themselves tied to national standards. Losing reachability to a primary does not instantly prove every clock is wrong or that every server has set leap indicator 3. Previously disciplined clocks may continue with growing uncertainty. Inspect the implementation’s selected source, last valid update, offset and error bounds; when it reports unsynchronised state, do not accept it as proof of current UTC accuracy.
The accuracy figures in the introduction are for a working system, and they should not be copied onto a cold start. The RFC says typical primary servers on modern machines are precise within a few tens of microseconds, and typical secondary servers and clients on fast LANs are within a few hundred microseconds, with poll intervals up to 1024 seconds. That is a statement about a disciplined clock on a fast network. It is not a statement that a host is correct 1024 seconds after its daemon starts, and it is not a statement about a wide-area path you just rebuilt. Our recommendation: withhold acceptance until the host reports an approved source, a valid synchronisation state, and offset and uncertainty within the application’s tolerance. A leap indicator other than 3 alone does not authenticate the source or prove accuracy. Do not use the microsecond figures as a recovery target you have measured. You have not.
What other protocols do with a wrong clock
DHCP's relative times are a deliberate defence against unsynchronised clocks, and the RFC still warns that drift breaks the assumption. The compensation it allows is a shorter lease advertised to the client than the server keeps internally. Our recommendation is to preserve and reconcile lease state, check the implementation’s handling of elapsed time and clock changes, and use the addressing design already approved for bootstrap infrastructure. Do not convert live hosts to static addresses merely because NTP is unavailable: that can create collisions. DHCP can itself provide the address and options needed to reach a time service, so requiring NTP first can create a circular dependency. The RFC's failure mode is specific: the server expires the lease first. The symptom is a second host receiving an address the first host still uses.
Anything else that compares an absolute timestamp to the local clock inherits the same class of fault. This article does not open a certificate or token specification, so it does not state their expiry rules. It does say: if a restored system starts rejecting credentials or presenting credentials that nobody will accept, and the rejection is about time, read the clock before you read the certificate store. Leap indicator 3, or a timestamp of zero, is the NTP way of saying the time is not known. A current log line stamped 2019 is evidence to investigate the host clock or log provenance; it is not the NTP protocol flag itself.
Sorting backups by timestamp has the same trap. The newest-looking label can reflect a clock error rather than the last consistent copy. Our recommendation: choose the recovery point from the catalogue's recorded backup identity and from the business recovery-point objective, which NIST defines as a point in time you chose, not from whichever file stamp looks latest on two machines that have not been synchronised.
Where time sits in the order
Our recommendation:
- Before you trust cross-machine evidence, bring up a time source that is itself synchronised to a primary, or is a primary. A single internal server that was set by hand to "about now" is a better interim than a loop of recovered guests, and it is still not the RFC's model. Label it as interim. Do not let it become the permanent root because the recovery ran long.
- Use the approved time topology and avoid loops. Redundant associations and intentionally configured peers are valid; an ad hoc ring of free-running hosts is not proof of UTC accuracy. The role of a host alone does not determine whether it can serve time safely.
- Validate lease state and elapsed-time behaviour alongside time recovery. DHCP does not require equal wall clocks. Investigate abnormal drift, clock-step handling and stale lease records before reallocation; do not stop normal lease service merely because wall-clock offsets differ.
- Synchronise a host before you believe its logs or its "newest file" stamps, if those logs will be merged with anybody else's or used to pick a backup. A host can do useful local work on a wrong clock. Its logs can still contribute if offsets and uncertainty are preserved and accounted for; later synchronisation does not repair old timestamps.
- Re-check after the time step. Setting a clock that was hours off is an event. Jobs that were waiting for a time, and leases that were mid-way, need another look. The RFC's poll interval figures describe a settled system. A step change is not a settled system. Our recommendation: one named person confirms the source and the offset after the step, and writes it down, before the estate treats time as done.
The monitoring path has the same dependency. A sample stored with the timestamp at which it was recorded is only comparable with another machine's sample if those clocks meant the same thing. Bring time up with the first live collector, not after a week of graphs you cannot line up.
What to choose and why
These are our recommendations.
| Situation | Reasonable choice |
|---|---|
| Hosts have booted and no time source is reachable | Preserve logs with clock uncertainty, validate lease-state handling, and avoid file timestamps as the sole recovery-point evidence |
| A server answers NTP with leap indicator 3 | It is telling you it is unsynchronised. Do not follow it |
| Only the recovered guests can see each other | Avoid ad hoc timing loops; assess holdover uncertainty and restore access to an approved source |
| DHCP and the clients have been stepped by different amounts | Check how each implementation handles elapsed lease time after a step; unequal wall clocks alone do not establish expiry disagreement |
| You need an interim clock | One labelled source, set deliberately, clients pointed at it, replaced by a synchronised source as soon as you have one |
| Logs will be used for the incident timeline | Synchronise first, or record each host's offset next to its log so a reader can correct it |
| Two backup copies disagree about which is newer | Use the catalogue and the recovery-point decision, not the clocks that stamped the files |
Risks and limits
- The microsecond figures are the RFC's "typical" numbers for working servers on fast LANs. They are not a cold-start guarantee and not a result from this estate. Poll intervals up to 1024 seconds are part of that same typical description.
- Leap indicator 3 means unsynchronised. It does not, by itself, correct the clock. A client that ignores it is outside what this article can see. The article's gate is that you do not treat the time as known while the indicator says it is not.
- DHCP uses relative time because wall clocks may differ. Rate drift can still affect expiry; offset alone is not drift. No product-specific timer behaviour was tested.
- Timestamp zero means unknown or unsynchronised. The RFC also says era 0 of the NTP timestamp runs until some time in 2036, when the field wraps. That wrap is a separate future problem. It is not what makes a recovered host show the wrong year today.
- No time daemon was configured, and no lease was issued. Certificate and token expiry rules were not opened. If a product rejects a credential for a time reason, confirm that product's current documentation. Do not invent the rule from this article.
- NIST does not describe NTP. It is cited for the dependency principle and for the recovery point being a chosen point in time, not a file stamp.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No article commands or recovery operations were executed. This is educational source research, not a lab-validated production procedure.
Sources
Independently reopened 13 November 2026.
- RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification, June 2010: text. Purpose, stratum, timing loops, leap indicator value 3, timestamp zero, typical accuracy.
- RFC 2131, Dynamic Host Configuration Protocol, March 1997: text. Section 3.3, relative times and clock drift between client and server.
- NIST SP 800-34 Rev. 1, May 2010: PDF. Recovery time as impact on other resources. Recovery point as a chosen point in time.
This article was originally published on .