You bought a domain, paid for hosting, the designer delivered the mockup — and the site still won’t open at your address. Or it opens for you, but not for a client in another country. The root of that confusion is almost always the same thing: DNS. It’s the invisible part of your infrastructure nobody thinks about while it works, and everybody complains about the moment something goes wrong.
Let’s unpack it in plain language: what DNS is, how it turns your address into a real website, which records you’ll end up editing yourself, and why changes sometimes take a full day to reach everyone. No academic phrasing — just the way we explain it to clients at Netloria when we connect a new domain for them.
Computers have no idea what “netloria.com” means. They speak in numbers — IP addresses like 192.0.2.10. A human, though, won’t memorise a string like that for every site they use. DNS (Domain Name System) is the layer that keeps the match between the human-friendly name and the machine-friendly address.
The old phone book analogy fits almost perfectly here. You know a person’s name, but to call them you need a number. You look up the name, you get the number. DNS does the same: the browser knows the site’s name, and DNS hands back its “number” — the IP address of the server where the site lives.
The difference is scale. A phone book is one thick volume. DNS is a distributed system of millions of servers around the world, constantly querying one another, and all of it happens in fractions of a second every time you open any page.
When you type an address and hit Enter, a small chain of queries unfolds behind the scenes. It looks like this.
First the browser reaches out to a recursive resolver — usually your provider’s server or a public resolver (the famous 8.8.8.8 from Google or 1.1.1.1). The resolver is the middleman that takes on all the legwork of the lookup. If it searched for this site recently, it answers straight from cache. If not, it goes asking further.
Next the resolver goes to the root servers. There are only 13 of them worldwide — labelled with the letters A through M, and they don’t know any specific site’s address, but they do know who’s responsible for the .com, .org or a given country zone. The root essentially says: “For .com, go ask this server.”
The resolver then queries the TLD server (the top-level domain — .com, .io and so on). That one doesn’t know your site’s IP either, but it knows which nameservers serve your particular domain. And only now does the resolver reach the authoritative nameserver for your domain — the place where all the records actually live. That’s what returns the final IP address.
Recognise the feeling when a site “thinks” for the first half-second, then flies? Part of that pause is the chain above. The good news: the result is cached at every step, so next time the answer arrives almost instantly.
Inside your domain or hosting control panel you’ll see a list of records. It looks intimidating, but a typical site owner only needs to understand a handful of types. Here they are.
| Record type | What it controls | When you touch it |
|---|---|---|
| A | Points the domain to a server’s IPv4 address | Moving the site to new hosting |
| AAAA | Same, but for the newer IPv6 address | Rarely, if the host requires IPv6 |
| CNAME | Makes one domain an alias of another (e.g. www → main domain) | Setting up a subdomain or connecting an external service |
| MX | Tells the world which server receives mail for the domain | Connecting business email (Google Workspace, etc.) |
| TXT | Arbitrary text: ownership proof, email-protection settings | Verifying the domain, configuring SPF/DKIM |
| NS | Specifies which nameservers manage the domain | Moving DNS management to another provider |
Ninety per cent of real situations come down to two records. The A record — when you need to point the domain at a new server. MX and TXT — when you set up email on your own domain. The rest, for an ordinary business site, you may not touch for years.
Here hides the most common confusion, and it’s the one that eats the most nerves. There are two different levels at which you can “manage DNS,” and people mix them up constantly.
The first level is nameservers. You set those where you bought the domain — at the registrar. Nameservers answer the question “who’s actually in charge of this domain, who stores its records.” As long as the registrar points to one provider’s nameservers, that’s where you edit every A, MX and TXT record. Change the nameservers to a different set, and the registrar stops looking at the old records — it sends everyone to the new “owner” of the zone.
The second level is the records themselves (A, MX, CNAME…). They live wherever your currently active nameservers are. That could be your registrar, your hosting provider, or a separate DNS service.
The classic trap goes like this. A client buys the domain from one provider and hosting from another (which, by the way, is perfectly normal — domain and hosting are usually bought separately), goes into the hosting panel, dutifully changes the A record to the right IP — and nothing happens. Because the nameservers at the registrar still point to the registrar, not to the host. The edits went somewhere the internet isn’t looking. First you decide who runs the zone, then you edit records in the right place.
At Netloria we pin this down as the very first item on every project: where the domain was bought, where the site will live, and whose nameservers the DNS runs on. That single answer removes most future “the site won’t open” tickets.
You changed the A record, refreshed the page — old site. An hour later you see the new one, but a colleague in another city still sees the old. That’s not a bug. That’s propagation — changes spreading across the world.
The cause is caching. Resolvers everywhere store the answer they got for a set time, so they don’t pester the authoritative server on every request. How long to store it is decided by the TTL (Time to Live) value, given in seconds right inside the record. Until the TTL expires, the resolver serves the stale, cached answer and doesn’t even ask about updates.
The standard TTL for an ordinary A record is 86,400 seconds — a full 24 hours. So in theory changes can take a long time to reach everyone. In practice, according to the same source, propagation usually settles within a few hours, though in some cases it stretches up to 72 hours.
There’s a trick for a planned move. A day or two before the change, you lower the TTL of the record in question to 30–300 seconds — then resolvers refresh their cache almost immediately instead of once a day. After the move you set the TTL back, so you don’t overload the servers needlessly. This is standard procedure when migrating a site to new hosting, and it turns a nerve-wracking blind switch into a controlled, near-invisible cutover.
In practice, the sequence we use to migrate client sites looks roughly like this: first we lower the TTL of the old records a day or two ahead, then we stand up a full copy of the site on the new server and test it separately, before any switch; only once the new version runs flawlessly do we change the A record to the new IP — and because the TTL is already low, most visitors land on the new server within minutes rather than seeing the old and new versions flip-flop for hours. We leave the old server running for another day as insurance until propagation completes. It sounds tedious, but that exact tedium is what saves a client their lost orders on moving day.
Years of connecting domains for clients builds up a recognisable list of rakes to step on. Here are the most typical ones — not abstract, but the ones we genuinely keep running into.
Notice the pattern? Almost none of these are about “complex technology.” They’re all about attention and about understanding which lever switches on what.
DNS is responsible for more than just getting the site to open. Through TXT records you configure protection for your email against forgery — SPF, DKIM and DMARC. In plain terms: these records tell the world’s mail servers which servers are allowed to send messages on behalf of your domain. Without them your emails land in spam more often, and it’s easier for an attacker to pretend they’re writing as you.
It’s the same logic of trust as an SSL certificate, only for email. And it’s one more reason not to leave DNS to fend for itself: wrong or missing records hurt not only the site’s availability but the reputation of the whole domain.
To keep DNS from being a black box, hold a few anchor points in mind.
You don’t have to love DNS or learn it to a sysadmin’s level. It’s enough to understand that it’s the layer translating names into addresses, that changes to it aren’t instant, and that you have to edit them in the place that actually runs the domain right now. The rest is handled by whoever sets up your infrastructure.
Netloria — a web studio based in Ukraine — takes this part on entirely: we register or transfer the domain, connect the hosting, set the right records, configure email and security, so you never once see the word “propagation” in your life. If you want a website that simply works from day one, with no dancing around nameservers — order corporate website development from Netloria, and we’ll take the whole technical kitchen off your plate.
