Pointing your domain at your website, without the jargon

You own a domain. Your website exists somewhere. Between the two sits DNS, which is where most people's confidence runs out — usually because it is explained with a metaphor about phone books and then never explained again.

It is genuinely simple. Here is what is actually happening, what to type, and why the thing you changed has not worked yet.

What DNS is doing

Computers find each other by number, not by name. When someone types khamsum.bt, their device has to turn that into an address like 203.0.113.40 before it can ask anybody for anything.

DNS is the lookup that does the turning. Your domain has a set of records — a small list of instructions — held by whoever runs DNS for it. When you “point your domain at your website”, you are editing that list. Nothing moves. No files are copied. You are changing an instruction that says “for this name, go and ask that machine.”

This is also why DNS is safe to experiment with: a wrong record makes the site unreachable for a while, and correcting the record fixes it. Your website's contents are never involved.

Where the records live

Usually with your registrar — the company you bought the domain from — under a menu called DNS, DNS Management, Zone Editor or Advanced DNS. Occasionally it has been delegated somewhere else, in which case the registrar's page will tell you which nameservers are in charge and you edit the records there instead.

The record types you will meet

The Name field, and the @ symbol

Every record has a Name (sometimes Host). This is the part before your domain, and it trips up nearly everyone:

Put in only the part before the domain. Typing www.khamsum.bt into the Name field usually creates a record for www.khamsum.bt.khamsum.bt, which will not work and will look like it should.

Doing it

Whoever hosts your site gives you either an IP address (four numbers with dots) or a hostname (something like sites.bt). Which one you get decides which record you create.

If you were given an IP address

The first sends the bare domain to the machine. The second makes www follow the bare domain, so you only ever have one address to update later.

If you were given a hostname

Then point the bare domain at www using whatever your registrar calls it — domain forwarding, URL redirect, ALIAS or ANAME. There is a technical reason for the awkwardness: the rules do not allow a plain CNAME on the bare domain, because it would collide with the records that make your email work. This is not your registrar being difficult.

If your registrar offers ALIAS or ANAME, use it — it behaves like a CNAME but is legal at the root.

Pick one address and mean it

Decide whether your site is khamsum.bt or www.khamsum.bt, and make the other one redirect to it. Both working independently is not twice as good — it splits your search results between two addresses and makes analytics report half your visitors twice.

Why it has not worked yet

You saved the record and the site is still not there. This is normal and almost always one of five things.

1. It has not propagated

DNS answers are cached all the way down the chain, for a period set by the record's TTL in seconds. A TTL of 3600 means a computer that already looked up your domain will not ask again for an hour. Some networks ignore this and cache longer.

Allow a few hours, and up to 48 for the last stragglers. If you know a change is coming, lower the TTL to 300 a day beforehand, make the change, then put it back. That is the whole trick, and it is why professionals appear to make DNS changes take effect instantly.

2. Your own computer is lying to you

Your machine and your router cache too. Before concluding anything, check from a phone on mobile data — a completely different network path. If it works there and not on your laptop, the record is fine and you are looking at a local cache.

3. There is an old record still there

The single most common real fault. Registrars pre-fill a parking page record, and adding yours leaves two A records for @. Visitors then get one or the other at random, which produces the maddening “it works for me but not for my colleague”.

Delete the old record. There should be exactly one A or CNAME for each name.

4. The name field has the domain in it

Look at what the registrar displays after saving. If it shows khamsum.bt.khamsum.bt, you typed the full domain into a field that only wanted the prefix. Edit it to @ or blank.

5. You edited the wrong nameservers

If the domain's nameservers point somewhere else — a previous host, a CDN — then the records at your registrar are being ignored entirely. Everything you typed is real and read by nobody. Check which nameservers are authoritative and edit there.

Checking it properly

Do not judge by loading the site in the browser you have been refreshing for an hour. Ask DNS directly. On macOS or Linux:

On Windows:

That prints what DNS currently answers, with no browser cache in the way. If it prints what you expect, the record is right and you are waiting on caching. If it prints something else, or nothing, the record is wrong and waiting will not help.

Two things not to break

• Do not touch MX records. They route your email. Changing where a website points has nothing to do with them, and deleting them stops mail arriving — often noticed days later, when someone asks why you never replied.
• Do not delete TXT records you do not recognise. They commonly prove domain ownership for email or other services. Removing one breaks something quietly, somewhere else.

Then: the certificate

Once DNS resolves, your site needs a certificate for https://. Most hosts and platforms issue one automatically within minutes of the domain pointing at them — but they cannot start until DNS is correct, which is why a “certificate error” right after a DNS change usually means wait a little longer rather than something is broken.

If it is still failing after an hour of DNS resolving correctly, that one is worth asking your host about.

The short version

1. Get into your registrar's DNS screen.
2. Lower the TTL to 300 and wait a day, if you can plan ahead.
3. Delete any existing A or CNAME record for the name you are setting.
4. Add one record, with only the prefix in the Name field.
5. Point www and the bare domain at the same place; redirect one to the other.
6. Check with dig or nslookup, not with your browser.
7. Wait. Then check from a phone on mobile data.

If you get stuck, tell us what you typed and what you see. This is the step we help people through most often, and there is no embarrassment in it — the interface is genuinely bad almost everywhere.