How a name becomes an address, and an address becomes a trusted connection: the domain you buy, the DNS that resolves it, and the certificate that proves who is really there.
← / → to navigate · EN/VI switch below
Before a browser shows you a page, the internet quietly solves three problems. This deck walks through each one.
People type names (example.com), machines speak addresses (IPs). Something must own the names and translate them.
The internet is a mesh of cables and routers. DNS turns a name into an IP so your packet knows where to go.
Anyone can impersonate a server. TLS plus certificates prove the site is who it claims — and keep the trip encrypted.
Four stations, one trip. Everything else in this deck is a zoom-in on one of them.
The name you own: example.com. Bought from a registrar, yours as long as you pay.
The phone book: example.com → 203.0.113.5. The lookup that turns a name into an address.
Your browser connects to that IP on port 443 and talks to your server.
The seal: encrypted traffic plus a verified identity. Private, and provably yours.
domain = the name · dns = name→ip · tls = trust + encryption — together: a professional site
You can't ship a professional site from a raw IP. A domain is the name the world will know you by — and the first thing you control.
IPs are the real addresses — but hostile to humans, and brittle for operators.
A name like example.com is memorable, typeable and brandable. Browsers don't remember — DNS remembers for us.
Migrate your whole site to a new server (new IP) and change one DNS record. Customers never notice.
you@example.com — the domain after the @ is your mail identity. A raw IP can't do that.
A name is a promise of continuity. People bookmark it, print it, type it. It's your address in the world.
Three rings, from least to most yours: the TLD is the street, the SLD is the house number, subdomains are the rooms.
shop.example.com
shop subdomain — as many as you want, you decide
example SLD — the name YOU bought (second-level domain)
com TLD — top-level domain: .com .io .dev .vn ...
shop.example.com = room + house + streetYou buy the middle ring. TLDs are licensed out by ICANN to registries; subdomains are free real estate inside your own domain.
A shop with a license to hand out names from a TLD's registry — nothing more, nothing less.
Namecheap, GoDaddy, Cloudflare… all buy names from the same registries and resell them. The price is whatever the shop decides.
Paying gets you the name and a control panel to set its DNS records (the A and NS records we'll meet soon). That panel is the whole product.
Let the renewal lapse and the name goes back to the pool — along with all your traffic, mail and links pointing at it.
Because the name lives in a global registry, you can move it between registrars whenever you want. Nobody can hold the name hostage.
Selling a name and hosting its records are different jobs. They usually come as one login — but you can (and sometimes should) split them.
The checkout. You pay, they record the name in the registry under you. They don't answer lookups for it.
Think: the office that issues the plate.
Cloudflare, your VPS, the registrar's own DNS service — anyone can hold your domain's records and answer lookups for it.
Think: the phone company that runs your listing.
Buy the name once, and everything else — servers, CDNs, email — can change around it without your customers ever noticing.
Every domain has a page in a global, distributed phone book: 'example.com, 203.0.113.5'. DNS is the system that maintains the book and answers questions about it.
There is no central DNS computer. The book is split into slices, and each slice is kept by whoever owns that part of the name.
The root knows who runs .com. The .com slice knows who runs example.com. Each level only knows the level below it.
'example.com → 203.0.113.5' is one record (an A record). A domain carries several: address, mail, verification…
Your ISP's resolver asks the book for you and remembers the answer for its TTL — the same question never travels the world twice.
You type records into your registrar's panel; resolvers around the globe pick up the change within the TTL. That's the whole job, done.
Your browser never chases answers itself — your resolver does, and each hop only answers 'I don't know, but ask them'.
Types shop.example.com. The browser asks its resolver: 'what's the IP?'
Your ISP's server — the one that chases the whole chain, caches answers, returns the IP to you.
'I don't know that name — but .com is handled over here.'
'example.com's records live on ns1.example-dns.net — go ask them.'
The page itself: 'shop.example.com. A → 203.0.113.5, TTL 300'. The answer comes home.
each hop = one question · the resolver makes all four so your browser gets a single, instant answer
dig asks a DNS question and prints the answer. +short gives just the IP — your everyday 'does it point correctly?' check.
A domain can carry a dozen record types. Six show up in real life — the first two are 90% of your work.
| Record | It answers | Example |
|---|---|---|
| A | Name → IPv4 address | shop.example.com → 203.0.113.5 |
| AAAA | Name → IPv6 address | shop.example.com → 2001:db8::1 |
| CNAME | Name → another name (alias) | www.example.com → shop.example.com |
| NS | Who is authoritative for this name | example.com → ns1.example-dns.net |
| MX | Which server takes mail for the domain | example.com → mail.example.com |
| TXT | Free-form facts — verification, SPF | example.com → "v=spf1 -all" |
Forget the rest until you need them. These two are the whole story of 'point my domain at my server'.
One line: 'this name lives at this IPv4 address.' Change the A record and the whole domain moves — no code touched.
Which servers hold the truth for this name. Point NS at a new provider and the entire page moves with it — the registrar can't stop you.
www → your real name. Browsers follow the alias to the real record. One IP to maintain instead of two.
A place to stick verification codes (Google Search Console, some CAs). You'll meet it again in the Let's Encrypt part.
Five lines in your registrar's DNS panel — and the site is reachable by name, worldwide.
# registrar panel -> example.com -> DNS records
name type value
@ A 203.0.113.5 # the site -> your VPS
@ NS ns1.example-dns.net # who is in charge
@ NS ns2.example-dns.net
www CNAME @ # alias -> the site
@ TXT "v=spf1 -all" # mail policy'@' means the domain itself. Every line is one fact the phone book will answer on your behalf.
You already have a VPS with a public IP (say 203.0.113.5) and a running web server. Now make the name point at it.
Your VPS has a public IP. That's the address the record will carry.
In your DNS panel: name = @ (or example.com), type = A, value = the VPS IP. Save.
Resolvers worldwide still hold the old (or no) answer until their TTL expires. Minutes to a day.
dig from another network (a phone hotspot works). If it returns your IP, the world can find you by name.
One asks a public resolver directly (the outside truth); one asks your local resolver (what the neighborhood thinks).
There is no 'push' in DNS — the world re-reads your page on its own schedule, and that schedule is the TTL.
Every answer carries an expiry: 'remember this for 300 seconds'. Resolvers obey it and skip the whole four-hop trip until then.
TTL is a dial you control in your own records.
When you change a record, every resolver in the world notices at its own expiry moment. Worst case: one full old TTL.
Trick: lower TTL to 300 a day before a cutover, raise it back after.
Big-picture truths that save real debugging hours.
Cached answers are instant. Only the very first lookup for a name pays the four hops.
Usually minutes. 48 hours is the worst case — old, high TTLs sitting in someone's resolver.
It often hosts it for convenience. Any NS servers can — Cloudflare, your VPS, whoever.
CNAME + A records let www, app and api point at completely different machines.
DNS got you the right address. But the trip is still in plain text, and anyone can impersonate the destination. TLS and the public key infrastructure fix both.
Between you and the server sit routers, ISPs and café Wi-Fi. None of them are bound by loyalty.
Plain HTTP is a postcard: every hop can see passwords, tokens and messages. 'Private' isn't even in the vocabulary.
A middle hop can edit what you receive — inject ads, scripts, 'your password is now…'. Nobody notices, because there's no signature on the data.
On open Wi-Fi, 'bank.com' might be a phone in the corner. The name resolved fine — it was just the wrong machine.
One protocol: TLS. It encrypts the trip, signs the data, and proves the server's identity with a certificate. That's the lock icon.
People bundle them as 'the lock'. Mechanically, TLS does two distinct jobs with two distinct tools.
Your browser and the server agree on a secret key; everything after travels as gibberish to everyone in between. Even the server's own ISP sees only noise.
Solved with temporary keys — generated per connection, forgotten after.
The server presents a certificate binding its public key to 'example.com', signed by a Certificate Authority your browser already trusts.
Solved with public keys — the subject of everything below.
The entire trust story of the internet rests on one trick: a key pair where one key locks and only its partner opens.
A server generates a private key (never leaves the server) and a public key (freely published). Math makes them partners: one locks, the other opens.
The public key is like a mailbox's slot: anyone can drop a letter in, but only the keyholder opens it. Leaking the public key costs you nothing.
It signs and decrypts — anything the server does to prove it's the server. If it leaks, the identity is compromised: that's why certificates have expiry dates.
Anyone can generate a key pair and print 'I am example.com'. So: who guarantees the key really belongs to example.com? Enter the CA.
A certificate is a public key plus an identity, signed by a CA. Your browser trusts the roots — and the roots sign down the chain.
Holds a private key (never shared) and a public key. The public key + 'I am example.com' becomes the certificate.
Checks you control example.com, then signs the certificate with its own private key — a digital 'guaranteed by' stamp.
Ships with root CAs built in (let's say, trust them). Verifies the signature chain and the name — then the lock turns green.
if any link in the chain is missing or unsigned, the browser stops the page with a warning
Not a magic protection layer — a specific document with a specific job: 'this public key belongs to this name, and I stand behind it'.
The certificate carries your public key and says 'example.com'. That's the core — everything else is paperwork around it.
A CA signs the certificate with its private key. Browsers verify the signature with the CA's public key — tamper with any byte and it breaks.
Certs live ~90 days (Let's Encrypt) to a few years (enterprise). Expired = untrustworthy, by the browser's rule book.
OS and browser vendors pre-install a handful of root CAs after auditing them. That closed list is the foundation of all web trust.
The whole ceremony runs in a few hundred milliseconds, every time you open an https page. You never see it — until it fails.
'Hi, I'm example.com — here's my public key, signed by this CA chain.'
Cert signed by intermediate? Known? Intermediate signed by a root in my built-in store? Every signature verified with the signer's public key.
Does the cert actually say example.com? Is it within its validity window? One 'no' and the whole thing stops.
Browser and server derive a shared secret; from here on the page, your inputs and every response travel encrypted.
curl can't verify a cert it doesn't trust — and it says so, loudly. The browser shows the same fact as a full-page warning.
The padlock is a claim with a precise scope. Two of the most common misreadings cost real projects.
'The trip is private, and the server I'm talking to is the one whose certificate is signed for this domain.'
A valid cert on a scam domain is still a scam domain. Phishing sites have perfectly green locks — the name is what you should judge.
Subresources on http:// URLs can still leak. Mixed-content warnings in the devtools console are the tell.
The flyout shows the name, the CA and the expiry. Thirty seconds of reading beats any amount of guessing.
For years, a certificate meant paperwork and money. Let's Encrypt made it free, automated, and 90 days — and made the whole web turn green.
Let's Encrypt is a real, well-known Certificate Authority — the kind your browser already trusts. Its only quirk: it signs by the machine, in minutes.
Non-profit, funded by donations and tech companies. If you control a domain, you can get a cert in one command.
The ACME protocol lets your server talk to Let's Encrypt directly: request, prove ownership, receive cert, renew. No humans, no forms.
Short lives mean a leaked private key stops mattering in a quarter. Renewal is automated — that's the design, not a limitation.
Its root is in every major browser and OS. For the lock, it's identical to a $200/year enterprise cert.
The CA can't see your registrar. It tests one thing: 'can you place a secret on this domain?' If yes, you control it.
certbot tells Let's Encrypt: 'I need a cert for example.com'.
Let's Encrypt hands you a random string: 'put this at http://example.com/.well-known/acme-challenge/abc123'.
Your web server responds to that URL with the token. If the domain points at you and your server answers, you control the domain.
It fetches the token from the public internet, checks it matches, and issues your signed certificate. Total time: under a minute.
certbot runs the ACME dance with your web server (nginx here), installs the cert, and wires up auto-renewal. Then you forget about it.
The only ongoing job is 'don't let the renewal break'. Everything else is one command.
A cert lives 90 days. From ~day 60 onward it's 'due for renewal' — certbot renews automatically, no notice needed.
A systemd timer (or cron) runs 'certbot renew' a couple of times a day. If nothing is due, it does nothing and exits.
A firewall that blocks port 80 during the challenge, a DNS record that moved, or the timer disabled after a migration. The renew log is where you look.
Once after setup: read one renewal log and watch it succeed. After that, it's a fire-and-forget machine.
Three machines, one pipeline. You own all three — and each one can change without breaking the others.
Bought once from a registrar. Your identity: the site, the email, the brand. It outlives every server.
A record or two pointing the name at your VPS's IP. Change a line and the whole site moves.
A free, auto-renewed certificate binding your server to the name. Encrypted, verified, green.
reachable by name · movable at will · trusted by default — the three properties every professional site has
The whole deck, compressed into the five actions you'll actually take — and the command that proves each one worked.
| # | Move | Prove it with |
|---|---|---|
| 1 | Buy the domain from a registrar | you@example.com mail works |
| 2 | Add the A record: @ → your VPS IP | dig example.com A +short |
| 3 | Add www → example.com CNAME | dig www.example.com |
| 4 | Run certbot --nginx -d example.com | curl -I https://example.com |
| 5 | Confirm certbot.timer is active | systemctl list-timers |
You don't need to memorize DNS record types or certificate fields. You need one picture: a name, a phone book, and a signed promise — and the five commands that keep them honest.
Buy the name, point the record, run certbot — then go build the thing the certificate protects.