DNS Handover Without Surprises: Who Controls the Domain, DNSSEC, and Mail?
A practical handover audit for registrar access, nameservers, DNSSEC, CAA, mail records, TTLs, and recovery before an agency or hosting change.
DNS Handover Without Surprises: Who Controls the Domain, DNSSEC, and Mail?
The website works. Then the agency relationship ends, hosting is being replaced, or an employee leaves. Suddenly somebody discovers that the registrar login belongs to a personal agency address, the nameservers point to an old provider, and nobody knows whether DNSSEC is enabled.
That is not an exotic edge case. A domain is more than a URL. It is a control point for the website, TLS certificates, email, and often several other services.
A good handover therefore does more than export a DNS zone. It establishes who can actually control the domain, which DNS dependencies exist, and how a change can be rolled back without unnecessary downtime.
The crucial distinction: registrar is not the same as DNS provider
The registrar manages the domain registration. That is typically where the delegation to authoritative nameservers is controlled and, when DNSSEC is in use, where DS information is provided to the parent zone. The DNS provider, meanwhile, usually hosts the zone containing A, AAAA, CNAME, MX, TXT, and other records.
Those roles may live at the same company, but they do not have to.
This is where handovers fail: a team receives access to a DNS dashboard and assumes it now controls the domain. If only the former agency can access the registrar, the team may still be unable to change nameservers, update DNSSEC, or transfer the registration.
ICANN describes the Auth-Code as a required element for transferring a gTLD between registrars. If your organization lacks registrar access and a reliable recovery path, that is a concrete operational risk.
Red flag 1: The domain depends on a personal agency or employee account
A handover should answer:
- Who is recorded as the domain holder or registrant?
- Which account can change nameservers, DNSSEC, and transfer settings?
- Who controls MFA and account recovery?
- Where do renewal and security notifications go?
- Is there more than one responsible person or a documented emergency path?
- Can the Auth-Code be obtained when needed?
The answer is not to paste credentials into a chat. Prefer an organization-controlled account, appropriate role separation, MFA, and a documented recovery process.
Red flag 2: There is no complete DNS inventory before the change
A DNS zone often contains much more than the visible website.
Beyond A, AAAA, and CNAME, it may contain:
- MX for inbound email,
- SPF as a TXT record,
- DKIM keys under selectors in
_domainkey, - DMARC under
_dmarc, - CAA controlling certificate issuance,
- verification records for SaaS products,
- subdomains for APIs, shops, analytics, status pages, or customer systems.
RFC 7208 defines SPF records in DNS TXT. RFC 6376 describes DNS publication of DKIM keys. RFC 9989 defines DMARC policy records in DNS.
If a migration copies only the website records, the homepage can remain perfectly reachable while email delivery breaks.
Before changing nameservers, keep an export or at least a structured inventory of the production zone as part of the handover documentation.
Red flag 3: DNSSEC is active but nobody has a migration plan
DNSSEC creates a cryptographic chain of trust. RFC 4033 describes that chain using DNSKEY and DS records, among other elements. With a signed delegation, the information in the parent needs to correspond to the keys used to sign the child zone.
That is why a DNSSEC-enabled nameserver change is not merely “enter the new NS records.”
An old DS record can stop matching the keys served after a move. Validating resolvers can then treat the zone as invalid. Cloudflare explicitly warns, for its own standard migration path, against switching nameservers while incompatible old DS information remains active or cached; more advanced environments can instead use multi-signer DNSSEC migration.
The correct sequence depends on both the old and new providers. At minimum:
- Determine whether DS records exist before the cutover.
- Document who manages the DNSSEC signing keys.
- Choose the migration method supported by both providers.
- Account for relevant delegation and DS TTLs.
- After the change, verify the chain using validating resolvers.
DNSSEC should not be disabled forever simply because migration is inconvenient. But an unplanned key and delegation change can turn a security feature into an outage.
Red flag 4: CAA unexpectedly blocks certificate issuance
CAA lets a domain holder specify which Certificate Authorities are permitted to issue certificates for a domain. RFC 8659 requires conforming CAs to consider relevant CAA records before issuance.
This is easy to overlook during a provider move.
The old host may have issued certificates through CA A while the new platform uses CA B. A restrictive CAA record can be copied unchanged, and the website may continue working until the current certificate needs renewal or a new subdomain needs its first certificate.
Before cutover, check:
- Are CAA records present?
- Which CA does the new platform actually use?
- Are wildcard certificates handled differently?
- Can the platform prepare certificates before the nameserver change?
- Has the renewal path been tested?
A valid certificate on migration day does not prove that the next renewal will succeed.
Red flag 5: TTLs are changed five minutes before cutover
RFC 1035 defines TTL as the interval for which a resource record may be cached before the source should be consulted again.
The operational consequence matters: reducing a TTL just before a change does not retroactively erase answers already stored in resolver caches.
If a critical record previously had a long TTL, resolvers can continue using that old answer until their existing cached copy expires.
TTL planning therefore belongs before the migration. For records that will be deliberately switched, lowering TTL sufficiently in advance can shorten the transition window. Once the new state is stable, values can be raised to sensible operational levels again.
Not every record needs an extremely low TTL. Tiny values increase query volume and do not compensate for poor cutover planning.
Red flag 6: The old DNS provider is shut down immediately
A nameserver change is not a magical global switch. While delegation and cache state expire, some queries may still reach the previous setup.
It is therefore generally sensible to keep the old zone consistent during the controlled transition instead of deleting it the moment new nameservers are entered.
A cleaner sequence is:
- Build the target zone completely.
- Compare it against the production inventory.
- Prepare the website, TLS, mail, and important subdomains on the target.
- Execute the chosen DNSSEC migration method.
- Change the delegation.
- Monitor public DNS resolution, HTTPS, and email.
- Retire the old infrastructure only after the transition has demonstrably completed.
The 20-minute handover audit
Before changing agency, host, or DNS provider, answer these questions:
Access: Do we control the registrar and DNS-provider accounts ourselves? Do MFA and recovery work without one external individual?
Delegation: Which nameservers are actually delegated by the parent? Do they match the expected provider?
DNSSEC: Are DS records present? Who controls signing? What exact migration path will we use?
Zone: Do we have a current inventory of every production record and its purpose?
Email: Are MX, SPF, DKIM, DMARC, and provider verification records documented?
TLS: Is CAA present? Can the new platform issue and renew certificates?
Caching: What TTLs are in force now, not merely what we intend to configure later?
Rollback: How do we revert if the website, mail, or another critical service fails after cutover?
Monitoring: Who checks DNS, TLS, the website, email, and important subdomains during and after the change?
If several answers are “we would need to ask the old agency,” that is the real finding.
What Website-Pflichtencheck can inspect
Not every registrar ownership or private account detail is externally verifiable. That boundary matters.
Website-Pflichtencheck can, however, inspect the public technical control surface and turn it into concrete handover questions, including:
- authoritative nameservers and delegation,
- DS records and visible DNSSEC state,
- CAA records,
- public website and subdomain records,
- MX plus visible SPF, DKIM, and DMARC configuration,
- TLS certificate chain and issuer,
- redirects and reachability of important hosts,
- contradictory or obviously stale DNS targets.
That can be paired with an organizational checklist covering registrar access, MFA, recovery, renewal, and responsibility.
The useful outcome is not a pretty DNS export. It is a handover where the website, email, and domain are not dependent on one forgotten login or one overlooked trust relationship.
If an agency or hosting change is coming, audit domain control before the cancellation date. Afterwards, a simple handover question can become an incident very quickly.