Expiry time is the SOA timing value that tells a secondary DNS server when to stop serving a zone if it cannot refresh from the primary server. After that limit, the cached zone data is treated as stale and should no longer be used for authoritative answers.
What expiry time means in DNS
Expiry time is not a generic cache timeout, it is the zone transfer safety limit in DNS secondary-server operations. It defines how long a secondary may continue serving a zone when refreshes from the primary stop arriving.
That makes expiry time a correctness control as much as a timing value. As long as refreshes succeed, the secondary stays aligned with the primary; once the limit is reached, the zone data is considered stale and should no longer be trusted for authoritative answers.
How expiry time affects authoritative DNS service
Expiry time sits inside the SOA record logic that governs zone freshness. In normal operation, secondaries use the refresh and retry values to keep synchronised, but expiry is the final boundary that prevents indefinite use of old data if the primary is unreachable or misconfigured.
This matters because secondary DNS servers are often deployed for resilience and distribution. If expiry is too short, a temporary upstream outage can cause avoidable service loss. If it is too long, stale records may continue to answer queries after the zone should have been retired or corrected.
In practice, expiry time helps balance availability and integrity. The value should be set with the expected update cadence, network reliability, and the organisation's tolerance for serving stale authoritative data in mind.
What can go wrong when expiry is mis-set
Expiry time is most visible when the primary server becomes unavailable, an update path breaks, or a secondary cannot refresh its zone file. At that point the remaining question is not whether the data is cached, but whether it is still acceptable to serve as authoritative.
Long expiry periods can mask failures for longer than operators expect, which can delay detection of broken replication, stale DNS records, or ownership changes that should have taken effect. Short expiry periods can turn a transient outage into an outright name resolution failure for resolvers that still depend on the secondary.
Because DNS is a trust layer for many other services, stale authority can have downstream effects on routing, email delivery, service discovery, and incident response. The risk is not only availability, but also users or systems being directed by outdated zone content.
How teams check and manage expiry time safely
Expiry time should be reviewed alongside the full SOA timer set, not in isolation. Teams should confirm that the expiry window matches their operational reality, including how often records change, how quickly secondaries usually refresh, and how long a primary outage can last before stale data becomes unacceptable.
It is also important to verify that the zone can actually refresh from the primary under normal conditions. A well-chosen expiry value does not compensate for broken transfers, blocked ports, or inconsistent zone distribution, so operators should validate the refresh path and monitor for secondaries approaching expiry.
Where possible, treat expiry as part of broader DNS resilience design. That includes clear ownership of zone updates, monitoring for stale secondary data, and documented procedures for what to do when a zone is nearing expiry and the primary has not recovered.
Risk and Threat Considerations
Expiry time creates a clear failure boundary in DNS authority. If refreshes fail and the expiry window is too generous, secondaries can keep serving records that no longer reflect the current zone state; if it is too aggressive, a brief outage can remove authoritative service entirely.
Failure mechanism: A secondary server loses contact with the primary, exhausts its refresh attempts, and then either serves stale data until expiry or stops answering authoritatively when the limit is reached.
Impact: The organisation can face stale name resolution, delayed propagation of DNS changes, service disruption, or incorrect routing that persists long enough to affect users and dependent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-20 — Secure Name / Address Resolution Service (Authoritative Source of Zone Data) | DNS expiry governs how long secondary servers may rely on zone data for authoritative answers. |
| CM-2 — Baseline Configuration | SOA timing values are configuration data that shape authoritative DNS behaviour and resilience. | |
| Recommendation — Validate authoritative DNS freshness windows and alert on secondaries nearing stale-zone expiry. Baseline SOA timer settings and review them when DNS operating conditions change. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Zone data served authoritatively must remain current and controlled to avoid stale disclosure or misuse. |
| Recommendation — Protect zone data integrity by ensuring secondaries stop serving expired authoritative records. | ||
Practitioner Guidance
What to watch for: Review expiry alongside refresh and retry settings whenever zone ownership, update frequency, or resilience requirements change. The right value depends on how quickly stale data becomes operationally harmful, not on a generic default.
Governance implication: Treat expiry as an owned DNS control with monitoring and escalation attached, because it defines when stale authoritative data must be considered invalid. Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle thinking applies cleanly to zone freshness and controlled retirement of old state.
Related resources from NHI Mgmt Group
- Guide: Guide to NHI Rotation Challenges
- How should security teams handle time-based logic in token expiry and session controls?
- What breaks when AI access control is still bound to token expiry instead of real-time signals?
- What happens when just-in-time access is used without strong approval and expiry controls?
- What is Just-in-Time (JIT) access and why is it important for NHI security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org