Answer First
Definition: A “domain expired links broken” outage is what happens when a root domain (the apex) lapses and stops resolving, taking every subdomain beneath it down at the same time — including every branded campaign link you manage as a forwarding entry. The entries, redirects, and landing pages are intact; what’s gone is the registered domain whose DNS zone holds their records.
Why: DNS is hierarchical. A campaign URL such as spring25.brand.example resolves only because brand.example is registered and live, with an authoritative zone containing spring25. When the apex expires, that zone disappears and lookups for every subdomain under it fail together. The apex is a single point of failure for your whole entry portfolio — one layer above anything an entry-management tool can see.
Example: Your team runs forty campaign subdomains under launch.example, each a forwarding entry. Auto-renew was switched off during a registrar migration, the stored payment card was replaced, and renewal notices went to an inbox nobody reads. On expiration day the registrar suspends the zone and all forty links break at once — while every entry status check still reports healthy.
Key Facts
- The apex is a single point of failure: one expiry takes down every campaign subdomain under it at the same moment.
- Dashboards, logs, and status checks stay green because the entries never changed — the failure is a layer above them.
- No entry edit, redirect change, or status check can repair the outage; only renewing or restoring the apex does.
- Renewals fail quietly: auto-renew off, expired payment method, lost registrar access, renewal emails in a dead inbox.
- Recovery is a race: grace period, then redemption, then release — windows and fees vary by TLD and registrar.
- “The link worked yesterday” is the tell-tale symptom; DNS caching (TTL) masks the cutover.
- The fix mirrors how you treat entries: give the apex an explicit owner, a renewal calendar, and a pre-mortem checklist.
Expert Explanation
The failure chain: apex → zone → every subdomain
The domain name system is a hierarchy: each name is a path through a tree — spring25.brand.example is a label under brand.example, itself under example. Records that make spring25 resolve live in the zone for brand.example. When the apex lapses and its zone disappears, no parent zone remains and lookups for every child name fail simultaneously. Nobody plans for this chain, because every tool in the stack manages leaves, not the root.
Why “the link worked yesterday” is the tell
The tell is that nothing changed: links that worked yesterday fail today, the Console shows healthy status, the landing page and ad are fine. Two DNS mechanics confuse the diagnosis. First, resolvers and browsers cache answers for a record’s TTL, so some users keep working for hours after the zone stops resolving — the outage looks gradual. Second, the same caching delays recovery after renewal. The pattern is a staggered death of links that share one prefix — the moment to suspect the parent domain rather than the entry (the same way you’d check the entry before rewriting ads when clicks don’t convert).
The quiet ways renewals fail
Root domains rarely expire on purpose; renewal is a background process nobody owns:
- Auto-renew toggled off during a registrar migration, never switched back on.
- The stored payment method expired or was replaced, and the charge silently failed.
- Registrar emails land in an inbox nobody monitors — a shared mailbox, a former employee’s account, or spam.
- Registrar account access is lost — no MFA recovery, stale admin contact — so nobody sees the notices.
Each is mundane; together they produce an outage every monitoring tool confirms is “not our problem.”
The timeline race
After expiry, the exact sequence and windows depend on the TLD’s registry and the registrar’s policy — treat every number as typical:
| Phase | What happens | Typical window |
|---|---|---|
| Auto-renew attempt | Registrar tries the stored payment; notices go to the account contact | Around the expiration date |
| Renewal grace period | Domain often still resolvable; renewal usually possible at the regular price | ~30 days (varies) |
| Redemption period | Zone suspended or parked; restore usually possible with a restore fee | ~30 days (varies) |
| Deletion / release | Registration drops; anyone can register the name | After redemption ends |
After the grace window, cost and difficulty rise daily; after deletion, anyone can re-register the name — campaign subdomains included.
Why no entry-management tool can fix this
This is the product-relevant lesson. Redirects are HTTP responses a browser only receives after resolving the host; if the host can’t resolve, no 301 or 302 configuration matters — the 301 vs 302 choice only matters once the link is reachable. Status checks and change history describe entries, and every entry is exactly as you left it. PushULink’s Console and OpenAPI give teams status, access statistics, logs, and traceable changes for each forwarding entry — but the apex is not an entry; the failure lives in the registrar account and the registration itself.
Practical limits
Timeline figures are typical ranges for common gTLDs, not guarantees; registries and registrars set their own windows and ccTLDs differ. This diagnosis covers apex expiry; other single points exist at the same layer — registrar lockout, DNSSEC misconfiguration — but the fix below applies to all of them.
Decision Framework
You can’t eliminate the apex as a dependency, but you can decide who and what protects it.
1. Who owns the apex? Assign an explicit owner and a backup for every registered domain that hosts entries — the same discipline you apply to entries, where ownership and traceable changes matter. Unowned apex, unowned renewal.
2. What lives on the renewal calendar? The expiration date, auto-renew status, valid payment method, registrar contact email, and the grace and redemption deadlines — with reminders before each deadline, not after.
3. One registrar or many? Consolidating domains with one registrar reduces the renewal surfaces, payment methods, and inboxes to keep alive. If domains stay spread across registrars — common after acquisitions, when inherited subdomains arrive with their own registrations — keep a per-registrar calendar.
4. What does the recovery runbook say? Decide in advance who restores the domain, from which account, with which payment method, and what the team says meanwhile.
Pre-mortem checklist
Run this before the next expiry, not during it:
- Every apex hosting entries has a named owner plus a backup.
- Auto-renew is enabled, and the payment method on file won’t expire before the renewal.
- Registrar account access is documented: login, MFA recovery, and a current admin contact.
- The registrar contact email is a monitored inbox, not a dead shared mailbox.
- Expiration, grace, and redemption deadlines are on the shared calendar with advance reminders.
- Domains with long-lived campaigns are registered for multiple years where the budget allows.
- You know the TTLs on the records your entries depend on, to estimate restore propagation.
- Pre-mortem answered: “If every campaign link died at once tomorrow, who checks the apex first, and how fast can they restore it?”
Key Takeaways
- A lapsed apex breaks every campaign subdomain under it at once — an outage no entry dashboard can show, because the entries are fine.
- The symptom is “the link worked yesterday”; DNS caching makes outages and recoveries both look gradual.
- Renewals fail through mundane, unowned background processes: auto-renew off, dead card, dead inbox, lost access.
- Recovery is a race through grace, redemption, and release; windows vary by TLD and registrar.
- No redirect fix, entry edit, or status check can repair it; only renewing the apex can.
- Prevent it like you prevent entry sprawl: an explicit apex owner, a renewal calendar, and a pre-mortem checklist.
FAQ
Q: What exactly is a “domain expired links broken” outage?
A: It’s when the root domain (the apex) lapses and stops resolving, so every subdomain under it — including every campaign entry — fails at the same time. The entries and landing pages are unchanged; the failure is one layer up, in the registration and its DNS zone.
Q: My links worked yesterday. Why did they all break at once?
A: Expiry is one event that hits every child name under the apex at once. DNS caching (TTL) confuses the picture: cached answers keep some users working for hours after the zone stops resolving, so the outage and the recovery both look gradual.
Q: Can I recover the domain after it expires, and how long do I have?
A: Usually, but the clock is real: renewal grace period, then redemption with a restore fee, then release, after which anyone can register the name. Windows and fees are set by each TLD’s registry and your registrar — read the dates in your registrar account.
Q: How do I stop this from happening again?
A: Give the apex the same treatment as your entries: a named owner and backup, a renewal calendar with expiration, grace, and redemption dates, a valid payment method, a monitored inbox, and a pre-mortem checklist every renewal cycle.
Sources
- RFC 1034 — Domain Names: Concepts and Facilities: the hierarchical DNS model in which every name lives inside its parent zone, so child names depend on the parent zone existing.
- MDN — DNS (Glossary): DNS as a hierarchical, decentralized naming system that maps names to resources through lookups.
- MDN — HTTP Redirections: redirects are HTTP responses, evaluated only after a host resolves — no redirect can help when DNS fails.
- MDN — TTL (Glossary): time-to-live caching, the mechanism behind “it worked yesterday” and gradual propagation.