Domain Registrar or DNS Provider Outage: Expired Domain Redemption Grace Period, DNSSEC SERVFAIL Trap, and Emergency Nameserver Migration¶

Waking up to discover that your company's primary website, API endpoints (api.example.com), and corporate email (MX records for Google Workspace or Microsoft 365) are completely unreachable across the globe (DNS_PROBE_FINISHED_NXDOMAIN or SERVFAIL) is a total-blackout infrastructure crisis. Unlike a single crashed web server that affects one service, a Domain Name System (DNS) or domain registration failure severs every single service under your root domain simultaneously, including Single Sign-On (SSO), customer support portals, and incoming incident-response emails. In practice, global domain blackouts stem from three distinct triggers: (1) an accidental domain expiration where a credit card on file expired and the registrar hijacked your NS records to point to a pay-per-click parking page 24 to 48 hours before the actual expiration date; (2) a DDoS attack or control-plane outage at your authoritative DNS provider (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); or (3) a broken DNSSEC (DS record) chain of trust during a hurried nameserver switch that causes validating resolvers (8.8.8.8, 1.1.1.1, ISP resolvers) to drop 100 percent of your traffic with SERVFAIL. If an attacker compromised your registrar login credentials and transferred or altered your domain maliciously, switch to domain name hijacking, expired DNS, and website takeover; if your TLS certificate expired or broke after DNS recovered, see SSL/TLS certificate expired in production, HSTS preload lockout, and emergency renewal and Google Workspace or Microsoft 365 custom domain admin lockout and DNS verification. If this outage disables hospital clinical communications, 911/112 emergency dispatch routing, or critical public utilities, call your local emergency number (911 in the United States and Canada, 112 across the European Union, 999 in the United Kingdom) or consult our directory of emergency numbers.

Do this now¶

1. Diagnose in 10 seconds whether the failure is an Expired/Suspended Domain (EPP Status), an Authoritative DNS Provider Outage, or a DNSSEC Validation Failure:
2. Run whois yourdomain.com | grep -iE "Status|Expiry|Name Server" and dig +trace yourdomain.com.
3. Test whether bypassing DNSSEC validation (+cd = Checking Disabled) makes your domain resolve again:

   dig @8.8.8.8 yourdomain.com A
   dig @8.8.8.8 yourdomain.com A +cd
   

   If the first command returns status: SERVFAIL while the second command (+cd) immediately returns status: NOERROR with your server's IP address, your DNS servers are NOT down: your DNSSEC (DS record at the registrar) is broken. Jump immediately to Phase 3 to delete the stale DS record at your registrar.
4. If your domain expired (Auto-Renew Grace Period or Redemption Grace Period), log into your current registrar immediately and pay the renewal/redemption fee; DO NOT wait for the domain to "drop" so you can re-register it cheaply:
5. During the first 1 to 45 days after expiration (Auto-Renew Grace Period), renewing in your registrar dashboard restores your original nameservers at standard renewal cost ($10 to $30).
6. During the 30-day Redemption Grace Period (RGP / redemptionPeriod), you must pay the mandatory registry redemption fee ($80 to $250) through your current registrar. If you wait for the domain to finish the 5-day Pending Delete phase to save $100, automated drop-catching sniper bots (DropCatch, SnapNames, NameJet) will snatch your domain within 5 milliseconds of release and auction it off for thousands of dollars.
7. NEVER change your Nameservers (NS) away from a DNSSEC-enabled DNS provider (like Cloudflare, Route 53, or Google Cloud DNS) without removing the DS record at your registrar first: If DNSSEC is enabled and you swap your NS records to a rescue DNS provider during an outage without deleting the parent DS (Delegation Signer) record in the .com / .org TLD zone first, every validating resolver on Earth will reject the new DNS provider's unsigned responses as a cryptographic spoofing attack (SERVFAIL).
8. If you are locked out of your corporate @yourdomain.com email because your domain's MX records are down, do NOT click "Send password reset code to admin@yourdomain.com" at your registrar: While your domain's NS or MX records are offline, any verification email sent to @yourdomain.com bounces or vanishes into a queue. Use your registrar's SMS/Authenticator MFA, out-of-band backup email (@gmail.com / @proton.me), or phone identity verification flow.
9. After renewing an expired domain, manually verify that your Registrar restored your original Custom Nameservers (NS) instead of leaving the domain on sedoparking.com / renewyourname.net: When a domain expires, registrars overwrite your custom NS records with parking nameservers (ns1.parklogic.com, dns1.name-services.com). Sometimes paying the renewal updates the expiration date to next year while leaving the parking nameservers active until you manually switch them back.
10. Flush global public recursive DNS caches (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) the second your NS or DS records are restored: Instead of waiting 24 to 48 hours for cached NXDOMAIN or parking-page NS records to expire naturally, trigger an instant global cache purge at Google Public DNS (developers.google.com/speed/public-dns/cache) and Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Decision tree: global domain or DNS blackout emergency triage¶

Use this flowchart to pinpoint the exact layer of the DNS hierarchy (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, or Authoritative Nameserver) where resolution is failing:

flowchart TD
    Start["Global Outage: Domain Web & Email Failing to Resolve (NXDOMAIN / SERVFAIL)"] --> RunDiag["Run: whois domain.com AND dig @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Does dig @8.8.8.8 domain.com Fail, While Adding +cd Succeeds?"}

    CheckCD -->|"Yes: Works with +cd, Fails Without +cd"| DnssecBreak["Broken DNSSEC Chain of Trust: Delete Stale DS Record at Registrar OR Re-Sign Zone -> Flush 8.8.8.8 & 1.1.1.1"]

    CheckCD -->|"No: Both Fail or Return Parking IP"| CheckWhois{"Inspect WHOIS EPP Domain Status & Expiry Date"}

    CheckWhois -->|"Status: clientHold or serverHold"| HoldState["Registrar / Registry Suspension: Complete ICANN RAA Email Verification OR Abuse/Billing Ticket Immediately"]

    CheckWhois -->|"Expiry Date Passed (Status: autoRenewPeriod)"| GraceRenew["Day 1 to 45 Post-Expiry: Pay Standard Renewal in Registrar Portal -> Verify Custom NS Restored"]

    CheckWhois -->|"Status: redemptionPeriod (RGP)"| RgpRestore["Day 45 to 75 Post-Expiry: Open Urgent Registrar Support Ticket / Pay RGP Restore Fee ($80-$250) Immediately"]

    CheckWhois -->|"Status: pendingDelete"| PendingDel["Final 5-Day Lock: Cannot Be Renewed at Registrar -> Place Backorders Across All Major Drop-Catchers Now"]

    CheckWhois -->|"Status: ok / clientTransferProhibited AND Expiry in Future"| AuthDown["Domain Registration Healthy -> Authoritative DNS Provider Outage or Missing Zone"]

    AuthDown --> MigrateNS["Import Zone File (`BIND` / Terraform) to Secondary DNS Provider -> Remove DS Record if DNSSEC On -> Update NS at Registrar"]

Phase 1: The ICANN Domain Expiration Lifecycle (Auto-Renew vs. Redemption vs. Pending Delete)¶

When a generic Top-Level Domain (gTLD such as .com, .net, .org, .io, .ai, .co, .app, .dev) expires because an auto-renew credit card failed or a finance card was canceled after an employee left, the domain passes through a strict multi-stage lifecycle governed by ICANN's Expired Registration Recovery Policy (ERRP) and registry operator agreements (Verisign for .com/.net, PIR for .org, Identity Digital).

How a domain dies and why it goes offline BEFORE or ON Day 1 of expiration¶

+-------------------------------------------------------------------------+
| ICANN gTLD EXPIRATION TIMELINE (.com / .net / .org example)             |
|                                                                         |
| [Active Domain]                                                         |
|       |                                                                 |
|       v  (Expiration Date Reached: Day 0)                               |
| +---------------------------------------------------------------------+ |
| | STAGE 1: Auto-Renew Grace Period (Day 1 to Day 30-45)               | |
| | - EPP Status: ok or clientHold (Registrar swaps your NS to parking) | |
| | - Production Impact: 100% OFFLINE within 0 to 48 hours of expiry    | |
| | - Recovery: Log into registrar & pay normal renewal ($10-$30).      | |
| +---------------------------------------------------------------------+ |
|       |  (Registrar sends Delete command to Registry at Day 30-45)      |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 2: Redemption Grace Period [RGP] (Exactly 30 Calendar Days)   | |
| | - EPP Status: redemptionPeriod (Domain removed from TLD Root Zone)  | |
| | - Recovery: Still 100% guaranteed to original owner, MUST pay       | |
| |   Registry RGP Redemption Fee ($80-$250) + renewal via registrar.   | |
| +---------------------------------------------------------------------+ |
|       |  (30-Day RGP expires without redemption payment)                |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 3: Pending Delete (Exactly 5 Calendar Days)                   | |
| | - EPP Status: pendingDelete                                         | |
| | - Recovery: IMPOSSIBLE to renew or redeem at any price. Registry    | |
| |   rejects all registrar commands until public drop at Day 5 (~18:00 | |
| |   UTC for Verisign .com/.net).                                      | |
| +---------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+

Compare your exact rights, costs, and recovery actions across every stage of expiration, including country-code Top-Level Domains (ccTLDs like .uk, .de, .eu, .ca, .au), which do not follow ICANN gTLD rules:

Phase 2: Step-by-step recovery of an expired or RedemptionPeriod domain¶

Follow this exact sequence to bring an expired domain back online in the shortest possible time:

Step 1: Regain access to your Registrar Account when @yourdomain.com email is dead¶

Here is the classic Catch-22 of an expired domain: - Your domain (company.com) expired, so MX records for company.com stopped resolving. - You try to log into your domain registrar (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), and the registrar says: "We sent a 6-digit verification code to admin@company.com." - Because company.com is expired, that email can never arrive.

How to break out of the expired-domain email loop immediately: 1. Do NOT transfer or modify anything yet: check if you can spin up a temporary emergency mail catcher ONLY if the domain is not expired (if the domain itself is expired at the TLD level, MX cannot resolve anywhere until renewed). 2. Use the Registrar's "Lost Email Access / Domain Expired" Account Recovery Channel: - Almost all ICANN-accredited registrars provide a dedicated phone or government-ID / corporate-incorporation-document verification workflow specifically for customers whose login email sits @ the expired domain inside the account. - Have three items ready before calling registrar support: (a) the last 4 digits of the credit card or PayPal transaction ID used on the previous renewal invoice, (b) your Registrar Account ID / Customer PIN, and © a government photo ID + Articles of Incorporation / utility bill matching the WHOIS Registrant Organization (Tech / Admin / Registrant). 3. Once logged in, immediately change your Registrar Account email address to an external domain (@gmail.com, @proton.me, or a separate emergency domain you own) and enable Hardware Security Key (FIDO2) or TOTP Authenticator App MFA so login never depends on @company.com email again.

Step 2: Execute the Renewal or RedemptionPeriod (RGP) Restore¶

1. If the domain is in Stage 1 (Auto-Renew Grace Period, Days 1 to 30/45):
2. Go to Billing -> Renewals or Domain List -> Expired Filter and pay the renewal invoice.
3. Critical Check 60 seconds after paying: Open the domain's Nameservers (NS) settings in the registrar dashboard. Check whether the registrar automatically put back your real nameservers (for example, ns-123.awsdns-15.com or ada.ns.cloudflare.com) or left the domain pointing to its expired-parking servers (ns1.sedoparking.com / dns1.registrar-servers.com). If parking servers are still listed, manually re-enter your production nameservers and save.
4. If the domain is in Stage 2 (Redemption Grace Period / redemptionPeriod, Days 30/45 to 75):
5. Look in a separate tab inside your registrar dashboard often labeled Expired Domains -> Redemption, Trash / Restore, or Grace/Redemption Billing.
6. Pay the RGP Restore fee + 1-year renewal.
7. How does RGP restoration work at the Registry (Verisign / PIR)? When you pay the RGP fee, your registrar sends an EPP <update><restore op="request"> command to the TLD Registry. The Registry immediately changes the domain status from redemptionPeriod to pendingRestore and puts your domain's NS records back into the TLD Root Zone within 15 to 60 minutes while your registrar submits the restore op="report" compliance confirmation.

Step 3: Bypass local ISP cache delays by purging 8.8.8.8 and 1.1.1.1¶

When your domain was expired, recursive DNS resolvers around the world cached the parking nameservers or the negative NXDOMAIN response (governed by the TLD's SOA Minimum TTL, typically 900 to 3,600 seconds, or 86,400 seconds for NS records). The moment dig @a.gtld-servers.net yourdomain.com NS (querying the .com root server directly) shows your real production nameservers again: 1. Open Google Public DNS Flush Cache (https://developers.google.com/speed/public-dns/cache): - Flush type NS first for yourdomain.com, then flush SOA, A, AAAA, MX, and TXT. 2. Open Cloudflare 1.1.1.1 Purge Cache (https://one.one.one.one/purge-cache/): - Purge NS, A, AAAA, and MX for yourdomain.com.

Phase 3: Emergency Nameserver (NS) Migration During a DNS Provider Outage (And the DNSSEC Trap)¶

What if your domain registration is 100 percent valid and unexpired, but your Authoritative DNS Provider (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn) is suffering a catastrophic outage or DDoS attack, and you need to migrate your domain's Nameservers (NS) to a backup DNS provider right now?

The #1 Migration Killer: Switching NS While DNSSEC (DS Record) Is Enabled¶

Before changing a single NS record at your registrar, run this command to check if DNSSEC is enabled on your domain at the parent TLD registry:

dig +short yourdomain.com DS @8.8.8.8

+-------------------------------------------------------------------------+
| WHY CHANGING NS RECORDS WITH AN ACTIVE DS RECORD BREAKS THE INTERNET    |
|                                                                         |
| 1. Parent TLD (.com) holds your old DNS provider's DS Record (Key #2371)|
| 2. Old DNS Provider goes down. You import zone to New DNS Provider      |
|    (unsigned, or signed with a brand-new Key #9910) and swap NS.        |
| 3. Validating Resolver (8.8.8.8 / 1.1.1.1 / Comcast / ISP) queries      |
|    New DNS Provider, sees signature does NOT match DS Key #2371.        |
| 4. Resolver assumes an active MITM Spoofing Attack -> Returns SERVFAIL  |
| 5. RESULT: Your domain stays 100% dead worldwide even though the new    |
|    DNS servers are up and answering cleanly.                            |
+-------------------------------------------------------------------------+

Safe Emergency Nameserver Migration Checklist (Zero SERVFAIL Procedure)¶

1. Reconstruct or import your complete DNS Zone File at the new DNS provider first:
2. Never guess your DNS records from memory (@, www, and api are rarely the only records; forgetting MX, SPF/TXT, DKIM, _dmarc, autodiscover, or CAA breaks email delivery and TLS renewals).
3. Where to find your full DNS zone when your primary DNS provider's dashboard is down:
   • Check Infrastructure-as-Code (Terraform, Pulumi, OctoDNS, DNSControl) in your Git repository.
   • Check recent zone exports (BIND .zone files) or search historical DNS databases (SecurityTrails, ViewDNS.info, DNSDumpster, or Censys / crt.sh for subdomains).
   • Query cached records still sitting inside public recursive resolvers (dig @8.8.8.8 yourdomain.com MX, dig @1.1.1.1 yourdomain.com TXT, dig @9.9.9.9 api.yourdomain.com A) before their TTLs expire.
4. Verify the new DNS provider is answering authoritatively for every critical record BEFORE touching your registrar: Suppose your new provider assigned you ns1.rescuedns.com and ns2.rescuedns.com. Test them directly with dig:

   dig @ns1.rescuedns.com yourdomain.com SOA +norecurse
   dig @ns1.rescuedns.com yourdomain.com A +norecurse
   dig @ns1.rescuedns.com yourdomain.com MX +norecurse
   

   Wait until the flags: line in the dig header explicitly includes aa (Authoritative Answer) and returns status: NOERROR.
5. If dig +short yourdomain.com DS returned a DS record, handle DNSSEC at the registrar:
6. During an active outage where the old DNS provider is completely unreachable: Log into your Domain Registrar (where you bought the domain), go to the DNSSEC / DS Records section, and delete all DS records so the domain reverts to unsigned (Insecure) mode at the TLD parent zone. Wait until dig +short yourdomain.com DS @a.gtld-servers.net returns empty (and flush DS in 8.8.8.8 / 1.1.1.1), or add the new DNS provider's DS record alongside the old one if doing a planned multi-signer migration.
7. Update the Nameservers (NS) at your Domain Registrar: Replace the dead nameservers with ns1.rescuedns.com and ns2.rescuedns.com in your registrar's Custom Nameservers panel (note: changing NS records inside the zone editor does nothing when the old servers are dead; you must change the Glue / Parent Delegation Nameservers at the Registrar level).
8. Purge NS and DS caches on Google (8.8.8.8) and Cloudflare (1.1.1.1): Use the public cache purge tools from Phase 2 Step 3 to force immediate adoption of the new nameservers.

Phase 4: Surviving the 60-Day ICANN Registrar Transfer Lock during an emergency¶

What if you need to transfer your domain to a new registrar (ICANN Inter-Registrar Transfer), only to get blocked by Domain Status: clientTransferProhibited and a message saying: "This domain is under a 60-day ICANN Transfer Lock because contact information was recently updated"?

1. Why the 60-day lock triggered: Under the ICANN Transfer Policy (Section II.C.1), registrars place a 60-day transfer lock whenever a domain is newly registered, transferred between registrars, or undergoes a "Change of Registrant" (updating the First Name, Last Name, Organization Name, or Email Address of the Registrant contact).
2. How to bypass or opt out of the Change-of-Registrant 60-day lock:
3. Before editing WHOIS contact details: Almost all major registrars provide a checkbox right on the contact edit screen labeled: "Opt out of the 60-day transfer lock after this contact update." Checking that box allows you to update your admin/registrant email address and still generate an EPP Auth-Code (Transfer Secret) to transfer the domain the very same day.
4. Remember that you do NOT need to transfer the domain registration to change DNS providers: Even if a domain is locked for 60 days against Registrar Transfers (clientTransferProhibited), you can still change its Nameservers (NS records) at the current registrar at any time with zero waiting period; switching DNS takes minutes, whereas a full registrar transfer takes up to 5 to 7 days unless the losing registrar clicks an instant Approve Outgoing Transfer (FOa) button.

Phase 5: Hardening domain registrations and DNS against future outages¶

Once your domain and DNS resolution are 100 percent restored, complete this resilience checklist:

• Enable Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) on mission-critical production domains: Standard Registrar Lock (clientTransferProhibited) can be toggled off with a single click if an attacker hijacks your registrar login. Registry Lock (offered by Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi, and Porkbun/Namecheap for enterprise domains) locks the domain directly at the TLD Registry level, requiring out-of-band multi-person voice/cryptographic verification before any NS record can be changed or the domain deleted.
• Renew production domains for 5 to 10 years in advance (ICANN maximum horizon is 10 years): Never leave a business-critical domain on year-to-year renewal where a single expired corporate credit card can trigger an expiration outage. Pre-pay 5 to 10 years at once.
• Never use an @yourdomain.com email address as the login or billing notification contact at the registrar managing yourdomain.com: Use a dedicated security distribution list on an independent administrative domain or hardened external account, and monitor RDAP / WHOIS expiration dates via automated external Prometheus/Uptime monitors (domain_expiry_days < 60).
• Lower NS and DS TTLs (300 to 3600 seconds) 48 hours before any planned DNS migration: Lowering TTLs in advance ensures resolvers switch over within 5 minutes of a planned cutover.

Regional emergency numbers and agency protocols¶

When a domain or DNS outage impacts healthcare facilities, emergency services, municipal utilities, or government infrastructure, follow these regional escalation channels:

• United States and Canada: Dial 911 if a domain/DNS outage disables clinical hospital telemetry, ambulance dispatch, or life-safety systems. Report DDoS attacks on DNS infrastructure or BGP/DNS hijacking to CISA (1-844-Say-CISA / cisa.gov/report), the FBI IC3 (ic3.gov), or the Canadian Centre for Cyber Security (1-833-CYBER-88). For .gov domains, contact the CISA .gov Registrar Helpdesk.
• United Kingdom: Dial 999 for threats to life or acute NHS disruptions. Report critical DNS outages or domain hijacks to the NCSC (ncsc.gov.uk), and contact Nominet (01865 332244) directly for urgent .uk / .gov.uk / .nhs.uk registry issues.
• European Union: Dial 112 across all EU member states. DNS service providers and TLD name registries are regulated under the EU NIS2 Directive (Directive 2022/2555) and must report significant availability incidents to their national CSIRT within 24 hours.
• Australia and New Zealand: Dial 000 in Australia or 111 in New Zealand; report critical DNS or domain incidents to the ACSC (1300 CYBER1), auDA (for .au), or Domain Name Commission NZ (for .nz).
• India and Asia-Pacific: Dial 112 in India for emergency response; report DNS/domain infrastructure attacks to CERT-In (incident@cert-in.org.in) within 6 hours or NIXI for .in registry escalations.

Frequently asked questions¶

Why did my domain stop working 24 hours BEFORE its official WHOIS expiration timestamp?¶

First, check timezones: WHOIS `Registry Expiry Date` is always printed in **UTC (`Z`)**, which is 4 to 8 hours ahead of North American timezones (meaning a domain expiring at `2026-11-01T04:00:00Z` actually expires at `8:00 PM PDT` on October 31). Second, if your `NS` records had a `24-hour` or `48-hour` TTL and the registrar swapped them at `00:00 UTC` on expiry day, users whose resolvers refreshed early hit the parking page immediately while others stay cached for hours.

My registrar is completely out of business or unresponsive (Dead / De-accredited Registrar), and my domain is expiring. How do I rescue it?¶

When ICANN terminates or de-accredits a failing registrar under the **De-Accredited Registrar Transition Procedure (`DARTP`)**, ICANN automatically bulk-transfers all domains to a gaining custodian registrar at zero cost to registrants. Check `whois yourdomain.com` (or `lookup.icann.org`) to see which **Registrar** and **IANA ID** currently holds your domain, or file an urgent **Domain Renewal / Transfer Complaint** directly with **ICANN Contractual Compliance (`icann.org/compliance/complaint`)**.

Why is my website working for some customers on cellular data, but still showing the expired parking page on our office Wi-Fi 6 hours after I renewed the domain?¶

Your office network or local ISP recursive DNS resolver cached the registrar's parking-page `NS` and `A` records while the domain was expired, and parking nameservers notoriously set high TTLs (`3,600` to `86,400` seconds / 24 hours) so ad pages stay cached longer. Flush Google (`8.8.8.8`) and Cloudflare (`1.1.1.1`) using their web purge tools, then on your local computer run `ipconfig /flushdns` (Windows), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS), or `sudo resolvectl flush-caches` (Linux).

What Happens to Emails Sent to @yourdomain.com While Our Domain or DNS Was Expired for 18 Hours? Are They Lost Forever?¶

In most cases, legitimate emails sent during the first 12 to 48 hours of a DNS outage are NOT lost: they are queued on the sender's mail server and will arrive automatically over the next few hours. Under **`RFC 5321` (Simple Mail Transfer Protocol, Section 4.5.4.1)**, when a sending mail server (`Gmail`, `Microsoft Exchange Online`, `Postfix`) gets a temporary DNS lookup failure (`SERVFAIL`) or cannot connect to an `MX` host, it places the message in a retry queue for **4 to 5 days (`96 to 120 hours`)**, retrying with exponential backoff. However, if the registrar's expired parking page included a **wildcard null `MX` record (`0 .`)** or a parking mail server that rejected mail with a hard `550 5.1.1 User Unknown` permanent bounce, those senders received an immediate bounce notification and must re-send their emails.

Can I set up two DNS providers at the same time (Cloudflare + Route 53) simply by listing two Cloudflare NS records and two Route 53 NS records at my registrar?¶

Yes, as long as `DNSSEC` is disabled (or properly configured with `RFC 8901` Multi-Signer DNSSEC) and both providers serve identical DNS records. Recursive resolvers query all listed parent `NS` records using round-robin/RTT latency selection (`SRTT`). If you list `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, and `ns2.providerB.com` in your registrar's Custom Nameservers and keep both zones synchronized using **OctoDNS**, **DNSControl**, **Terraform**, or `AXFR / IXFR` zone transfers, your domain automatically survives a 100 percent outage of either DNS provider.

What is the difference between clientHold and serverHold in WHOIS?¶

EPP status codes starting with **`client...`** (`clientHold`, `clientTransferProhibited`) are set by your **Domain Registrar** (the retailer where you manage your account, such as Namecheap or GoDaddy) and can be removed immediately by your registrar's support or billing system. Status codes starting with **`server...`** (`serverHold`, `serverTransferProhibited`) are set directly by the **TLD Registry Operator** (`Verisign`, `PIR`, `Nominet`) due to court orders, UDRP disputes, registry-level abuse suspensions, or hardware **Registry Lock**, and require contacting the Registry through your registrar to lift.

Related guides¶

• Domain name hijacking, expired DNS, and website takeover
• SSL/TLS certificate expired in production, HSTS preload lockout, CA CAA record block, and emergency renewal
• Google Workspace or Microsoft 365 custom domain admin lockout, DNS TXT verification, and tenant rescue
• DNS hijacking, ISP router WAN reconfiguration, and captive portal spoofing
• Web hosting crisis, migration, and backup restoration
• Emergency numbers by country

Sources and official guidance¶

• Internet Corporation for Assigned Names and Numbers (ICANN): Expired Registration Recovery Policy (ERRP), Expired Domain Deletion Policy (EDDP), Inter-Registrar Transfer Policy (60-Day Change-of-Registrant Lock), and EPP Status Codes Reference (clientHold, redemptionPeriod, pendingDelete).
• Internet Engineering Task Force (IETF): RFC 6781 (DNSSEC Operational Practices: Key Rollovers and Emergency DS Removal) & RFC 8901 (Multi-Signer DNSSEC Models for Multi-Provider Authoritative DNS).
• National Institute of Standards and Technology (NIST) (United States): Special Publication 800-81-2: Secure Domain Name System (DNS) Deployment Guide.
• Cybersecurity and Infrastructure Security Agency (CISA) (United States): Emergency Directive 19-01: Mitigating DNS Infrastructure Tampering.
• European Union Agency for Cybersecurity (ENISA): NIS2 Technical Guidance for DNS Service Providers and TLD Name Registries.