{"id":1300,"date":"2026-09-25T16:17:30","date_gmt":"2026-09-25T16:17:30","guid":{"rendered":"https:\/\/netloria.com\/blog\/what-is-dns-en\/"},"modified":"2026-10-05T09:36:14","modified_gmt":"2026-10-05T09:36:14","slug":"what-is-dns-en","status":"publish","type":"post","link":"https:\/\/netloria.com\/en\/blog-en\/what-is-dns-en\/","title":{"rendered":"What Is DNS and Why Your Website Needs It"},"content":{"rendered":"

What Is DNS and Why Your Website Needs It<\/h1>\n

\"Illustration<\/p>\n

You bought a domain, paid for hosting, the designer delivered the mockup \u2014 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.<\/p>\n

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 \u2014 just the way we explain it to clients at Netloria when we connect a new domain for them.<\/p>\n

The simplest explanation: DNS is the internet’s phone book<\/h2>\n

Computers have no idea what “netloria.com” means. They speak in numbers \u2014 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.<\/p>\n

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” \u2014 the IP address of the server where the site lives.<\/p>\n

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.<\/p>\n

What actually happens in the milliseconds before a page loads<\/h2>\n

When you type an address and hit Enter, a small chain of queries unfolds behind the scenes. It looks like this.<\/p>\n

First the browser reaches out to a recursive resolver<\/strong> \u2014 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.<\/p>\n

Next the resolver goes to the root servers<\/strong>. There are only 13 of them worldwide \u2014 labelled with the letters A through M<\/a>, 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.”<\/p>\n

The resolver then queries the TLD server<\/strong> (the top-level domain \u2014 .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<\/strong> for your domain \u2014 the place where all the records actually live. That’s what returns the final IP address.<\/p>\n

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.<\/p>\n

The DNS records you’ll actually run into<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n
Record type<\/th>\nWhat it controls<\/th>\nWhen you touch it<\/th>\n<\/tr>\n
A<\/td>\nPoints the domain to a server’s IPv4 address<\/td>\nMoving the site to new hosting<\/td>\n<\/tr>\n
AAAA<\/td>\nSame, but for the newer IPv6 address<\/td>\nRarely, if the host requires IPv6<\/td>\n<\/tr>\n
CNAME<\/td>\nMakes one domain an alias of another (e.g. www \u2192 main domain)<\/td>\nSetting up a subdomain or connecting an external service<\/td>\n<\/tr>\n
MX<\/td>\nTells the world which server receives mail for the domain<\/td>\nConnecting business email (Google Workspace, etc.)<\/td>\n<\/tr>\n
TXT<\/td>\nArbitrary text: ownership proof, email-protection settings<\/td>\nVerifying the domain, configuring SPF\/DKIM<\/td>\n<\/tr>\n
NS<\/td>\nSpecifies which nameservers manage the domain<\/td>\nMoving DNS management to another provider<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ninety per cent of real situations come down to two records. The A record \u2014 when you need to point the domain at a new server. MX and TXT \u2014 when you set up email on your own domain. The rest, for an ordinary business site, you may not touch for years.<\/p>\n

Nameservers vs records \u2014 where you change what<\/h2>\n

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.<\/p>\n

The first level is nameservers<\/strong>. You set those where you bought the domain \u2014 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 \u2014 it sends everyone to the new “owner” of the zone.<\/p>\n

The second level is the records themselves<\/strong> (A, MX, CNAME\u2026). They live wherever your currently active nameservers are. That could be your registrar, your hosting provider, or a separate DNS service.<\/p>\n

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 \u2014 domain and hosting are usually bought separately<\/a>), goes into the hosting panel, dutifully changes the A record to the right IP \u2014 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.<\/p>\n

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.<\/p>\n

Why DNS changes don’t “work instantly”: propagation and TTL<\/h2>\n

You changed the A record, refreshed the page \u2014 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 \u2014 changes spreading across the world.<\/p>\n

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.<\/p>\n

The standard TTL for an ordinary A record is 86,400 seconds \u2014 a full 24 hours<\/a>. 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<\/a>.<\/p>\n

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\u2013300 seconds \u2014 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.<\/p>\n

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 \u2014 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.<\/p>\n

The mistakes we see most often<\/h2>\n

Years of connecting domains for clients builds up a recognisable list of rakes to step on. Here are the most typical ones \u2014 not abstract, but the ones we genuinely keep running into.<\/p>\n