What is DNS, why is it needed and how does it work

When we search for information on the Internet, we use clear site names like google.com or realhost.pro. But we are the ones who communicate with names, while computers use dry and not very memorable IP addresses like 185.72.159.45 to understand each other.

So that we don't have to keep these thousands of numbers in our heads, mankind invented DNS — a kind of directory or phone book of the internet. We type in the familiar name of the site, and DNS instantly (sometimes intermittently, but more on that later) finds the IP address behind which the desired resource is hiding.

DNS (Domain Name System) is a service that translates domain names into IP addresses that computers can understand. It allows people to use familiar site names instead of fiddling with numbers. DNS is the foundation of the entire Internet. Without it, the browser will say: “404. I don't know where to go".

We propose to deal with it now:

• Where are DNS records stored?
• Who manages it all?
• Why do things often still not work after changing DNS records?
• And what does that mysterious "TTL" mean that suddenly becomes a major problem?

In this article, we'll lay it all out - simply, professionally, with examples, and (we promise) without too much techno-bureaucracy. It's a bit long, but you'll understand exactly what kind of DNS it is.

1. How DNS works: step-by-step

Let's imagine: you open your browser and type example.com. It seems simple - the site opens and you go about your business. But behind the scenes, a little “quest” of several levels unfolds. Here's how it works:

🔴Step 1: The browser asks: “And where is this example.com? ”

The first thing the browser asks the operating system is: "Do you have an IP address for this domain? If the answer is “yes” (in the cache), that's the end of it - the site opens.

🔴Step 2: Not in the cache? Let's move on!"

Then the request is passed to a recursive DNS server - usually an ISP server or Google DNS: 8.8.8.8.8.8.8, 8.8.4.4, Cloudflare DNS: 1.1.1.1.1, 1.0.0.1, OpenDNS: 208.67.222.222, 208.67.220.220.

• Recursive DNS server (or recursive resolver) - responsible for finding a complete answer to a user's DNS query, even if that answer is unknown to the user.
• Why is it "recursive? Because it doesn't stop halfway. It "recurses" (runs through the instances for you) - that is, it follows all the steps until it finds the final answer. You don't need to know exactly what and where it is requested- the user's result is a finished IP address.
• What is all this for?
  • Users don't have to wait: recursive servers usually cache (memorize) the responses so they don't have to repeat the same path the next time.
  • To unload the network: by caching, they reduce the number of calls to "higher" DNS servers.
  • To unify the DNS queries processing, one powerful server can serve many users (e.g. at an ISP or Google DNS).

🔴Step 3. The recursive server is sent to search.

If the DNS resolver itself does not have an answer regarding the desired IP, it starts a chain of lookups:

• A query to root ( . ), i.e., root servers: "Who has information about the top-level domain (.com)?
• Root replies: “refer to TLD-server .com”.
• TLD-server says: “here is a reputable DNS-server responsible for exactly example.com”.
• The resolver goes there and receives an IP address.
• IP comes back to your computer - the site opens.

🕐 It all takes a split second!

🔴Step 4. IP is found, and the information is cached.

The retrieved address is returned to the browser and stored in the cache for a certain time (set via TTL). The browser now knows where to knock if the user requests it again.

🔴Step 5: The connection is established.

The browser finally goes to the IP, establishes a TCP connection (and TLS if HTTPS), and here it is - the site is on the screen.

Briefly about the "heroes" of the IP search for the site:

• Browser/OS ➡ Queries, caches
• Recursive DNS ➡ Search engine: searches for an answer
• Root server ➡ Tells you where to go next
• TLD server ➡ Knows who manages the domain
• Authoritative DNS ➡ Gives the final answer: the IP address

2. Obligatory and not so obligatory: Let's understand the main types of DNS records

DNS records are essentially instructions for DNS servers: they tell you where to send traffic, where to look for mail, which server is the master server, and much more. Here are the most common types:

🔑 The most essential entries: without them — no way:

Without the A/AAAA record, the site just won't open. Without MX - emails won't arrive. Without NS - DNS won't work at all. And without SOA, the servers won't know how often to update the information.

🛠️ Records that will come in handy when configuring or optimizing:

🧙‍♂️ For advanced, DevOps and VoIP fans

💡 Summary: minimum set of records for the site to work correctly:

• A or AAAA - so the browser knows where to go
• CNAME - if you want www to work
• NS - to make DNS work at all
• SOA - for synchronization between DNS servers
• MX - for mail
• TXT - for security and services.

3. DNS zone: where all your domain records live

DNS records don't just float around. They are stored in DNS zones or zone files on authoritative DNS servers. These are simply text files (tables) with structured information about the domain.

📂 What is a DNS zone

DNS zone is the part of the domain space that a particular server is responsible for. It contains all the A, CNAME, MX, TXT, NS, SOA, and other records. For example, an example.com zone could look like this:

This is an example of a so-called zone file. If you are working with BIND, PowerDNS or similar DNS servers, this is what you are dealing with.

💻 But most users see hosting interfaces

Often providers offer simple panels for editing DNS - without having to hand-write these files.

Records are entered in tabs:

• Type→A
• Name → @ or www
• Value→ IP address
• TTL → e.g., 3600 (i.e., 1 hour)

4. Who and where manages DNS records

There are several players involved in running DNS:

1. Domain Registrar

The one you bought the domain from (example.com). This is who determines which NS records are specified for the domain, i.e., to which servers management is delegated.

2. DNS hosting

This is where the DNS records are stored. It can be:

• Hosting provider (on your server).
• A specialized DNS service (Cloudflare, AWS Route 53, Google Cloud DNS).
• Domain registrar (many of them provide DNS as a bonus).

3. Sysadmin or yourself

You can add, modify, or delete records by yourself in case you have access to the DNS panel. But the responsibility is also on you 😅

🧬 Delegation

• You can specify other NS records to delegate control to another platform (e.g., from ns1.registrar.ua → ns1.cloudflare.com).
• You can delegate subdomains (e.g., shop.example.com) to another DNS server for microservices, SaaS, or testing.

5. TTL or why DNS changes don't work instantly

⏱️ What TTL is

TTL (Time To Live) is the amount of time a DNS record is cached:

• You set TTL=3600; the cache will be kept for 1 hour.
• During this time, the servers don't check for a new version of the record - even if you've already changed it.
• It is specified in seconds, so TTL=1 means that an entry can only be cached for 1 second.

💢 Typical situation:

• You changed the A-record to a new IP, the information is correct.
• But the site is still opening the same way for 3 hours.
• You check, panic, call the hoster.
• In fact, it's just that the TTL hasn't worked out yet, so the old version persists.

🧠 Tip on what to do:

• Before making important changes, reduce the TTL (e.g. to 300 seconds).
• Wait until the TTL of old entries "burnout" and all caches are updated.
• Then make the change, it will be applied quickly.

📌 Recommended minimum:

If you need very fast DNS updates (for example, during a site migration), set the TTL in the range of 30–300 seconds:

• 30 - for short-term critical changes
• 300 (5 minutes) - for most technical tasks

6. DNS cache is your friend and foe at the same time

Cache is a good thing. But when you make changes, it becomes your enemy.

📦 Where exactly the DNS cache is stored:

• Operating system: Windows, macOS, Linux - keep DNS records in memory.
• Browsers: Chrome, Firefox have their own DNS cache (independent of OS).
• Recursive DNS servers (ISP or Google DNS) - cache records according to TTL.
• CDNs or proxies (Cloudflare, Sucuri, Akamai) - have their own levels of caching.

🤦🤦‍♂️ What does this mean in practice?

• You've changed the A-record, but your friend in Germany is still getting the old version of the site, because his DNS server hasn't been updated yet.
• You check via VPN, and see a different one.
• And so on to infinity/

In this case, clearing the cache will help.

7. How to clear DNS cache (for all systems)

On the computer:

📌 Windows:

🍏 macOS

Depends on macOS version, macOS 10.11 and newer (inclusive with macOS Sonoma):

After entering it, you will have to enter the administrator password. This command clears the cache and restarts the DNS service

🐧 Linux

Cache clearing depends on which resolver is being used.

If using systemd-resolved (often in Ubuntu):

If nscd is used:

If using dnsmasq:

🌐 Browsers (local DNS cache)

Chrome

Type in the address bar:

And click “Clear host cache”.

Firefox:

Close and open the browser, or restart in safe mode.

8. DNS rake: what sysadmins step on most often

Typical mistakes when working with DNS:

1. TTL is too big — you set it to 86400 (24 hours) and you want to check for changes in 5 minutes.
2. CNAME for root domain — it doesn't work there! For example.com use A/AAAA.
3. Forget to save or click “Apply” — and think that “nothing works”.
4. Changed IP — but didn't update the DNS record.
5. Errors in TXT records (especially in SPF - one extra quote can “kill” the entire email).
6. DNSSEC enabled - and keys not configured— site becomes inaccessible.

9. Important points when working with DNS: sysadmin tips

• 🧠 Scheduling TTL before migrations.
• 🔐 DNSSEC - to protect against record spoofing (but only with proper configuration!).
• ⚡ Reliable DNS servers - Google (8.8.8.8.8.8.8.8), Cloudflare (1.1.1.1.1), OpenDNS.
• 🔍 Checking via online tools:
  • dnschecker.org
  • dig, nslookup, host in terminal
  • mxtoolbox.com

10. Conclusion: without DNS, there's nothing

DNS is like logistics for websites: imperceptible while everything is working. And catastrophic when things go wrong.

🎯 Remember:

• Check the TTL before making changes.
• Don't forget the cache.
• Use proven tools.
• And treat DNS with respect - it's your first (and often the only) way to get to the user.

And also, always have a dig, dnschecker and nerves of steel on hand. In the words of sysadmins, “Real DevOps cleans the DNS cache first, and then checks everything else.”