How to Transfer a Domain to a New Registrar Without DNS Downtime

When you move a domain to a new registrar, you change the company that manages its registration, renewals, and transfer settings. Your DNS host is the service that answers requests for the domain using its DNS records, which direct visitors to your website and route email. One company can provide both services, but they are separate functions.

To avoid DNS downtime, keep the existing DNS host and nameservers in place during a registrar-only transfer. Nameservers are the servers that provide authoritative DNS answers for a domain. If your current DNS service will end when you leave the old registrar, set up replacement DNS before the transfer instead. Check which services your registrar provides and avoid changing the domain’s nameserver settings by accident.

Check who hosts your DNS

Before starting, identify the current registrar, the DNS host, and the domain’s authoritative nameservers. Record the nameservers and save a copy of the DNS zone, the set of records that directs website, email, and other domain traffic.

Then confirm whether the old registrar also provides your DNS service and whether that service will remain active after the transfer. If it will end, you need a replacement DNS host before proceeding. As Amazon Route 53’s DNS migration guidance warns, losing a registrar-provided DNS service without moving the zone can make websites and other services unavailable.

If your DNS host will continue operating, leave its zone and nameservers unchanged. For example, Route 53’s instructions tell customers who are keeping Route 53 for DNS to give the new registrar their existing Route 53 nameservers. Check the new registrar’s transfer screen and enter those nameservers if it asks; do not assume every registrar carries them over automatically.

Transfer the registration and keep DNS steady

First, confirm that the domain is eligible for transfer and that you can access the email address used for transfer notices. Check for transfer locks. If the domain’s registry uses an authorization code, obtain it. Many domains use an authorization code, also called an AuthInfo code, but country-code domains can follow different procedures. The ICANN Transfer Policy sets rules for covered transfers, including restrictions related to the first 60 days after domain creation or a completed transfer. It also sets a 60-day transfer lock after a change of registrant, with an opt-out potentially available before the change where the registrar offers that option.

During the new registrar’s transfer flow, select the option to retain the current nameservers or enter them exactly as recorded. Avoid choosing the new registrar’s default nameservers unless you have already moved the DNS zone there. Then complete the registrar’s authorization steps and watch the registered contact email for notices. The required steps depend on the registrar and the domain’s top-level domain, or TLD.

After the transfer completes, check the nameservers shown in the new registrar account. Confirm that they still point to the existing DNS host, then check that the DNS host continues to answer with the expected website and email records. When you keep the domain pointed at the same nameservers and leave the DNS zone unchanged, you do not need to change DNS records or wait for DNS caches to update. That reduces the risk of an outage, but it does not guarantee one cannot occur if a registrar changes the nameservers, suspends the domain, or ends the DNS service.

Move DNS separately when the old service will end

If you also need to change DNS hosts, prepare the replacement zone before changing nameservers. Copy the records, check that the new provider supports any special record types or routing features you use, and test the new DNS service. Some provider-specific features do not have direct equivalents elsewhere; Route 53, for example, identifies alias records and certain routing policies as items to review when moving to another provider.

Once the replacement DNS service is ready, change the domain’s nameserver delegation and keep the old DNS service active during the transition. DNS resolvers, the servers that look up domain records for visitors, cache answers. As a result, some visitors may continue using the old nameservers after you make the change. AWS says nameserver TTLs are typically 24 to 48 hours and that a change can take up to two days to take effect; those figures describe Route 53 guidance, not a guaranteed schedule for every provider. Its DNS troubleshooting guidance also explains why deleting the old zone too soon can make a domain unavailable to resolvers still using the old nameservers.

A record’s TTL, or time to live, tells a resolver how long it can keep a cached copy of that record before checking again. Lowering record TTLs can help when you are changing records, but it does not remove caching of the nameserver delegation or replace testing the new zone. If you are only changing registrars and keeping the same DNS host, changing TTLs is not the main continuity measure.

Check DNSSEC and provider-specific rules

DNSSEC adds cryptographic checks that help resolvers verify DNS answers. A DS record, stored in the DNS zone above your domain, links the domain to the keys used to sign its DNS zone. If DNSSEC is active, check the instructions from both registrars and your DNS host before changing anything. Removing or replacing DNSSEC information without coordinating the signing keys and DS record can cause resolvers to reject DNS answers as invalid.

Provider instructions can differ. Route 53 recommends disabling DNSSEC before a transfer to Route 53 in its documented workflow because the existing keys and DS record do not transfer automatically there. Cloudflare’s troubleshooting guidance describes a different, service-specific restriction: active DNSSEC at the current registrar blocks a transfer to Cloudflare, and Cloudflare advises waiting for the DS-record TTL to expire after disabling it. Use the instructions for your particular transfer, since the procedures differ by provider.

Some registrars also require a particular setup before they accept a transfer. For example, Cloudflare documents a workflow that requires the domain to be active on Cloudflare and pointed to Cloudflare nameservers before the transfer begins. Country-code domains can have their own rules as well; some.uk-family transfers use an IPS tag instead of the standard authorization-code flow. Check the new registrar’s instructions for your TLD before you begin.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com