Domain, Hosting and DNS Without the Jargon

Domain, hosting and DNS are three separate things that usually arrive on one invoice, which is how businesses end up not knowing who owns their website's address. The jargon is not the real problem. The real problem is that each of the three can be held by a different party, and one of them is much harder to get back than the other two.

This guide explains what each one actually is, and then covers the part that nobody explains until it goes wrong: the rules ICANN publishes about when you can and cannot move a domain.

The three things, in plain terms

The domain is a name you rent. Nobody owns a domain outright — you hold a registration for a term, renewable. The company you pay is a registrar; the organisation that runs the whole extension (.com, .co.uk, .com.tr) is the registry. The person or company recorded as holding the registration is the registrant, and that word is the one that matters most in this article.

Hosting is the machine your site runs on. It stores the files, runs the code and holds the database. Moving hosting is a normal, reversible operation — you copy the site somewhere else and point at it.

DNS is the lookup table. When someone types your domain, their computer asks DNS which server to talk to. DNS can live at your registrar, at your host, or at a third party, and pointing a domain at a new host is a DNS change rather than a domain change.

The practical summary: hosting and DNS are moves you can make in an afternoon. The domain is not, and it is the one people forget to check.

Who is the registrant, really

This is the single question to ask before anything else, and most businesses have never checked the answer.

If an agency, a freelancer or a former employee is listed as the registrant, they hold the registration. Not the site, not the content, not the hosting — those you can rebuild. But the address your customers type, your email routing and every backlink you have ever earned all depend on a name that is legally someone else's to move.

Our position on this is in our website ownership guide: register the domain yourself, before the project starts, on an account with a company email address that survives staff changes. Give the agency DNS access if they need it. Never the registrant record — the same principle applies to the repository and every other account. The same goes into the contract, along with the rest of the paperwork when the supplier is abroad.

The 60-day rules nobody mentions

Here is where ICANN's own Transfer Policy becomes the most useful document in the conversation, because it sets out exactly when a registrar is allowed to say no.

A registrar may deny a transfer when:

"3.7.5 The transfer was requested within 60 days of the creation date as shown in the registry Whois record for the domain name."

and when:

"3.7.6 A domain name is within 60 days (or a lesser period to be determined) after being transferred…"

So a newly registered domain is stuck for two months, and a freshly transferred one is stuck for another two. If someone registers a domain on your behalf today, you cannot take it anywhere until that window closes — whatever either of you agreed.

There is a third lock, and it catches people doing exactly the right thing in the wrong order. A registrar must deny a transfer when:

"3.8.5 The Registrar imposed a 60-day inter-registrar transfer lock following a Change of Registrant, and the Registered Name Holder did not opt out of the 60-day inter-registrar transfer lock prior to the Change of Registrant request."

So changing the owner can lock the domain in place for two months. ICANN says what to do about it in the policy itself: the prior registrant "is advised to request the inter-registrar transfer before the Change of Registrant to avoid triggering the 60-day lock."

The order is therefore: move the registrar first, change the registrant second. Most people do it the other way round because changing the owner feels like the important step, and then spend two months unable to finish the job.

The lever you do have

One clause is worth knowing because it changes the tone of a difficult conversation. ICANN lists instances when a transfer may not be denied, and the first is:

"3.9.1 Nonpayment for a pending or future registration period."

A registrar can refuse a transfer for non-payment of a previous registration period. It cannot hold your domain against a renewal that has not happened yet. If someone is refusing to release a domain over an invoice for future service, that is not a rule they are following.

DNS, and why migrations go wrong at 3am

DNS records carry a TTL — time to live — which is how long other machines are allowed to remember the answer. Cloudflare's documentation puts it precisely: TTL "controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users." Its Auto setting is 300 seconds, and proxied records are fixed at that value.

The failure mode is always the same. A migration is scheduled, the TTL is lowered on the day, and the change still takes hours to reach everyone — because the old, longer TTL is what the world already cached. Lower the TTL a day or two before the migration, not during it. Cloudflare also notes the honest caveat: "it may take longer than 5 minutes for you to actually experience record changes, as your local DNS cache may take longer to update."

And keep email in mind. MX records live in the same zone as the website records, so a careless "point the domain at the new site" can take the company's mail down. Check MX before, not after.

What we do on a project

We ask for DNS access and we do not ask to be the registrant. The client registers the domain, or already has it, and we work inside it.

When a client arrives holding a domain registered to a previous agency, the first thing we do is establish which of the three 60-day clocks is running, because that determines the launch date more reliably than any development estimate. It is also the reason we put this question at the start of a project rather than at the end, which we cover in our step-by-step build guide.

We do not treat "we'll manage the domain for you" as a service. It reads as convenience and functions as a lock, and a client who cannot leave without a negotiation is not a client relationship we want. Our web development page sets out what we do handle.

The five-minute check

1. Look up your own domain. A public WHOIS or RDAP lookup will show the registrar and often the registrant organisation. If the name is not yours, that is today's task.
2. Confirm the account email is a company address, not a person's, and not one that stops working when they leave.
3. Check the expiry date and turn on auto-renew. The most common way to lose a domain is not a dispute; it is a card that expired.
4. Know where DNS is hosted — registrar, host or a third party — and who has the login.
5. Before any migration, lower the TTL a day ahead and write down your MX records first.

If you would rather have someone check which clocks are running before you commit to a launch date, send us the domain and we will tell you what the records say. Where the domain and hosting decision falls in the build sequence is covered in how to build a website.