Refresh, Retry & Expire in DNS: How SOA Timing Actually Works

📝 Introduction

DNS was designed under the assumption that a primary server and its secondaries wouldn't always be able to talk to each other reliably — networks fail, servers go down for maintenance, connectivity hiccups happen. Rather than pretending that never occurs, the SOA record builds explicit tolerance for it directly into the protocol through three timing fields, each answering a slightly different question about how patient a secondary should be.

🔍 Defining Each Field Precisely

Refresh is how often, under normal healthy conditions, a secondary checks the primary's current serial. Retry is the shorter interval a secondary falls back to specifically after a refresh check fails, letting it recover from a brief hiccup faster than waiting for the next full refresh cycle. Expire is the outer limit — if a secondary genuinely can't reach the primary for longer than this, it stops serving the zone authoritatively at all, treating its data as too stale to trust.

🔄 How the Three Values Relate to Each Other

The intended relationship is refresh > retry, and expire >> refresh — a secondary should recheck routinely, retry quickly after hiccups, and only give up after a genuinely extended, unusual outage, not a routine blip.

⚙️ Technical Walkthrough: A Failure Scenario

⚙️ Typical Provider Defaults

Common industry-standard defaults look roughly like a refresh of 1–2 hours, a retry of 15–30 minutes, and an expire of 1–2 weeks — values chosen to comfortably absorb routine maintenance windows and even fairly serious extended outages without a secondary prematurely dropping the zone, while still keeping normal propagation reasonably prompt.

🎯 Tuning Guidance by Use Case

🏢 Hosting & Cloud Examples

Traditional shared-hosting DNS panels frequently leave these three values at whatever the underlying software's install defaults were, sometimes for years, without anyone revisiting them. Cloud DNS platforms generally choose more deliberately tuned defaults reflecting their own large-scale operational experience — a reasonable starting point for most users, though still worth reviewing rather than assuming is universally correct for every workload.

🏢 Enterprise Reliability Scenarios

Organizations running geographically distributed secondary infrastructure sometimes deliberately extend expire values well beyond typical defaults specifically to tolerate extended regional network partitions without any secondary dropping authoritative service — a conservative choice that trades a slightly longer worst-case staleness window for meaningfully improved resilience during genuine large-scale connectivity incidents.

🔄 Migration Considerations

During a DNS provider migration, these three values reset to whatever the new provider's defaults are — there's no meaningful reason to try to preserve the old provider's specific numbers unless your organization has a documented, deliberate reason those particular values were chosen in the first place.

🔒 Security Angle

An unusually short expire value paired with genuinely unreliable primary infrastructure creates a realistic scenario where a coordinated denial-of-service against the primary could push secondaries into expiring the zone faster than a more conservatively configured setup would allow — worth factoring into expire decisions for any zone with real availability requirements.

⏱️ Performance Tradeoffs

Shorter refresh intervals mean more frequent primary-to-secondary check traffic and marginally faster propagation of legitimate changes; longer intervals reduce overhead at the cost of a wider window where a secondary could theoretically be serving slightly stale data. For the overwhelming majority of zones, this tradeoff is barely noticeable in practice — it mostly matters for very high-change-frequency or very large-scale zones where the aggregate query volume becomes operationally significant.

📊 Comparison & Decision Tables

Refresh vs. Retry vs. Expire, Side by Side

Expire vs. TTL

✅ Best-Practice Checklist

• Keep retry meaningfully shorter than refresh
• Set expire generously enough to absorb a realistic extended outage
• Review provider defaults rather than assuming they suit every workload
• Adjust refresh based on actual zone change frequency, not guesswork
• Document any deliberate deviation from defaults for future reference

❌ Common Mistakes

🔧 Troubleshooting

🎓 Expert Tips

💼 Daily Practical Use Cases

Network engineers tune these values during initial zone setup for organizations with specific availability requirements. Site reliability teams reference expire specifically when modeling worst-case DNS behavior during extended incident response planning. Hosting providers set sensible platform-wide defaults that most customers never need to touch.

🔬 Advanced Insights

Some modern DNS architectures using near-real-time internal replication (rather than classic scheduled AXFR/IXFR polling) still publish standards-compliant refresh, retry, and expire values for compatibility, even though their actual internal propagation may be effectively instantaneous — meaning the published SOA timing values function more as a compatibility contract for any external tooling than as a literal description of internal replication behavior. Understanding this distinction matters when interpreting SOA values on modern managed platforms versus classic self-hosted BIND deployments, where the values are much more literally descriptive of real polling behavior.

📋 Related Tools & Guides Comparison

🔗 More Guides