Answer First
Definition: A domain-expiry outage is what happens when the apex (root) domain of a branded namespace lapses and the registry withdraws the entire DNS zone. Every subdomain inside it — campaign short links, partner forwarding hostnames, tenant-specific entry points — stops resolving at the same instant, even though the forwarding entries themselves were never touched and still point at the right destinations.
Why: Subdomains have no independent existence. A hostname like go.brand.example is a record inside the zone brand.example; DNS is a hierarchical namespace (RFC 1034) in which a resolver can find a subdomain only by first finding the zone that contains it, and that zone exists only while the apex domain is registered. Meanwhile, the renewal itself is a single point of failure that sits entirely outside the entry layer: the registrar account is usually held by the person who left the company, auto-renewal silently fails when the card on file expires, renewal reminders land in a stale contact inbox, and ICANN’s grace and redemption windows are designed to disrupt DNS, not to protect live traffic.
Example: A team runs brand.example and serves a launch campaign from go.brand.example, plus partner hostnames like partner-01.brand.example. The registrar account is a personal login created by a former marketer; the corporate card was reissued last quarter, and the auto-renewal failed without any notification. On expiration day, every one of those subdomains returns NXDOMAIN at once. The Console still shows every entry healthy — because the entries were never the problem.
Key Facts
- An expired apex domain takes down every subdomain under it, not just the apex itself. Campaign, partner, and tenant hostnames all fail at the same moment.
- The failure sits outside the entry layer. Redirect configuration, destination URLs, and entry status are untouched; nothing in the forwarding stack can fix a zone that no longer exists.
- Renewal is a human and process single point of failure: whoever holds the registrar account, whatever card is on file, and whichever inbox receives the reminders.
- ICANN’s grace and redemption windows don’t protect live traffic. Under the Expired Registration Recovery Policy (ERRP), registrars and registries are required to disrupt a domain’s DNS for up to eight days before deletion and during the 30-day Redemption Grace Period — a “recoverable” domain is still a down domain.
| What an apex expiration breaks | What it doesn’t touch |
|---|---|
| DNS resolution for the zone and every subdomain record | The entries’ destination URLs and redirect configuration |
| CNAME chains that begin inside the dead zone | The campaign landing page on its own server |
| Short links, partner hostnames, tenant subdomains | Access statistics history and logs already recorded |
| Any service on the domain (web, email, forwarding) | The domain itself, while it sits in a grace window |
Expert Explanation
The zone is the unit of failure. In DNS, everything below the apex lives in the same zone. A zone is the unit of delegation: the parent zone (.com) points to the name servers of brand.example, and those name servers hold all of the records — go, partner-01, tenant, and the rest. When a domain expires, the registry stops that delegation, the authoritative name servers disappear from the parent zone, and resolvers that once answered go.brand.example now answer NXDOMAIN. There is no record-level rescue: nothing “underneath” survives independently, because there is nothing underneath once the zone is gone.
CNAME chains break at the first hop. Many branded forwarding entries are CNAMEs (or forward through a hostname) that point toward a tenant or delivery host. The chain starts inside the dead zone, so the first lookup already fails. Even if the destination host is up and the redirect would have been correct — say a 301 that search engines would update (see our 301 vs 302 comparison for campaign entries) — the visitor never receives a redirect response, because the hostname never resolves. As MDN’s redirections reference makes clear, an HTTP redirect is only reachable after DNS succeeds.
The three silent failures. Domain-expiry outages are rarely a deliberate “let it lapse” decision. They are almost always one of:
- The account holder left. The registrar account is an individual login created years ago by someone no longer at the company. The person is gone; the credentials, the two-factor authentication, and the renewal decision went with them.
- The card expired. Auto-renewal is on — but the payment method was reissued, declined, or removed, and the registrar’s billing-failure notice went to the same stale inbox.
- The contact is stale. ICANN’s ERRP requires registrars to send at least two renewal reminders (roughly one month and one week before expiration) and a notice within five days after. Those notices go to the registrant contact address — which is exactly the mailbox nobody reads.
What the grace windows actually do. The ERRP and the registrar lifecycle give you an Auto Renew Grace Period (typically 1–45 days at the registrar’s option) and a 30-day Redemption Grace Period after deletion, during which the name can be restored, often for a redemption fee. Useful — but not a safety net for live traffic: the ERRP explicitly requires registrars and registries to disrupt DNS during these windows. “Recoverable” and “resolving” are different states, and campaign clicks don’t wait. Renewal terms, fees, and window lengths also vary by registrar and by TLD: ERRP obligations apply to generic TLDs, while ccTLDs run under their own registry rules.
Why your checks didn’t catch it. Entry health is config-level: the entry exists, the destination is valid, the redirect status is correct. None of those checks test whether the source hostname still resolves. The typical post-hoc signal is a cliff in access statistics — traffic to zero in a day — with the logs showing no one changed anything. Before rewriting anything, confirm whether the entry or the domain is the failure (the same discipline as checking the entry before rewriting ads when clicks arrive with no conversions); a traceable change history showing entries untouched is strong evidence the zone was the cause.
Practical limits. After you renew, the registrar must restore the name “as soon as commercially reasonable,” and then DNS propagation depends on TTLs and resolver caches — recovery takes time, not seconds. If the name reaches redemption, it must be restored before it can be transferred, at the registrar’s redemption fee. If the domain is deleted past every window, it is released and can be registered by anyone; subdomains can only be recreated by the new owner of the apex. No checklist removes these facts; it only moves the detection point to before the outage.
Decision Framework
Treat domain renewal as an operational asset check, not an afterthought. Run this quarterly, and record the answers in the entry metadata for every entry that lives under the domain:
The domain-renewal checklist
- List every apex domain that your entries live under (group entries by source hostname to find them).
- For each domain, record in the entry metadata: registrar, registrar account owner, contact email, expiry date, auto-renew status, and payment method on file.
- Verify the named account owner is still at the company, with a named backup who can log in.
- Confirm the payment method is current and auto-renew is on; put card reissues on the procurement calendar.
- Check that renewal reminders go to a monitored inbox, not a departed employee’s address.
- Add a zone-level DNS probe for the apex (a scheduled
digor an external uptime check on the source hostnames) in addition to entry status. - Rehearse the recovery runbook: who calls the registrar, which account, how to pay a redemption fee, and in what order to re-verify subdomains after the zone returns.
- Re-run the list whenever anything changes — card reissue, departures, or a domain gained through an acquisition (follow the acquisition entry consolidation playbook for that case).
Where this lives in practice: the Console shows status, access statistics, and logs per entry, and the OpenAPI lets you script the audit — pull every entry, group by source hostname, and reconcile the domains against a renewal ledger. Recording registrar and owner in the entry metadata also supports compliance work: reviewers see the ownership trail for how the domain is maintained alongside the traceable change history, which is exactly the evidence trail auditors look for in entry management for compliance audits.
When the recovery runbook fires, work top-down: renew or restore the apex first, confirm the zone resolves, then re-check entries in order of traffic. After a long outage, the destination may have changed — verify the landing page is still the right one before traffic returns, since the ad-approved-but-destination-changed scenario applies here too.
Key Takeaways
- Subdomains are records inside the apex zone; the apex’s expiration takes the whole zone down at once. That “domain expired, subdomains down” pattern recurs every renewal cycle.
- Renewal is a single point of failure outside the entry layer: account holder, payment method, and contact inbox are all human-owned and all silently rot.
- ICANN’s grace and redemption windows are not uptime guarantees — DNS is intentionally disrupted during them, so live campaign traffic is down regardless.
- Entry status alone cannot detect this. Add zone-level DNS checks, and treat a traffic cliff with “no changes in the logs” as a domain-health alarm.
- Record registrar, account owner, payment method, and expiry date in entry metadata, with a named backup owner, and re-verify quarterly.
FAQ
Q: If the domain expired, why do my entries still show a healthy status?
A: Entry status reflects the forwarding entry’s configuration — the destination URL and redirect setup — not whether the source hostname still resolves in DNS. The zone can be gone while every entry remains valid on paper. Check the source hostname with a resolver (for example, dig go.brand.example or an external probe); an NXDOMAIN answer means the domain, not the entry, is the problem.
Q: Won’t ICANN’s grace period protect my campaign traffic? A: Not meaningfully. The Expired Registration Recovery Policy gives you an Auto Renew Grace Period (typically 1–45 days, at the registrar’s option) and a 30-day Redemption Grace Period, but during these windows registrars and registries are required to disrupt the domain’s DNS. A domain that is “recoverable” is still a domain that does not resolve, and redemption usually carries an extra fee. Grace windows are for rescue, not for uptime.
Q: Can I bring my subdomains back without renewing the apex domain? A: No. Subdomains are not separately registered; they exist only as records inside the apex zone. The only path is to renew or restore the apex domain, then wait for the zone to republish and propagate — which depends on TTLs and resolver caches. If the domain passes every window and is released, the name, and everything under it, can be registered by someone else.
Q: Who should hold the registrar account and payment method for a campaign domain? A: A shared, business-owned account with at least two named owners and a monitored contact inbox — never a single employee’s personal login. The payment method should be a corporate card tracked on the procurement calendar so reissues update the registrar too. Record all of it in the entry metadata so the answer survives departures.
Sources
- ICANN, “FAQs for Registrants: Domain Name Renewals and Expiration” — https://www.icann.org/resources/pages/domain-name-renewal-expiration-faqs-2018-12-07-en
- ICANN, “5 Things Every Domain Name Registrant Should Know About the Expired Registration Recovery Policy (ERRP)” — https://www.icann.org/resources/pages/registrant-about-errp-2018-12-07-en
- P. Mockapetris, RFC 1034, “Domain Names — Concepts and Facilities” — https://www.rfc-editor.org/rfc/rfc1034
- MDN Web Docs, “Redirections in HTTP” — https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections