DNSwebsitetechnical

Website Handover Playbook: DNS TTLs, Registrar Access, and Emergency Keyholders

iinherit

2026-01-30

11 min read

A technical playbook for buyers and executors: which DNS, registrar, and hosting credentials to secure, where to store them, and exact steps to survive outages and transfers.

Hook: If the person who knows your domain and hosting credentials is gone, your website can disappear in hours

Executors, buyers, and small business operators tell the same story in 2026: a founder dies or exits, and the business loses control of its domain, DNS, or hosting. Recent spikes in outages across major providers in early 2026 make this risk real and immediate. This playbook shows exactly which DNS, registrar, and hosting credentials to secure, how to store them, and the step-by-step actions an emergency keyholder should take to survive outages and transfers.

Why this matters now: 2025-2026 trends that change the game

Late 2025 and early 2026 brought a higher frequency of cloud and DNS disruptions and major provider policy changes that affect recovery paths. Outages at major DNS and CDN providers showed how a single-point failure can cascade. Provider changes to identity and email policies in 2025 mean relying on a personal Gmail address for registrar recovery is increasingly fragile — see related notes on identity controls and recovery. Legislatures and courts continued to clarify digital asset succession, and enterprise-grade tools for secure inheritance matured — but the technical and legal gaps remain.

What this playbook solves

Clear inventory of what to capture for DNS, registrar, hosting, and CMS access.
Actionable storage options that are auditable, secure, and legally useful.
Operational steps for an emergency keyholder during outages and transfers.
TTL and DNS strategies to minimize downtime during handovers.

Core inventory: exactly what credentials and records to secure

Start with one authoritative inventory. Every item below should be captured, timestamped, and stored in an auditable vault.

Domain and registrar

Registrar account login username and password or single-sign-on method and recovery methods.
Authenticated email used for registrar account and domain WHOIS and recovery (avoid personal free email where possible).
Authorization/EPP code or transfer code for each domain.
Registrar lock status and instructions to disable registrar lock or transfer lock.
Nameserver records and ownership of DNS hosting (registrar DNS versus third-party DNS like Cloudflare — see the Cloudflare/AWS postmortem for real-world examples).
Billing and invoice access to prove payment history for disputes.
Registry-level contacts and any premium domain agreements or legal encumbrances.

DNS and DNS hosting

DNS provider console access credentials (Cloudflare, AWS Route 53, NS1, etc).
Full zone export (BIND zone file or equivalent) and a plain-text copy of all critical records: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV.
Glue records if the domain is used for authoritative nameservers; instructions for updating glue at the registry.
TTL history and recommendations — current TTLs and suggestion for pre-transfer TTL changes.

Hosting, CDN, and infrastructure

Hosting control panel credentials (cPanel, Plesk, vendor console login).
Cloud console credentials and role-based access (AWS, Azure, Google Cloud) and the account owner contact — patch and update procedures for these consoles are critical and are discussed in resources like patch management guidance.
SSH keys and the location of their private keys, and which servers those keys access. Store and document key rotation and authorization patterns for service-to-service access.
Database credentials and an encrypted dump stored offsite.
CDN and WAF console access and fallback configuration steps — include rollback and redirect safety notes from modern redirect and layer-2 settlement guides where applicable.
Backups and snapshot locations including S3 buckets, offsite backups, and retention policies.

CMS, code, and third-party services

CMS admin accounts (WordPress, Shopify, headless CMS) with at least one organization-owned admin.
Code repository access (GitHub, GitLab) including details of organization versus personal accounts and deploy keys.
Payment processor and merchant account access (Stripe, PayPal).
Email delivery provider credentials (SendGrid, SES) and DKIM/DMARC keys.
SSL/TLS certificate management and private key storage or ACME account details.

Where to store credentials: secure, auditable, and legally defensible locations

Two requirements conflict: security and executor accessibility. Use a layered approach that gives executors safe access without weakening day-to-day security.

Primary vault: enterprise password manager with emergency access

Use an enterprise-grade password manager that supports emergency access or legacy contacts (for example, 1Password, Bitwarden enterprise, or a comparable provider).
Store all credentials, zone files, and recovery codes. Attach documentation and short SOPs for each credential.
Configure an emergency access policy that requires multi-party approval or time-delayed approval before granting access to an executor.

Secondary vault: legal escrow and notarized access

Store critical items like EPP codes, notarized instruction letters, and signed power-of-attorney in a legal escrow service or with the company attorney.
Escrow should include a checklist that matches the digital inventory and a chain-of-custody log.

Hardware keys and air-gapped copies

Keep at least one hardware security key (FIDO2 / YubiKey) and an encrypted backup of SSH private keys and certificate private keys in an air-gapped hardware wallet or encrypted USB stored with a trustee — hardware-backed keys are also covered in secure agent policy guidance like creating a secure desktop AI agent policy.
Record how to use those keys and the passphrase to unlock them in the notarized instructions.

Practical rules for storage

Never rely solely on personal email for registrar recovery; use an enterprise-managed email alias on your domain or an email controlled by the business entity.
Use multi-factor authentication and register at least two MFA methods where possible, including one hardware key.
Ensure all vault access and emergency release events are logged and auditable for legal review.

Emergency keyholder: who, how, and what they must be able to do

An emergency keyholder is a person or service authorized to act immediately to restore continuity. They should be trusted, technically competent, and have a legal mechanism to act.

Selection criteria

Technical competence with DNS, registrar procedures, and cloud console fundamentals.
Legal authority via will, power of attorney, or court appointment, or an escrow agreement that triggers on specific events.
Availability — able to act 24/7 for initial crisis steps.

Minimum skills and tools

Can change nameservers and update DNS records.
Can request EPP codes and initiate a domain transfer.
Can log into cloud consoles and enable or rotate IAM keys.
Understands TLS certificate issuance and renewal, and how to pull backups.

Legal setup for keyholders

Include specific powers in the will and in a separate digital assets rider that names digital assets, keyholders, and escrow instructions.
Use an access agreement with the emergency keyholder that defines triggers, scope, liabilities, and reimbursement for costs.

DNS TTLs and handover timing: the technical playbook

TTL strategy is the single most effective lever to minimize downtime during a transfer. Follow this timing playbook before planned transfers or when preparing for an emergency transfer.

Stage 0: 7+ days before planned handover

Export full DNS zone and verify backups.
Reduce critical TTLs (A, AAAA, CNAME, MX, TXT) from high values to 300 seconds (5 minutes) if you expect a switch in the next week. Note: short TTLs increase DNS query load and cost; plan accordingly.
Ensure at least two independent DNS providers are configured as secondaries if possible for resilience — consider multi-region and micro-region strategies for redundancy.

Stage 1: 24-48 hours before transfer

Confirm registrar EPP code availability and remove transfer locks if the transfer is authorized.
Confirm email recovery path for the registrar account and make sure recovery email is reachable by an executor or organization-controlled address.
Notify stakeholders and schedule maintenance windows for low-traffic hours.

Stage 2: Transfer day

Start transfer early in the maintenance window.
Monitor DNS propagation with multi-region checks and synthetic monitors — techniques used in edge-first production environments are helpful for global validation.
If nameservers change, expect up to the previous TTL delay; pre-lowering TTL reduces that window.

Stage 3: Post-transfer (0-72 hours)

Increase TTLs to a stable value after validating all services for 48-72 hours.
Rotate credentials and keys, reissue certificates if necessary, and update backup destinations — treat this like a patch/recovery cycle from patch management playbooks.
Document changes and confirm chain-of-custody in your vault.

Emergency playbook: first 0-24 hours for outages or sudden loss

When an outage or sudden loss occurs, an executor or buyer needs a concise checklist. This is the one to print and store with emergency documents.

0-1 hour: Triage

Confirm scope: is the outage provider-wide (Cloudflare/AWS) or limited to your domain/hosting?
Check provider status pages and outages. If a major provider outage is the cause, escalate to the provider and follow their interim guidance — read the postmortem on large provider outages for responder playbook ideas.
Retrieve the registrar login and EPP code from the vault. If the registrar account email is inaccessible, use legal escrow to prove authority.

1-6 hours: Restore accessibility

If DNS hosting is down and you control the registrar, change nameservers to a secondary DNS provider whose config you have stored, or point A records to a failover host.
Deploy the stored DNS zone file to the backup DNS provider, verify records, and set short TTLs for quick validation; techniques from offline-first edge strategies can speed failover in constrained environments.
If hosting is down, shift traffic to a static cached site using a CDN or to an offsite backup host where the snapshot was stored.

6-24 hours: Stabilize and document

Rotate keys and passwords used during the emergency. Ensure the final state is recorded and audited in the vault.
Notify users and customers about the incident, actions taken, and expected resolution timelines.
Trigger legal notifications if required by contracts or privacy laws.

CMS and code: make admin access transfer-proof

CMS access is often the weak link because it sits behind personal admin accounts. Harden these now.

Create an organization-owned admin account for each CMS with a strong password stored in the enterprise vault.
Remove or minimize the use of personal emails as primary admin contacts.
Store deploy keys and CI/CD secrets in the vault and consider using ephemeral tokens with expirations for deploy pipelines.
Keep automated daily backups and offsite copies of the CMS database and assets, and test restores quarterly.

Long-term governance: policies and regular audits

Security and succession aren’t one-off tasks. Build policies and run quarterly checks.

Quarterly audit of the inventory and vault entries; verify access assignments and update executor contacts.
Annual tabletop exercises simulating an outage and a transfer event with the emergency keyholder and legal counsel.
Maintain an updated digital assets rider to the will that lists domains, DNS provider, registrar, and hosting providers, and references the stored inventory location.

Templates and checklists (copy and use)

Minimal domain handover checklist

Registrar name and account login
Registrar recovery email and phone
EPP/transfer code
Nameservers and DNS host
Zone file export attached
Billing account ID and invoices

Emergency contact template for executor

Name of emergency keyholder
Phone and circadian availability
Location of vault and legal escrow
Signed authority document reference

Rule of thumb: If a credential can destroy or redirect your business traffic, it belongs in the vault and in the legal instructions.

Case studies and quick examples

Case 1: Rapid failover saved a storefront after Cloudflare outage

A midsize e-commerce business experienced a Cloudflare outage in January 2026 that affected their DNS and edge caching. Because they had a secondary DNS provider and a prepared zone file in their enterprise vault, the emergency keyholder rotated nameservers to the secondary within 45 minutes and restored core site availability with a static storefront while the CDN recovered. The incident caused minimal revenue loss and proved the value of multi-provider DNS strategies.

Case 2: Registrar recovery blocked by personal email policy change

A startup lost access after Google's identity policy changes impacted account recovery. The business had used a founder's personal Gmail on the registrar account. Because the registrar required email validation and the email changed due to Google's account migration rules, the transfer stalled. The solution required legal letters, escrow release, and a longer-than-expected transfer. The root cause: relying on a personal email rather than an organization-controlled email.

Advanced strategies and future-proofing (2026 and beyond)

As identity platforms evolve and regulations around digital inheritance grow, advanced measures help reduce friction.

Use organization-managed identity providers for registrar and cloud logins instead of personal OAuth providers whenever possible.
Adopt hardware-backed multi-signature controls for critical keys (for example, multi-sig HSM workflows for certificate issuance or cloud root actions).
Consider a dedicated digital asset fiduciary service that combines legal escrow, secure key custody, and operational runbooks.
Track regulatory changes in digital asset succession and update the digital assets rider annually with your counsel.

Actionable takeaways

Build an authoritative inventory now and store it in an enterprise vault with emergency access configured.
Stop using personal email for registrar and cloud recovery; create organization-managed email accounts.
Lower TTLs before any planned transfer and run a failover test with a secondary DNS provider.
Name and legally authorize an emergency keyholder, and run quarterly tabletop exercises with them.
Keep notarized instructions and an escrow copy of critical secrets like EPP codes and notarized access letters.

Closing: Start the one-hour check you can complete today

Take one hour now: export your DNS zone, identify the registrar login, and store both in your enterprise password manager with an emergency access contact. That one hour can prevent days of downtime, legal expense, and lost revenue if an outage or a succession event occurs.

Executors and buyers: if you need a tailored handover worksheet or a consultant to run a tabletop exercise, contact a specialist who understands registrar law, DNS operations, and secure custody. Don’t let a single credential become a single point of failure.

Call to action

Download the ready-to-use domain handover checklist and emergency vault template, or schedule a 30-minute consultation to build your customizable succession playbook. Secure your website continuity today.

inherit

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.