Lesson 9 of 12

DNS

21 min read

DNS — Domain Name System

Every time you type a website address into your browser, something remarkable happens in the background: a system called DNS translates the human-readable name you typed into a numeric address your computer can actually use to reach the right server. That translation happens in milliseconds, involves multiple servers around the world, and is almost entirely invisible to you. This lesson explains how it works, why it is designed the way it is, and where it can go wrong.

What DNS Is and Why It Exists

DNS stands for Domain Name System. Its job is to translate human-readable domain names — like google.com, github.com, or wikipedia.org — into IP (Internet Protocol) addresses, which are the numeric identifiers that computers and routers use to route traffic across the internet.

An IP address looks like this: 93.184.216.34 (IPv4, or Internet Protocol version 4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6, or Internet Protocol version 6). These numbers are how network equipment actually delivers your request to the correct destination. But humans are not good at memorizing lists of numbers. DNS exists to bridge that gap.

Without DNS, you would have to know and type the IP address of every website you wanted to visit. That was the approach in the early internet: a file called HOSTS.TXT was manually updated and distributed to every connected machine. By the mid-1980s, the internet had grown too large for that to work. DNS was created to replace it, defined in RFC (Request for Comments) 1034 and RFC 1035, published in 1987 by the IETF (Internet Engineering Task Force).

DNS is sometimes called "the phone book of the internet." That analogy is useful but incomplete — the real DNS is a globally distributed, hierarchical, and heavily cached database operated by thousands of organizations. No single server knows all domain names. The system is designed that way intentionally.

The DNS Hierarchy — A Distributed, Layered Database

The DNS namespace is organized as a tree, read from right to left. The name www.example.com is actually three labels: com (the top-level domain), example (the registered domain), and www (the subdomain or hostname). Each label is a level in the hierarchy.

The Root Zone

At the very top is the root zone, represented by a single dot (.) that is usually invisible at the end of a domain name. The root zone is served by 13 sets of root name servers, labeled A through M: a.root-servers.net through m.root-servers.net. These are operated by a variety of organizations — ICANN (Internet Corporation for Assigned Names and Numbers), Verisign, NASA (National Aeronautics and Space Administration), and others.

Thirteen labels might sound like only 13 servers, but that is not the case. Through a technique called anycast routing, each label corresponds to hundreds of physical servers distributed around the world. Anycast works by having many machines announce the same IP address; your query is automatically routed to the nearest one. The total number of root server instances worldwide is well over 1,600.

Root servers do not know the IP address of every domain in the world. They only know the addresses of the servers responsible for each TLD (Top-Level Domain). Their job is to point the next step in the right direction.

TLD (Top-Level Domain) Servers

Below the root sit the TLD servers. Each TLD — .com, .org, .net, .gov, .edu, .uk, .io, .de, and hundreds of others — has its own set of authoritative name servers.

The .com TLD servers, operated by Verisign, know the authoritative name servers for every registered .com domain. When you register example.com, your registrar tells the .com TLD servers where your authoritative name servers are. The .com servers do not store the actual IP address of your website — they only know which servers are authoritative for your domain.

Authoritative Name Servers

At the bottom of the hierarchy sit the authoritative name servers. These are the servers that hold the actual DNS records for a specific domain. If you own example.com, your authoritative name servers hold the records that say www.example.com resolves to a particular IP address.

When you register a domain, you designate authoritative name servers for it. This can be servers provided by your registrar, your web hosting company, a cloud DNS provider like Cloudflare or AWS (Amazon Web Services) Route 53, or servers you operate yourself.

The authoritative name server is the final, authoritative answer. Its response is not a referral — it is the definitive answer.

Recursive Resolvers

Your device does not talk to root servers directly. Instead, it talks to a recursive resolver — also called a recursive name server or simply a DNS resolver. This is a server (usually operated by your ISP, or Internet Service Provider, or a public provider) that does the work of querying the hierarchy on your behalf.

When you connect to a network, your device is told which recursive resolver to use — usually via DHCP (Dynamic Host Configuration Protocol). Common public recursive resolvers include 8.8.8.8 and 8.8.4.4 (operated by Google) and 1.1.1.1 (operated by Cloudflare). Your router at home may also act as a simple local resolver that forwards queries to one of these.

The recursive resolver receives your query, consults the hierarchy step by step (root → TLD → authoritative), assembles the final answer, returns it to your device, and caches it for future use.

The DNS Resolution Process — Step by Step

Here is exactly what happens when you type www.example.com into your browser:

Step 1 — Browser cache check. Your browser keeps its own short-lived DNS cache. If it has resolved www.example.com recently and the cached entry has not expired, it uses that cached answer immediately and skips all remaining steps.

Step 2 — OS cache and hosts file check. If the browser cache has no answer, the OS (operating system) checks its own DNS cache and a local file called the hosts file. On Linux and macOS, this file lives at /etc/hosts. On Windows, it lives at C:\Windows\System32\drivers\etc\hosts. Any entry in the hosts file overrides DNS entirely. If an entry is found, it is used immediately.

Step 3 — Query the recursive resolver. If neither local cache nor the hosts file has an answer, the OS sends a DNS query to the configured recursive resolver — for example, 8.8.8.8.

Step 4 — Recursive resolver cache check. The recursive resolver checks its own cache. If it has recently resolved www.example.com and the TTL (Time to Live — explained in the next section) has not expired, it returns the cached answer immediately. This is the most common case for popular websites.

Step 5 — Query a root name server. If the resolver has no cached answer, it sends an iterative query to one of the 13 root name servers: "Who handles the .com TLD?"

Step 6 — Root server responds with TLD referral. The root server responds: "I don't know example.com, but the .com TLD servers are at a.gtld-servers.net, b.gtld-servers.net..." (and so on). The root server gives the resolver an address to ask next.

Step 7 — Query the .com TLD server. The resolver now asks a .com TLD server: "Who is authoritative for example.com?"

Step 8 — TLD server responds with authoritative referral. The .com TLD server responds: "The authoritative name servers for example.com are ns1.example.com and ns2.example.com." It also provides the IP addresses of those name servers so the resolver does not need to look those up separately.

Step 9 — Query the authoritative name server. The resolver queries ns1.example.com (or ns2.example.com): "What is the IP address of www.example.com?"

Step 10 — Authoritative server responds with the answer. The authoritative name server responds: "www.example.com has IP address 93.184.216.34." This is the final, definitive answer.

Step 11 — Resolver returns the answer and caches it. The resolver sends the answer back to your device and stores it in its cache for the duration of the TTL. Future queries from any device using that resolver will get the cached answer instantly.

Step 12 — Browser connects. Your browser connects to 93.184.216.34 on port 443 (for HTTPS, or Hypertext Transfer Protocol Secure) or port 80 (for HTTP, or Hypertext Transfer Protocol). The web page loads.

This entire process — all 12 steps — typically completes in tens to a few hundred milliseconds.

DNS Caching and TTL (Time to Live)

Every DNS record carries a TTL value — a number measured in seconds that tells resolvers and clients how long they may cache the record before they must query for a fresh copy. The TTL is set by the domain owner in their authoritative DNS configuration.

When a recursive resolver caches a record, it starts counting down the TTL. Each subsequent response that includes the record in transit also decrements the TTL to reflect how long the record has been in circulation. By the time a cached entry reaches a client, the TTL shown is the remaining lifetime. When the TTL reaches zero, the cached entry is discarded and the next query triggers a fresh lookup.

High TTL values — for example, 86400 seconds (24 hours) — mean:

Fewer DNS queries across the internet (better performance, less load)
Faster responses for users, because the cached answer is reused often
Slower propagation when you change a record — every resolver and client that has the old record cached will continue using it until their copy expires

Low TTL values — for example, 300 seconds (5 minutes) — mean:

DNS record changes propagate quickly
More frequent DNS queries (higher load on resolvers and authoritative servers)
Useful before a planned migration: drop the TTL days in advance so propagation after the change is fast

A common best practice is to use a moderate TTL (3600 = 1 hour) normally, then lower it temporarily before a planned change, and raise it again after the change is confirmed working.

DNS Record Types — In Detail

DNS records are stored in zone files on authoritative name servers. Each record has a type that determines what information it carries. Here are the most important types you will encounter.

A Record

An A record maps a hostname to an IPv4 address. It is the most fundamental DNS record type.

Example: www.example.com → 93.184.216.34

A single hostname can have multiple A records, each with a different IP address. DNS will return all of them, and the client (or a load balancer) decides which to use. This is called DNS round-robin and is a simple form of load distribution.

AAAA Record (Quad-A)

An AAAA record (pronounced "quad-A") maps a hostname to an IPv6 address. The name comes from the fact that IPv6 addresses are four times longer than IPv4 addresses (128 bits versus 32 bits).

Example: www.example.com → 2606:2800:220:1:248:1893:25c8:1946

Modern servers typically have both A and AAAA records. When a client that supports IPv6 queries for a name, it receives both and will generally prefer to connect over IPv6.

CNAME Record (Canonical Name)

A CNAME record creates an alias — it maps one hostname to another hostname, not to an IP address directly. The querying system follows the chain until it reaches an A or AAAA record.

Example: mail.example.com → example-mail.mailprovider.com

If the target of the CNAME (example-mail.mailprovider.com) has an A record pointing to some IP address, then mail.example.com ultimately resolves to that IP — but through the intermediate alias. This is useful when you want a friendly name (mail.example.com) to point to a service managed elsewhere, and the service provider controls the actual IP address.

Important restriction: you cannot use a CNAME at the root of a domain (the "apex" or "naked domain" — example.com without a subdomain). The root must have an A record. Some DNS providers offer proprietary workarounds (called ALIAS or ANAME records) for this.

MX Record (Mail Exchanger)

An MX record specifies which server handles email for a domain. When another mail server wants to deliver email to user@example.com, it queries the MX record for example.com.

Example: example.com → mail.example.com (priority 10)

MX records include a priority number. Lower numbers have higher priority. If you have:

Priority 10: mail1.example.com
Priority 20: mail2.example.com

then mail is delivered to mail1.example.com first. If mail1 is unavailable, the sending server tries mail2.example.com. This provides automatic failover for email delivery.

MX records must point to a hostname (which has an A record), not directly to an IP address.

NS Record (Name Server)

An NS record specifies which servers are authoritative for a domain.

Example: example.com → ns1.example.com, ns2.example.com

NS records are the glue that connects the TLD servers to your authoritative servers. When you look up a domain's NS records, you see where the authoritative zone is hosted. You typically have at least two NS records (two different name servers) for redundancy.

PTR Record (Pointer)

A PTR record is the reverse of an A record. Instead of mapping a hostname to an IP, it maps an IP address back to a hostname. This is called reverse DNS.

The IP address is written in reverse order and appended with .in-addr.arpa for IPv4. For example, the PTR record for 93.184.216.34 is found at 34.216.184.93.in-addr.arpa.

Example: 34.216.184.93.in-addr.arpa → www.example.com

PTR records are used by mail servers to verify that a sending server's IP address matches its claimed hostname (the domain in its HELO/EHLO greeting). This is called a forward-confirmed reverse DNS check, and many mail servers reject email or mark it as spam if the PTR record does not match. PTR records are also useful in network logs for making IP addresses more readable.

TXT Record (Text)

A TXT record holds arbitrary text associated with a domain. It has evolved into the standard mechanism for domain ownership verification and email authentication.

Common uses:

SPF (Sender Policy Framework): A TXT record that lists which mail servers are authorized to send email on behalf of a domain. Receiving mail servers check SPF to filter forged-sender spam.
DKIM (DomainKeys Identified Mail): A TXT record that publishes the public key used to verify the cryptographic signature attached to outgoing email.
Domain ownership verification: Services like Google Search Console or certificate authorities ask you to add a specific TXT record to prove you control the domain.

SOA Record (Start of Authority)

Every DNS zone has exactly one SOA record. It contains administrative information about the zone:

The primary (master) name server for the zone
The email address of the zone administrator (in a special format: admin.example.com means admin@example.com)
A serial number that increases each time the zone is updated (secondary name servers use this to detect whether they need to synchronize)
Timing parameters: refresh interval (how often secondary servers check for updates), retry interval (how long a secondary waits before retrying a failed refresh), expire time (when a secondary server stops answering queries if it cannot reach the primary), and the default TTL for negative responses

DNS Query Types

Recursive query: Your device sends a recursive query to the recursive resolver. You are asking: "Give me the complete, final answer for www.example.com." The resolver accepts responsibility for doing all the work — querying root servers, TLD servers, and authoritative servers — and returns only the final answer to your device. This is the type of query your device sends.

Iterative query: The recursive resolver uses iterative queries when it talks to root and TLD servers. It asks: "What do you know about www.example.com?" The server being queried returns the best referral it has ("ask the .com TLD servers") rather than doing the recursive lookup itself. The resolver follows the chain of referrals until it reaches an authoritative answer.

Your device makes recursive queries. Resolvers make iterative queries upward through the hierarchy.

Transport protocol: DNS uses UDP (User Datagram Protocol) on port 53 for almost all queries. UDP is fast and low-overhead — ideal for short request-response exchanges. Because most DNS responses are small (under a few hundred bytes), the lack of TCP's connection overhead makes UDP the right choice.

When a DNS response is larger than 4,096 bytes, or for zone transfers (AXFR — a full copy of a zone sent from primary to secondary name server), DNS falls back to TCP (Transmission Control Protocol) on port 53. TCP provides reliable, ordered delivery, which matters for large transfers.

More recently, DNS over HTTPS (DoH) and DNS over TLS (DoT) are emerging standards that encrypt DNS queries, preventing eavesdropping by your ISP or anyone on the network between you and the resolver.

DNS Security Threats

DNS was designed in an era when the internet was a small network of trusted academic and government institutions. Security was not a design priority. That has created vulnerabilities that attackers exploit regularly.

DNS Cache Poisoning (DNS Spoofing)

In DNS cache poisoning, an attacker injects forged DNS records into a resolver's cache. If the attacker succeeds, the resolver will return the malicious IP address to every user who queries for the target domain — redirecting their traffic to an attacker-controlled server.

The fundamental vulnerability is that DNS queries use a transaction ID — a 16-bit number included in the query and matched in the response. Early DNS implementations used predictable transaction IDs and sent queries from a fixed source port. In 2008, security researcher Dan Kaminsky discovered a fundamental weakness that made it practical to guess the transaction ID and race a forged response against the legitimate one. An attacker could reliably poison a resolver's cache within seconds.

The immediate mitigations were to randomize the source port of DNS queries (adding entropy beyond just the 16-bit transaction ID) and to randomize transaction IDs properly. The deeper, more robust solution is DNSSEC (DNS Security Extensions), defined in RFC 4033, which allows resolvers to cryptographically verify that DNS records are authentic and have not been tampered with. DNSSEC uses public-key cryptography to sign zone records; resolvers with DNSSEC validation enabled will reject forged responses even if they arrive before the legitimate one.

DNS Hijacking

DNS hijacking differs from cache poisoning in that the attacker modifies the legitimate records at their source — by compromising the domain registrar account, the authoritative name server configuration, or the recursive resolver itself. Users querying for a legitimate domain are directed to malicious servers because the authoritative answer itself has been changed.

In 2019, CISA (Cybersecurity and Infrastructure Security Agency) issued Alert TA19-024A documenting a campaign in which a state-sponsored actor gained access to domain registrar accounts and modified NS records and A records for government and commercial domains in multiple countries. Victims' traffic was silently routed through infrastructure the attacker controlled, allowing credential harvesting via forged login pages.

DNS hijacking is particularly dangerous because DNSSEC cannot protect against it if the attacker has compromised the private signing keys or the registrar account used to publish DNSSEC records.

Defenses include multi-factor authentication on registrar accounts, registry lock (a service that prevents DNS record changes without out-of-band verification), and monitoring for unexpected changes to your DNS records.

DNS Tunneling

DNS tunneling encodes arbitrary data inside DNS queries and responses to bypass network security controls. Because UDP port 53 is almost never blocked by firewalls — DNS is considered essential infrastructure — it can be used as a covert channel to exfiltrate data or establish command-and-control communication even when other outbound traffic is blocked.

The technique works because an attacker controls an authoritative name server for a domain (for example, tunnel.attacker.com). Malware on a victim machine sends DNS queries with encoded data in the subdomain portion: steal-data-chunk-1.tunnel.attacker.com. The query passes through the organization's firewall (which allows DNS), is forwarded by the recursive resolver to the attacker's authoritative server, and the attacker reads the encoded data from the subdomain label.

The attacker sends data back to the malware encoded in the DNS response. Neither the firewall nor most network monitoring tools inspect DNS query contents for unusual patterns.

Tools that implement DNS tunneling include iodine (which can tunnel an IP connection through DNS) and dnscat2 (designed for command-and-control). Security defenders detect DNS tunneling by looking for unusually long subdomain labels, high query volumes to a single domain, unusual query types (TXT queries in particular), and domains with low reputation or no web presence.

DNS Amplification DDoS (Distributed Denial of Service)

DNS amplification abuses open recursive resolvers — DNS servers that will respond to queries from any IP address on the internet — to flood a victim with traffic.

The attack works as follows: the attacker sends DNS queries to many open resolvers, forging the victim's IP address as the source IP (IP spoofing). The resolvers, believing the queries came from the victim, send their responses to the victim. The key is the amplification factor: a small DNS query (perhaps 40 bytes) can trigger a large response (up to 4,000 bytes or more), a multiplication of 100 times or more. With thousands of resolvers sending these amplified responses simultaneously, the victim is overwhelmed.

DNS amplification attacks are a common vector for large volumetric DDoS attacks. Defense involves network operators filtering outbound traffic with spoofed source addresses (BCP 38, or Best Current Practice 38 — network ingress filtering), limiting or eliminating open recursive resolvers, and rate-limiting DNS responses.

Checking DNS from the Command Line

You do not need special tools to investigate DNS. Every major operating system ships with utilities for querying DNS records directly.

nslookup — available on Windows, Linux, and macOS:

nslookup example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

dig (Domain Information Groper) — standard on Linux and macOS, installable on Windows:

dig example.com
dig example.com MX
dig example.com TXT
dig @8.8.8.8 example.com          # Query a specific resolver (8.8.8.8 = Google)
dig +short example.com             # Show only the answer, not full output
dig +trace example.com             # Show the full iterative resolution from root

The dig +trace option is especially valuable for learning: it shows you exactly how the resolver walks the hierarchy from root server to TLD server to authoritative server.

host — a simpler alternative on Linux and macOS:

host example.com
host -t MX example.com

The Bottom Line

DNS is the system that translates domain names into IP addresses. It is hierarchical and distributed — no single server holds all the answers. Your device asks a recursive resolver, which queries root servers, then TLD servers, then authoritative servers, and returns the complete answer. Every answer is cached for a TTL period to reduce load and improve speed. DNS records come in many types: A and AAAA for IP addresses, CNAME for aliases, MX for mail, NS for name servers, PTR for reverse lookups, TXT for email authentication and verification, and SOA for zone administration. Because DNS was not designed with security in mind, it is vulnerable to cache poisoning, hijacking, tunneling, and amplification attacks. DNSSEC, registrar account security, and DNS monitoring are the primary defenses.

Check Your Understanding

When you type a website address into your browser, your device does not contact a root name server directly. What does it contact instead, and what does that system do on your device's behalf?
You own a domain and you want email sent to @yourdomain.com to be delivered to a mail server you control. Which DNS record type do you need to create, and what does it contain?

Something to Think About

A website you visit regularly suddenly redirects you to a fake login page that looks identical to the real one. Your browser shows the correct URL but the page is asking for your password. Knowing what you know about DNS cache poisoning and DNS hijacking, how could an attacker have caused this? What would you check to investigate?
Many organizations block unusual outbound traffic but permit DNS queries on port 53. Why does DNS tunneling represent a fundamental challenge for perimeter security, and what properties of DNS traffic would you look for if you were trying to detect it in network logs?

References

Official Specification. RFC 1034 — "Domain Names — Concepts and Facilities". IETF, 1987. — Foundational DNS specification defining the namespace structure, the hierarchy of root, TLD, and authoritative servers, and the distributed database model.
Official Specification. RFC 1035 — "Domain Names — Implementation and Specification". IETF, 1987. — Companion to RFC 1034; defines DNS record types (A, NS, CNAME, SOA, PTR, MX, TXT), message format, and the resolution process including recursive and iterative queries.
Official Specification. RFC 4033 — "DNS Security Introduction and Requirements (DNSSEC)". IETF. — Introduces DNSSEC, the cryptographic extension that allows DNS resolvers to verify that records are authentic and have not been tampered with, addressing the cache poisoning vulnerability class.
Real-World Incident. CISA — "Advisory AA22-011A: Understanding and Mitigating Russian State-Sponsored Cyber Threats". CISA. — Documents DNS hijacking used in state-sponsored operations against government and critical infrastructure targets, including techniques for credential harvesting via redirected DNS.
Real-World Incident. CISA — "Alert TA19-024A: DNS Infrastructure Tampering". CISA, 2019. — Specific advisory on a state-sponsored actor modifying DNS records for government and commercial domains globally by compromising domain registrar accounts.