What Is DNS: How It Works and Why You Need It, Explained

In short. DNS (Domain Name System) is the distributed system that turns a site name into a server IP address. Your browser asks a resolver, which walks the chain of root, TLD and authoritative servers for the domain, gets the address and caches the answer. Without DNS you would reach sites by numbers only, and moving to a new server would break every link pointing at you.

What is DNS in simple terms

You type enterno.io, but the connection is still made to a number such as 81.163.20.249. Routers and switches can only deliver packets to IP addresses — names mean nothing to them. DNS sits exactly between those two worlds: it takes a name and returns an address.

DNS stands for Domain Name System. The founding documents are RFC 1034 (concepts) and RFC 1035 (message format), both over thirty years old. Encryption, signatures and dozens of record types were added since, but the lookup mechanics never changed.

Why the phone book analogy lies to you

Nearly every DNS explainer opens with "it is the phone book of the internet". The analogy is honest in exactly one respect: both map a name to a number. Everything after that is misleading — and it misleads precisely where sites break.

• There is no single book. No server holds a complete list of the world's domains. The data is split across levels: the root knows who runs the io zone; the io servers know who runs enterno.io; only those last servers know the address itself. It is a chain of referrals, not a book.
• Answers go stale. A printed book always shows what was printed. DNS shows whatever a particular resolver happened to cache — sometimes an address that no longer exists.
• One name, different answers. A person has one phone number, but a large site can resolve to different IPs for a visitor in London and one in Singapore. That is how CDNs, geo-balancing and split-horizon DNS work.
• DNS holds more than addresses. It also carries mail routing (MX), domain ownership proofs and anti-spam policy (TXT), service locations (SRV) and certificate authority constraints (CAA). No phone book does that.
• Reverse lookup is a separate system. You cannot look up a name by number in a printed book, and DNS does not do it for free either: that is what PTR records in the separate in-addr.arpa tree are for. See the guide to reverse DNS and PTR records.

A more accurate analogy is a directory service that delegates. You call the one number you know. They do not have the answer, but they know exactly who handles that region and give you their number. Those people know who handles the specific organisation. Only the third call returns a result. And every participant writes down what they heard and answers from that note for the next few minutes instead of calling again.

The defining property of DNS is not lookup, it is delegation. The operator of the io zone does not store your site's address — only a pointer to the servers that do. That is why you can change records without asking anyone, and equally why one broken delegation takes the whole domain offline.

Why DNS is needed and what would happen without it

DNS solves four problems, and only the first one is obvious.

1. Human readability. A name can be dictated over the phone, printed on a card and remembered. An IPv6 address like 2001:db8:85a3::8a2e:370:7334 cannot.
2. Decoupling the name from the hardware. The server moves to a different host, the IP changes — you edit one A record and every link, bookmark and external integration keeps working. Without DNS a migration would mean emailing a new address to everyone who links to you.
3. Load distribution and failover. One name can point at several addresses, and the answer can depend on the client's region or the health of a site. CDNs and DNS failover are built on this.
4. Domain metadata. Where mail should be delivered, which certificate authorities may issue for the domain, which services own it — all of that lives in DNS and is checked by automation without a human in the loop.

What a DNS failure looks like is easy to recognise: the site is "not found" while the server is perfectly alive, mail stops arriving, a certificate fails to renew. DNS is the single choke point every inbound request passes through, which is why it produces such an outsized share of domain incidents.

What a DNS server is and which kinds exist

At least five different things are called "a DNS server", and confusing them causes half of all failed diagnostics. Split them by role.

Stub resolver: the client inside your device

Code in the operating system — and increasingly in the browser itself — that takes a name from an application and returns an address. It searches for nothing on its own: it holds a list of one or two servers to ask, handed out by the router over DHCP or configured manually. A stub resolver keeps a small cache of its own, which is why "the browser shows the old address but the terminal shows the new one" is completely normal.

Recursive resolver: the one doing the actual work

Run by your ISP, your router or a public operator (see the roundup of the best public DNS servers). This is the component that walks the hierarchy top-down, assembles an answer and keeps a large cache shared across all of its users. From your site's point of view it is the most important participant: its cache decides how fast the world sees your changes.

Root servers: 13 names, not 13 machines

The top of the hierarchy. There are exactly thirteen of them — but thirteen names, from a.root-servers.net to m.root-servers.net. This is the most repeated mistake in DNS explainers: "there are only 13 root servers in the world, and if you switch them off the internet dies".

Behind those thirteen names sit well over a thousand physical sites around the world, and the count keeps growing. It works through anycast: the same IP address is announced from dozens of locations, and a query lands on whichever one is closest by network metrics. The limit of 13 names is historical — the root list had to fit into a single 512-byte UDP message, the size defined in RFC 1035. The mechanics of announcing one address from many places are covered in the article on anycast DNS.

Do not repeat "the internet has 13 root servers". The accurate statement is: 13 root names, backed by thousands of anycast nodes and operated by twelve independent organisations. That is exactly why the root is so hard to kill — there is no single box to switch off.

TLD servers: keepers of the top-level zone

They are responsible for com, org, io, de and every other ending. They do not know your site's address either — only the names of the servers your zone is delegated to. That data reaches them from your registrar when you set the NS records in the domain panel.

Authoritative servers: the single source of truth

This is where your zone physically lives: A, AAAA, MX, TXT and everything else. Whatever is written here is the truth; every other participant only passes around copies with an expiry date. Usually these are servers run by a DNS host, a registrar or a cloud provider. A full role-by-role comparison lives in the article on types of DNS servers.

Participant	What it stores	Who it asks	Does it cache
Stub resolver (OS, browser)	Nothing of its own	One configured resolver	Yes, small and short-lived
Recursive resolver	Other people's answers	Root then TLD then authoritative	Yes, large and shared
Root server	Who runs each TLD	Nobody	No
TLD server	NS records of zone domains	Nobody	No
Authoritative server	The zone itself	Nobody	No, it is the source

What happens between typing an address and the page opening

Here is the full path. Assume every cache is empty — the worst and most instructive case.

1. The browser and OS look locally. The browser's internal cache, the stub resolver cache and the hosts file are checked. If the answer is there, nothing touches the network at all.
2. The query goes to a recursive resolver. Normally UDP on port 53. The client asks: "give me the A record for enterno.io, you figure out how" — the recursion-desired flag is set.
3. The resolver asks the root. The root does not know the answer and returns a referral: "the io zone is handled by these servers".
4. The resolver asks the TLD. The io servers do not know the address either, but they know the delegation: "enterno.io lives on dns1.yandex.net and dns2.yandex.net".
5. The resolver asks the authoritative server. That one answers on the merits: the A record and its TTL.
6. The resolver caches and replies. The answer is flagged non-authoritative: it is a copy, not the original.
7. The browser opens a TCP connection to that IP, then the TLS handshake and HTTP request follow. None of that is DNS any more.

You can watch the whole chain yourself. The +trace flag disables recursion and makes dig walk the hierarchy itself, printing every step:

dig +trace enterno.io A

.            80131  IN  NS  a.root-servers.net.
...
;; Received 525 bytes from 188.93.17.19#53(188.93.17.19) in 0 ms

io.          172800 IN  NS  a0.nic.io.
io.          172800 IN  NS  b0.nic.io.
;; Received 650 bytes from 192.5.5.241#53(f.root-servers.net) in 0 ms

enterno.io.  3600   IN  NS  dns1.yandex.net.
enterno.io.  3600   IN  NS  dns2.yandex.net.
;; Received 572 bytes from 65.22.160.17#53(a0.nic.io) in 45 ms

enterno.io.  3600   IN  A   81.163.20.249
;; Received 103 bytes from 93.158.134.213#53(dns2.yandex.net) in 7 ms

Four blocks, four steps: root, the io zone, the delegation, the answer. Note the Received ... from line closing each block — it names exactly who replied. If +trace stops halfway, you have located the level where delegation is broken.

Why DNS caching exists and why changes are not visible immediately

If every query walked the full hierarchy, root and TLD servers would drown within the hour. Caching prevents that: the overwhelming majority of answers come out of the nearest resolver's memory in single-digit milliseconds.

You can time the difference. The first query reaches the authoritative server; the second comes from cache, and the TTL in the answer has already started counting down:

# cold query — the resolver walks the hierarchy
dig iana.org A | grep -E "^iana|Query time"
iana.org.  3600  IN  A  192.0.43.8
;; Query time: 170 msec

# same query a few seconds later — served from cache
dig iana.org A | grep -E "^iana|Query time"
iana.org.  3592  IN  A  192.0.43.8
;; Query time: 0 msec

TTL (Time To Live) is the number of seconds an answer may be stored. Above, 3600 means one hour, and 3592 shows how much is left. When it hits zero the resolver goes back for fresh data.

Hence the practical conclusion: you do not control other people's caches. Editing an A record changes it on your authoritative server instantly — but every resolver in the world holding the old answer keeps serving it until its own TTL expires. On top of that, the visitor's browser and operating system cache separately.

"Changes take effect within 24 to 72 hours" is not a rule and not a guarantee. It is legacy registrar boilerplate. The real window is set by your TTL, and individual resolvers may hold a record longer than advertised or refresh within a minute. If a migration is planned, lower the TTL in advance — longer ahead than the current TTL — and raise it again afterwards.

Negative answers are cached too. When a name does not exist, the authoritative server returns NXDOMAIN together with an SOA record whose last field sets how long that "does not exist" verdict may be stored. That is why a freshly created record can be invisible even though you did everything right:

dig +noall +authority no-such-host-zz1.enterno.io A
enterno.io.  95  IN  SOA  dns1.yandex.net. dns-hosting.yandex.ru. 36 900 90 86400 900

The last number (900) is the negative TTL: for fifteen minutes the resolver will remember that the name does not exist. How to pick TTL values for different situations is covered in the guide to DNS record TTL, and what updates in which order during an address change is in the article on DNS propagation.

What private DNS is: Private DNS, DoH and DoT

Classic DNS travels in clear text over UDP port 53. Anyone on the path — your ISP, the owner of the Wi-Fi, a transit operator — can see which sites you look up and can rewrite the answer. Encryption closes both problems.

Android's Private DNS is DoT

The "Private DNS" setting on Android enables DNS over TLS: the same DNS, wrapped in a TLS tunnel on port 853. In hostname mode you enter the resolver's domain name and the system validates its certificate — so it also confirms it is talking to the right operator. The specification is RFC 7858.

You can verify that a resolver really listens on 853 and presents a valid certificate:

echo | openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com 2>/dev/null \
  | grep -E "subject=|Verify return code"

subject=C=US, ST=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com
Verify return code: 0 (ok)

DoH: DNS inside HTTPS

DNS over HTTPS (RFC 8484) wraps queries in ordinary HTTPS on port 443, where they are indistinguishable from the rest of your web traffic. This is what browsers with a built-in resolver use. Many DoH providers also expose a JSON variant that is convenient from a terminal:

curl -s -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=enterno.io&type=A"

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,
 "Question":[{"name":"enterno.io","type":1}],
 "Answer":[{"name":"enterno.io","type":1,"TTL":3600,"data":"81.163.20.249"}]}

Variant	Transport	Port	Visible to observers	Where it is enabled
Classic DNS (Do53)	UDP, TCP for large answers	53	Names visible, answers can be rewritten	The default everywhere
DoT	TLS	853	Hidden, but the port reveals that DNS is in use	Android Private DNS, systemd-resolved, routers
DoH	HTTPS	443	Hidden and blended into normal web traffic	Browsers, operating systems, apps

Encryption hides the query from intermediaries but does not make the answer trustworthy: you are moving trust from your ISP to the resolver operator you picked. Authenticity of the data itself is a different technology — DNSSEC, cryptographic signing of the zone. DoH and DNSSEC solve different problems and do not replace each other.

The practical side — which providers exist, what privacy costs and how encrypted DNS interacts with corporate filtering — is covered in the article on DNS over HTTPS. Changing the resolver on a device or router is walked through in how to change your DNS server.

How to check what DNS returns for your domain

Three command-line tools cover nearly every question. dig is the main one — precise and verbose; nslookup is everywhere, including Windows; host is handy for a quick check.

# the address, short form
dig +short enterno.io A

# answer with TTL and record type
dig +noall +answer enterno.io A
enterno.io.  3245  IN  A  81.163.20.249

# who is authoritative for the zone
dig +short NS enterno.io
dns1.yandex.net.
dns2.yandex.net.

# ask the authoritative server directly, bypassing every cache
dig +noall +answer +norecurse @dns1.yandex.net enterno.io A
enterno.io.  3600  IN  A  81.163.20.249

# compare what a specific public resolver returns
dig +short enterno.io A @8.8.8.8

# the same through nslookup and host
nslookup -type=NS enterno.io 1.1.1.1
host -t A enterno.io

The +norecurse trick with an explicit server is the key diagnostic move: it shows the truth with no intermediaries. If the authoritative server returns the new address while a public resolver returns the old one, the case is closed — it is caching, wait out the TTL. If the authoritative server returns the old value, the edit simply never saved.

Looking at several resolvers at once is easier in a browser:

• DNS Lookup — every record for a domain at once: A, AAAA, MX, NS, TXT, CNAME, SOA, with TTLs.
• DNS propagation check — what resolvers in different countries see right now; the fastest way to tell whether a change has spread.
• Single record check — when you need one type and its exact value.
• WHOIS — which NS are set at the registrar level; a mismatch with the NS inside the zone is a classic cause of "it works sometimes".
• MX Lookup and mail record check — when it is mail that broke rather than the website.
• Monitoring — watches your DNS records and warns you when they change without your knowledge or the zone stops answering.

Common DNS errors and what they mean

The response status appears in the dig header under status:, and it narrows the suspect list immediately.

What you see	What it means	Where to look
status: NOERROR with ANSWER: 0	The name exists, that record type does not	You asked for A but only AAAA or a CNAME is configured
status: NXDOMAIN	The name does not exist	Typo, record never saved, domain expired
status: SERVFAIL	The resolver could not obtain an answer	Authoritative servers unreachable, broken delegation, DNSSEC validation failure
status: REFUSED	The server declined to answer	Wrong server: it is not authoritative for the zone and will not recurse for you
connection timed out; no servers could be reached	Packets never arrived	UDP/53 filtering, network issues, wrong resolver address

One especially treacherous case is a mismatch between the NS at the registrar and the NS inside the zone. Resolvers follow the delegation from the TLD, so edits made on a set of servers that is not delegated are invisible to everyone, even though the panel shows them saved. Compare two answers: dig +short NS yourdomain (what the world sees) against the NS list in the registrar panel. A symptom-by-symptom walkthrough is in why DNS is not resolving.

Before changing anything else, answer one question: is the authoritative server already returning the correct answer? If yes, everything that remains is time and other people's caches, and further edits only make the path longer. If no, flushing caches is pointless — fix the zone.

What to know about zone records

Every DNS answer is a record of a specific type. The minimum set almost every domain has:

• A — an IPv4 address. AAAA — an IPv6 address.
• CNAME — an alias meaning "ask about this other name instead". For www.github.com the resolver first receives a CNAME, then fetches the target's address: www.github.com. CNAME github.com. then github.com. A 140.82.121.4.
• NS — who is authoritative for the zone. SOA — zone parameters, including the negative TTL.
• MX — where mail for the domain should be delivered.
• TXT — free-form text: SPF, DKIM, DMARC, ownership verification.
• CAA — which certificate authorities may issue certificates for the domain.

A full breakdown with example values and typical mistakes is in the DNS records guide. If you are still figuring out domains in general, start with what a domain is.

Frequently asked questions

What is a DNS server in simple terms?

A machine that answers the question "what address does this name have". But the roles differ: an authoritative server stores your zone and speaks the truth, while a recursive resolver hunts the answer down through the hierarchy and caches it for its users. The one you configure on a device is always a recursive resolver.

How many DNS servers are there in the world?

There is no exact number: every host and large company runs authoritative servers, and recursive ones sit at ISPs and inside routers. Only the count of root names is fixed — thirteen, from a to m, backed by thousands of physical anycast nodes.

What is private DNS and should I turn it on?

It is encryption for DNS queries: on Android the "Private DNS" setting enables DNS over TLS, while browsers more often use DNS over HTTPS. Turning it on is worth it when you use untrusted or public networks — the owner of the access point can no longer see or rewrite your lookups. On a corporate network, check with the administrator first: encrypted DNS bypassing the internal resolver breaks access to internal names.

Why does my site still open at the old address after a DNS change?

The answer is cached — in your browser, your operating system or your ISP's resolver — and will keep being served until the TTL expires. Check the truth directly at the authoritative server with dig +norecurse @your-ns yourdomain A: if the new value is there, all that remains is waiting. There is no guaranteed timeframe, only your TTL.

Does DNS affect site speed?

Yes, but not where people usually look. Resolution happens once before the connection and normally takes single or double-digit milliseconds; from cache it costs almost nothing. Noticeable delay appears when authoritative servers are far away or slow to answer and the page pulls resources from several different domains — each new domain costs its own lookup. Measuring the overall effect is easiest through the speed test.

How is DNS different from hosting?

DNS answers "where", hosting answers "what". DNS only reports the server's address; the site itself lives and runs on the hosting. So a site can be perfectly alive but unreachable because of DNS, and the reverse — DNS answers correctly while nothing is served at that address.

Checklist: your domain's DNS is healthy

• The NS in your registrar panel match what dig +short NS yourdomain returns.
• There are at least two authoritative servers, and they sit in different networks.
• dig +trace yourdomain A completes all four steps without stopping.
• A and AAAA records point at a live server, not at an address from a previous host.
• TTL values make sense: short ahead of a planned migration, normal the rest of the time.
• MX and TXT records (SPF, DKIM, DMARC) are in place if the domain sends or receives mail.
• A CAA record is set if you want to restrict which authorities can issue certificates.
• The authoritative server and public resolvers return the same answers.
• The domain and zone are under monitoring, so record changes and zone outages surface immediately instead of through user complaints.