# 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.

Source: https://cwp.sg/guides/how-to-host-a-website/point-a-domain-to-your-host/  
Author: Ben Johnson  
Last verified: 2026-08-02

**In short:** You have two options. **Change your nameservers** at the registrar to your host's — simplest, and the host then manages all DNS. Or **keep your DNS provider** and add an `A` record for the root plus a `CNAME` for `www`. Use the second if your email is already configured elsewhere.

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](/tools/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](/tools/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

| Symptom | Cause |
|---|---|
| [NXDOMAIN](/errors/dns-probe-finished-nxdomain/) after hours | Nameservers at the registrar don't match where you created records |
| Root works, `www` doesn't | `www` needs its own record; it isn't automatic |
| Email stopped after switching nameservers | `MX` records didn't come along — recreate them at the new provider |
| Site loads for others, not for you | Your local DNS cache. Flush it. |
| [Too many redirects](/errors/err-too-many-redirects/) after moving | Two HTTPS redirects now active — the host's and your own |
| Certificate warning right after switching | Normal. The certificate is issued after DNS resolves; wait a few minutes. |

## 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](/guides/how-to-host-a-website/#5-turn-on-https).

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.