Guide

Point a domain at your host

Nameservers or A records, what actually happens when you change them, and how to migrate a live site without downtime.

Ben Johnson · last checked 2026-08-02 · 6 min read

Pointing a domain at a host is two minutes of work and up to 48 hours of waiting, and almost every problem people have with it comes from misunderstanding which of those two parts they’re currently in.

What a domain actually does

A domain name doesn’t contain your website. It’s an entry in a distributed lookup system that answers one question: which IP address should I send this request to?

Three parties are involved, and knowing which is which tells you where to make changes:

• The registrar — where you bought the domain (Namecheap, Cloudflare, GoDaddy). It controls one thing that matters here: which nameservers the domain uses.
• The DNS provider — whoever runs those nameservers. This is where the actual records live. It’s often the registrar, but it doesn’t have to be, and it’s frequently your host.
• The host — where the files are.

Almost every “I changed the record and nothing happened” report is someone editing records at a DNS provider whose nameservers the domain no longer uses. Confirm which zone is authoritative before touching anything:

dig +short NS example.com

Whatever that returns is where your records must live. Nothing else is consulted.

Option 1 — change the nameservers

The simpler path, and the right default.

Your host gives you two or more nameservers, something like:

ns1.example-host.com
ns2.example-host.com

At your registrar, find the domain’s DNS or nameserver settings, replace what’s there, and save. That’s it — the host now controls all DNS for the domain, and the account’s records are created automatically.

Choose this when your host is handling everything and you have no email or other services on the domain.

The trade-off: you hand over the whole zone. If you have email configured, its MX records live in the old zone and will stop being consulted the moment the nameservers change — mail stops arriving immediately, with no warning.

If you have email on the domain, either recreate the MX records at the new provider before switching, or use Option 2.

Option 2 — point individual records

Keep your DNS where it is and change only what needs to change. More control, and no risk to email.

You need your host’s IP address, shown in the control panel. Then, at your DNS provider:

Type    Name    Value                TTL
A       @       203.0.113.10         300
CNAME   www     example.com.         300

@ means the root domain itself. The trailing dot on example.com. is significant in zone files — without it many providers append the domain again and you end up with example.com.example.com. Some interfaces add it for you; check what was saved rather than assuming.

Why not a CNAME on the root? The DNS specification doesn’t allow a CNAME to coexist with other records at the same name, and the root must carry NS and SOA records. Some providers offer ALIAS or ANAME records that simulate it. Otherwise use an A record at the root.

Understanding TTL — the one thing worth planning

TTL is how many seconds resolvers may cache a record before asking again.

The critical detail: when you change a record, the delay is governed by the TTL of the old record, not the new one. A record published with a 24-hour TTL can be cached for a full day after you change it. Lowering the TTL afterwards does nothing to copies already handed out.

This gives you the one genuinely useful DNS trick:

1. A day or two before the move, lower the TTL on the records you’ll change to 300.
2. Wait for the old TTL to expire everywhere.
3. Make the change. It now propagates in about five minutes.
4. Raise the TTL back to 3600 or higher once you’re satisfied.

Planned ahead, this turns a 24-hour cutover into a five-minute one. Done after the fact, it achieves nothing.

Migrating a live site without downtime

The order matters. Done in this sequence, visitors never see an error:

1. Lower the TTL on the records you’ll change, at least 24 hours ahead.
2. Upload the site to the new host and get it fully working on the temporary address. Test everything.
3. Copy the database across and confirm the new site reads from it.
4. Set the site to read-only, if it accepts user content, so nothing is written to the old database during the switch.
5. Change the DNS record.
6. Leave the old host running for at least 48 hours. Resolvers still holding the old address must keep working. Cancelling immediately is the classic way to create the downtime you were trying to avoid.
7. Verify propagation with the DNS propagation checker, then re-enable writes.
8. Raise the TTL and cancel the old account.

Checking whether it worked

Your own machine is the worst place to check. Browsers, operating systems and routers all cache DNS, so you can be looking at a stale answer long after the change is live everywhere else.

Query public resolvers directly instead:

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8

Or use the DNS propagation checker, which asks several independent resolvers at once and tells you whether they agree.

If they agree, you’re done — anyone still seeing the old site has a local cache that will expire on its own. If they disagree, it’s still propagating; nothing you do will speed it up.

To clear your own cache:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux (systemd-resolved)
resolvectl flush-caches

Chrome keeps a separate cache of its own at chrome://net-internals/#dns.

Common failures

Turn on HTTPS once the domain resolves

Once DNS resolves to the new host, issue a certificate. Most panels do it automatically within minutes of the domain pointing correctly — the validation requires DNS to be working first, which is why the order matters.

Then force HTTPS in exactly one place, as described in the main guide.