You Bought a Domain. Now What? Connecting It to Hosting

Registering a domain buys you a name in a registry database. It does not put anything on the internet. A freshly registered domain resolves to nothing until you tell the DNS system where to send visitors — and that step is where most first-time owners lose a day.

This guide covers the path from "purchase confirmed" to "site loads over HTTPS."

1. The Two Things You Just Bought (and the One You Didn't)

Component	What it does	Who provides it
Registration	Your exclusive right to the name	Registrar
DNS hosting	Answers "what IP is this name?"	Registrar or host (free)
Web hosting	Actually serves your files	Separate purchase

The third row is the one people miss. A registrar sells you the name; it does not, by default, run a web server for you. If you skip hosting, your domain is a signpost pointing at an empty lot.

2. Pick Your Connection Method

There are two ways to point a domain at a host. Choose one — mixing them is the single most common cause of a half-broken setup.

Option A: Change nameservers (recommended for beginners)

You hand DNS control to your host entirely. At your registrar, replace the default nameservers with the two-to-four your host gave you:

ns1.yourhost.com
ns2.yourhost.com

Pros: the host manages every record for you; their one-click installers work. Cons: you must manage all records in their panel, including email.

Option B: Keep registrar DNS, add records

You leave nameservers alone and add records pointing at the host's IP:

A     @      203.0.113.10
CNAME www    yoursite.yourhost.com.

Pros: DNS stays in one place even if you switch hosts. Cons: you must update records manually whenever the host's IP changes.

3. The Records That Matter

Record	Host	Points to	Purpose
A	@	IPv4 address	Root domain
AAAA	@	IPv6 address	Root over IPv6
CNAME	www	hostname	The www subdomain
MX	@	mail server	Inbound email
TXT	@	verification string	SPF, domain ownership

A root domain (example.com with no subdomain) cannot use a CNAME under the original DNS spec. Providers work around this with ALIAS/ANAME/CNAME-flattening records — if your host offers one, use it for the root and a normal CNAME for www.

4. Propagation: What It Actually Is

"Propagation" is not data crawling across the internet. It's caches expiring. Every DNS record has a TTL (time to live) in seconds, and resolvers hold the old answer until it lapses.

The practical trick: lower your TTL to 300 seconds at least 24 hours before a planned migration. Then the cutover takes five minutes instead of two days. Raise it back to 3600+ afterward to reduce lookup latency.

Check what the world currently sees rather than guessing:

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

If those disagree, you're mid-propagation, not broken.

5. SSL Comes After DNS, Not Before

Almost every host issues free Let's Encrypt certificates, but issuance requires proving you control the domain — which is verified through DNS. If DNS isn't resolving to the host yet, certificate issuance fails with a confusing error.

Correct order:

1. Point DNS at the host.
2. Wait for resolution to confirm (dig).
3. Trigger SSL issuance.
4. Enable "force HTTPS" redirects.

Enabling forced HTTPS before a certificate exists produces a browser security warning that looks far worse than a plain "not found" page.

6. Failure Modes and What They Mean

Symptom	Likely cause
DNS_PROBE_FINISHED_NXDOMAIN	No A record, or nameservers not yet updated
Site loads at www but not root	Missing root A/ALIAS record
Old site still showing	Cached TTL not expired, or browser cache
Certificate warning	SSL issued before DNS pointed correctly
Email stopped working	Nameserver switch dropped the MX records

That last row deserves emphasis. Switching nameservers wipes your existing MX records. If you had email running on the domain, copy every MX and TXT record into the new provider before you flip nameservers, not after.

7. A Sane Launch Checklist

• Hosting purchased and account provisioned
• Existing MX/TXT records exported (if any)
• TTL lowered 24h in advance (for migrations)
• Nameservers OR A/CNAME records set — not both
• dig confirms resolution from an external resolver
• SSL certificate issued and verified
• Force-HTTPS enabled
• www and root both resolve
• Email send/receive tested
• TTL raised back to normal

Closing Thought

The gap between owning a domain and running a site is small but unforgiving: a handful of records, one ordering constraint (DNS before SSL), and one trap (nameserver changes dropping email). Get those right and the whole thing takes fifteen minutes.

Use the main search to find your name, then work this checklist top to bottom.