What Is DNS? How the Domain Name System Works

DNS (Domain Name System) is the internet's address book. It translates human-friendly names like `olladns.com` into the numeric IP addresses computers use to find each other. Every time you open a browser tab, DNS runs a lightning-fast relay through resolvers, root servers, TLD servers, and authoritative servers, usually finishing in under 100 milliseconds. Because almost nothing on the internet happens without a DNS lookup first, DNS is also one of the earliest, cheapest places to stop phishing, malware, and command-and-control traffic before it reaches a device.

• Foundational & Fast: DNS is the internet's invisible address book, translating names to numbers via an elegantly delegated hierarchy in milliseconds.
• Earliest Intervention: Because a DNS lookup happens before almost anything else on a network, it is a high-leverage chokepoint for catching trouble.
• Stops Threats Pre-Connection: It can block phishing sites, command-and-control callbacks, and lookalike domains before a device even connects.
• Crucial Context: Understanding the mechanics of DNS is the essential foundation for grasping why DNS-layer security exists in the first place.
• Simple & Effective: Implementing DNS security controls tends to be one of the simplest, fastest, and most quietly effective strategies a security team can deploy.

The problem DNS was invented to solve As organizations scale, solutions like OllaDNS provide essential visibility and protection at this layer.

Origin Story

~1970s

The HOSTS.TXT Era

Computers do not talk to each other using names. They use IP addresses — strings like 172.217.14.206 — that tell routers exactly where to send data. That addressing system is precise, but humans are not built to memorize dotted strings of numbers.

~1980s

ARPANET Hits a Wall

In the early days of ARPANET, engineers maintained a single text file called HOSTS.TXT that mapped every machine’s name to its number. Every computer periodically downloaded a fresh copy from a single machine at Stanford Research Institute. That approach worked for a few hundred hosts but collapsed at internet scale.

1983

DNS is Born

In 1983, Paul Mockapetris proposed a distributed, hierarchical naming system where responsibility for different parts of the namespace could be delegated across many servers. That proposal became the Domain Name System. Four decades later, it is still the same structure, resolving hundreds of billions of queries a day.

02

What is DNS?

At its simplest, DNS is a distributed directory service that maps human-readable domain names to the IP addresses computers use to route traffic. Type olladns.com into a browser, and DNS quietly answers the question “where, numerically, is that?” so your browser knows which server to connect to.

The phonebook analogy is apt but incomplete. DNS does more than name-to-number lookups. It tells the internet where to deliver your email (via MX records), which servers can send mail on your behalf (via SPF and DKIM in TXT records), and how to route subdomains (via NS records). It can also let one domain point to another without touching the destination server (via CNAME records). DNS is not just an address book — it is a full directory and routing layer for how the internet finds anything at all.

03

Breaking down a domain name

Domain names are read from right to left, in the same order DNS processes them.

Take blog.olladns.com:

.com

Top-level domain, or TLD. TLDs include .com, .org, .net, .gov, country codes like .in and .uk, and newer options like .dev and .security. Registries manage TLDs, and ICANN coordinates the global namespace.

olladns

Second-level domain. This is the part a business or individual registers through a domain registrar and carries the brand identity.

blog

Is a subdomain. The domain owner controls subdomains without additional registration. Companies use them constantly to separate services: mail.company.com, [api](https://olladns.com/developers.html "olladns Developer API").company.com, vpn.company.com.

This layered delegation is what makes DNS scale. Responsibility flows downward — ICANN and registries handle TLDs, registrars and owners handle second-level domains, and owners handle their own subdomains.

04

Following one lookup, start to finish

DNS resolution feels like magic until you walk through it. Then it feels like a relay race.

That is five separate servers cooperating across potentially five physical locations, usually completing in well under 100 milliseconds.

Two query styles are at work here. Your device’s query to the resolver is recursive — it expects a complete final answer. The resolver’s queries to the root, TLD, and authoritative servers are iterative — each server may respond with “I don’t know, but here’s who to ask next.” That division is deliberate. It keeps the root and TLD servers, which handle staggering global traffic, from doing the heavy lifting of full recursive lookups themselves.

Step one: local cache check

Your device checks whether it already knows the answer — first in the browser’s DNS cache, then in the operating system’s resolver cache. If you or someone on your network visited the domain recently, the answer may already be stored locally, and the rest of the process is skipped.

↓

Step two: recursive resolver

If nothing is cached locally, the query is handed to a recursive resolver — a server whose job is to find the answer and bring it back. This might be your ISP’s resolver, a public resolver like Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8, or a protective DNS resolver. Think of the recursive resolver as a determined assistant: you give it one question, and it does the legwork until it returns a final answer.

↓

Step three: root server

If the recursive resolver does not have the answer cached, it starts at the top of the hierarchy by querying a root server. There are only 13 root server addresses globally, though anycast routing means those addresses are served by hundreds of physical machines worldwide. The root server does not know where olladns.com lives. It only knows which server is responsible for the .com TLD, and it points the resolver there.

↓

Step four: TLD server

The resolver now asks the .com TLD server. The TLD server also does not know the final answer, but it knows which name servers are authoritative for olladns.com because that information was registered when the domain was set up. It returns that referral.

↓

Step five: authoritative name server

The resolver goes directly to the authoritative name server for olladns.com, typically run by the domain’s DNS hosting provider. This server holds the actual DNS records and responds with the real IP address.

↓

Step six: the answer returns

The recursive resolver hands the IP address back to your device. Your browser opens a connection to that address, and the page starts loading. Your device also caches the answer so the next lookup can skip some of these steps.

05

Why caching makes the internet faster

If every DNS lookup ran that full relay from scratch, the internet would feel slower and the root and TLD servers would crumble under the load. Caching prevents that.

Every DNS record carries a Time to Live (TTL) — a number in seconds that tells resolvers and devices how long they may reuse a cached answer before asking again. Typical TTLs range from one hour (3,600 seconds) to one day (86,400 seconds), depending on how often the domain owner expects the record to change.

Caching means popular domains get looked up once by a resolver and then served instantly from memory to everyone else who asks during that window. It dramatically reduces load on authoritative servers and cuts real time off page loads.

TTL also matters whenever something changes. If a company migrates its website to a new server and updates its DNS record, that change propagates gradually as cached copies expire. This is why IT teams talk about “DNS propagation” taking anywhere from minutes to, in edge cases, a couple of days. Lowering a record’s TTL before a planned migration shrinks the propagation window when you need it smallest.

06

The record types that make DNS work

A domain’s DNS configuration is a collection of records, each answering a narrow question.

A record

example.com. 3600 IN A ...

A record

Maps a domain to an IPv4 address.

AAAA record

example.com. 3600 IN A ...

AAAA record

Maps a domain to an IPv6 address, the newer address format the internet is migrating toward as IPv4’s roughly 4.3 billion addresses run short.

CNAME record

example.com. 3600 IN A ...

CNAME record

Points a domain to another domain name instead of an IP. This lets shop.company.com quietly point to a third-party e-commerce platform without anyone needing to update that platform’s real IP address.

MX record

example.com. 3600 IN A ...

MX record

Mail Exchange record. Tells the internet which mail server accepts email for a domain, with priority values so a primary and backups can be listed.

TXT record

example.com. 3600 IN A ...

TXT record

Originally a general-purpose text field, now heavily used for security. SPF records list authorized mail servers, DKIM records hold public keys for email authentication, and DMARC records tell receiving servers what to do when authentication fails.

NS record

example.com. 3600 IN A ...

NS record

Name Server record. Identifies which servers are authoritative for a domain.

SOA record

example.com. 3600 IN A ...

SOA record

Start of Authority record. Sits at the top of every DNS zone and holds administrative metadata, including the primary source of truth server and timing values that control how secondary servers refresh their copies.

PTR record

example.com. 3600 IN A ...

PTR record

Pointer record. Used for reverse DNS — mapping an IP address back to a domain name. Especially useful for verifying mail server legitimacy.

SRV record

example.com. 3600 IN A ...

SRV record

Service record. Locates specific services, such as SIP or XMPP, by hostname and port.

CAA record

example.com. 3600 IN A ...

CAA record

Certificate Authority Authorization record. Specifies which certificate authorities are allowed to issue TLS certificates for the domain.

A, AAAA, CNAME, MX, TXT, NS, and SOA cover the overwhelming majority of day-to-day domain operations. PTR, SRV, and CAA matter in more specialized cases.

07

Who runs the resolvers you use

Every device needs a recursive resolver, and where it comes from matters.

ISP Resolvers

It requires no configuration, but the ISP can see every domain looked up, and there is usually no filtering or security inspection.

Public Resolvers

Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and Quad9’s 9.9.9.9 are free, fast thanks to anycast infrastructure, and often advertise stronger privacy commitments than ISP resolvers. Some, like Quad9, also apply built-in threat-intelligence filtering.

Protective Resolvers (olladns)

Then there is the category that matters most in business: protective DNS resolvers, the category olladns operates in. These sit deliberately in the resolution path and treat every DNS query as a checkpoint. Because virtually nothing on a network happens without a DNS lookup — not a phishing page loading, not malware phoning home, not a browser being redirected to a lookalike login — that checkpoint is an efficient place to catch bad activity before any malicious payload reaches the device.

08

DNS as an attack surface

DNS was designed in the early 1980s for a smaller, more trusting internet. Security was not the top priority. That history still has consequences.

DNS cache poisoning is one of the oldest attacks. An attacker forges a fake DNS response and tries to slip it into a resolver’s cache before the legitimate answer arrives. If it succeeds, everyone who queries that resolver is sent to the attacker’s server instead of the real one — for banking, webmail, anything — with no obvious warning. The browser’s padlock icon does not help, because from the browser’s perspective it is simply connecting to whatever address DNS provided.

DNS hijacking operates one level up. Rather than poisoning a single resolver’s cache, an attacker compromises the actual DNS settings for a domain or the router settings on a network, redirecting traffic structurally for a longer window before anyone notices.

DNS tunneling is used by attackers who already have a foothold inside a network. Because DNS traffic is routine and rarely inspected closely, attackers encode stolen data inside DNS queries themselves and quietly exfiltrate it, or use a steady drip of DNS lookups as a covert command-and-control channel. To a casual observer, it looks like ordinary DNS traffic.

Typosquatting and lookalike domains rely less on technical cleverness and more on human pattern matching. Attackers register domains like oll4dns.com or amaz0n-support.com, close enough that a tired employee glances at them and misses the difference before clicking. This is overwhelmingly how modern phishing campaigns get started.

The unifying operational fact is simple: DNS is the first network event in almost every attack chain. Before malware phones home, before a phishing page loads, before data leaves a network — there is a DNS query. DNS is not just infrastructure that needs protection; it is one of the earliest, cheapest, highest-leverage places to stop an attack.

09

Encrypting DNS: DoH, DoT, and DoQ

For most of DNS history, queries traveled in plain text. Anyone positioned on the network path could see which domains were being looked up, and in some cases tamper with responses. Three newer protocols close that gap.

Protocol

DNS over HTTPS (DoH)

wraps DNS queries inside standard encrypted HTTPS traffic, the same protocol used for secure web browsing. The practical effect is that DNS traffic becomes very hard to distinguish from ordinary web traffic on the wire.

Protocol

DNS over TLS (DoT)

also encrypts queries using TLS, but keeps them on a dedicated port rather than blending in with HTTPS. This makes it easier for network administrators to identify and manage DNS traffic deliberately.

Protocol

DNS over QUIC (DoQ)

is the newest option, built on Google’s QUIC transport. It combines encryption with faster connection setup and better performance on unreliable, high-latency mobile networks.

Encryption matters for privacy — it stops casual eavesdropping on browsing habits. But it also creates a real tension for enterprise security: encrypted DNS can make it harder for protective tooling to inspect and filter queries centrally, because standard DoH traffic blends invisibly into encrypted web browsing. Modern protective DNS platforms solve this by natively supporting DoH, DoT, and DoQ themselves. The goal is not to fight encryption; it is to be the trusted, encrypted resolver that devices and managed clients are deliberately pointed at.

10

DNS as a security layer, not just plumbing

DNS sits before almost everything else on a network.

A firewall inspects traffic once a connection is underway. Endpoint protection inspects files once they have landed. An email gateway inspects a message once it has arrived. DNS, by contrast, is consulted before any of that — before the connection opens, before the file downloads, before the phishing page renders.

That timing makes DNS-layer security efficient. A protective resolver can refuse to resolve a known-malicious or suspicious domain, stopping the connection before it opens. It is a low-friction control: point a network or fleet at a protective resolver and every device is covered, with nothing to install and no behavior change required.

11

When DNS breaks

DNS failures are deceptive because they tend to look like something else.

A misconfigured DNS record can take a healthy website offline even though the server never went down. A DNS provider outage can knock out every domain that provider hosts at once. An expired domain registration can silently break a domain the moment it lapses. Redundancy across providers and careful renewal discipline are standard defenses.

The common thread is that DNS problems rarely announce themselves as DNS problems. Users report “the website is down” or “I cannot get email.” Diagnosing the real cause usually means checking DNS resolution directly with dig or nslookup, or a web-based DNS checker, before blaming a server, hosting provider, or application.

12

Where DNS is heading

DNS is still fundamentally the same protocol Paul Mockapetris designed in 1983, but the layers built on it keep evolving. Encrypted DNS through DoH, DoT, and DoQ is becoming the default. DNSSEC is gaining adoption, adding cryptographic signing so resolvers can verify an answer came from the real authoritative source. Multi-signal protective DNS — combining real-time threat intelligence, domain-age signals, and behavioral detection — is becoming baseline for security-conscious organizations. And as more life moves through screenless connected devices, DNS remains the quiet mechanism figuring out where it all should connect.

13

DNS myths worth retiring

A few misconceptions circulate constantly. Clearing them up helps the whole picture click into place.

DNS is just for websites.

It never was. Email routing, certificate validation, load balancing, content delivery networks, VoIP setup, even the way your phone finds the nearest game server — all depend on DNS somewhere.

Changing DNS settings is risky and technical.

For most people, changing which resolver a device or router uses is one of the lowest-risk, highest-impact changes available. It is a setting, not a rebuild.

HTTPS means I am safe, DNS does not matter.

The padlock confirms that a connection is encrypted. It says nothing about whether the server is the legitimate one you meant to reach. A phishing site behind a valid HTTPS certificate is trivially easy to set up, and DNS decides which server you connect to before that padlock appears.

DNS outages are rare, so planning is unnecessary.

Because so much infrastructure depends on DNS resolving correctly, a DNS failure tends to cascade sideways faster than expected.

My ISP’s default DNS is basically the same as anything else.

Default ISP resolvers typically apply no security filtering, may log queries for advertising purposes, and were not designed with protective inspection in mind.

14

A troubleshooting toolkit

When something DNS-shaped goes wrong, a small set of everyday tools does almost all the diagnostic work.

Use dig or nslookup to query a specific DNS record directly and see what is being returned right now. Run a lookup against a specific resolver to check whether a change has propagated in one place but not another. Lower TTL values a day or two before a migration to shrink the propagation window. Use online propagation checkers to see whether an update has reached resolvers worldwide or whether some still hold stale cached answers. If you suspect unauthorized changes, check DNS settings at the registrar level directly — that is where core configuration changes are made.

15

Frequently Asked Questions

What is DNS in simple terms? +

DNS (Domain Name System) is the internet’s address book. It translates human-friendly domain names like olladns.com into the numeric IP addresses computers use to find and connect to each other.

What is a DNS server? +

A DNS server stores or looks up DNS records. Recursive resolvers, root servers, TLD servers, and authoritative name servers each play different roles in answering a lookup.

What is the difference between DNS and an IP address? +

An IP address is the actual numeric location of a device on the internet. DNS maps a human-readable name to that IP address so people do not have to memorize numbers.

What is a DNS resolver? +

A DNS resolver, also called a recursive resolver, receives your device’s query and does the work of tracking down the final answer, checking root, TLD, and authoritative servers as needed.

What are the main types of DNS records? +

The most common are A (IPv4 address), AAAA (IPv6 address), CNAME (alias to another domain), MX (email routing), TXT (text data, often SPF/DKIM/DMARC), NS (authoritative name servers), and SOA (administrative zone info).

What is DNS caching and why does it matter? +

Caching lets resolvers and devices temporarily store a DNS answer based on a record’s TTL, instead of looking it up fresh every time. It is why the internet feels fast — most lookups are served from memory rather than running the full resolution chain.

What is DNS propagation and how long does it take? +

Propagation is the time it takes a DNS change to reach every resolver worldwide, since each refreshes its cached copy only after the TTL expires. It typically takes a few minutes to 24–48 hours.

What is DNS cache poisoning? +

An attacker sneaks a fake DNS response into a resolver’s cache, redirecting users to a malicious server instead of the real one — often without any visible warning.

What is DNS hijacking? +

DNS hijacking happens when an attacker alters a domain’s actual DNS settings or a network’s router configuration to redirect traffic maliciously, usually for a longer window than a single poisoned cache entry.

Is DNS a security risk? +

DNS itself is not inherently risky, but because nearly every online action starts with a DNS lookup, it is a common target and one of the earliest points where phishing, malware callbacks, and lookalike domains can be caught.

Can DNS be used for security protection? +

Yes. Protective DNS resolvers inspect and can block malicious or suspicious domains before a device connects to them, stopping phishing pages, malware command-and-control traffic, and lookalike domains at the earliest possible point.

Return to the OllaDNS Homepage →

Explore our Protective DNS platform and enterprise solutions.