Connecting a domain to a website

Records, or nameservers

There are two ways to point a domain at a host. You can change the nameservers to your host's, handing them the whole zone, or you can keep your current DNS and add records pointing at the host.

Handing over the nameservers is fewer clicks and is what most hosts recommend. It also moves every record you have — including MX records for email — so if mail is configured at your current provider and does not get recreated, mail stops. Adding records keeps everything else where it is and changes only what you name. Unless you have a reason to move the whole zone, adding records is the safer default.

The apex and www

The bare domain — the apex — usually needs an A record pointing at your host's IP address, because a CNAME is not allowed there. For www you can either add a second A record with the same address, or a CNAME pointing at the apex so it follows automatically. The CNAME means one less thing to update if the address ever changes.

Pick one of the two as canonical and redirect the other to it. Serving the same site on both without a redirect splits your links and your analytics for no benefit.

Then the certificate

Hosts that issue certificates automatically cannot start until the DNS actually points at them — domain validation has to verify control of the name. So HTTPS will fail for a while after the records are correct. This is expected and self-correcting; on a recent setup of our own, the certificate was issued about two minutes after the record resolved.

Check it properly

Ask an authoritative nameserver directly rather than trusting your browser: dig +short @ns1.yourprovider.com yourdomain.com A, or a DNS lookup if you would rather not open a terminal. Then check a couple of public resolvers, @8.8.8.8 and @1.1.1.1, to see how far the change has spread. When those agree with the address you set, the DNS side is finished.

When the browser still shows the old site

This is normal and it is almost never the DNS. Browsers cache aggressively, and Chrome keeps its own host cache separate from the operating system's — which is why a domain can load correctly in Safari and still show a parking page in Chrome on the same machine.

Parking pages make this worse, because some of them redirect using JavaScript rather than an HTTP redirect. A command-line check sees a clean 200 and reports success, while the browser runs the script and lands somewhere else entirely. If curl and the browser disagree, look at the actual bytes the server returned before assuming the DNS is wrong.

The fix is local: clear the browser's host cache, or open the site in a private window. Nothing needs changing at the registrar.