How DNS Works – Domain Name System Explained

1. What Is DNS and Why It Exists

The Domain Name System (DNS) is the internet's distributed directory service — it translates human-readable hostnames like www.google.com into the numeric IP addresses (like 142.250.183.14) that routers and computers use to actually send traffic. Without DNS, every user would need to memorise IP addresses for every website, service, or server they want to reach.

DNS is not a single server or a simple lookup table. It is a globally distributed, hierarchical, and highly redundant database — split across millions of servers worldwide, designed so that no single failure can bring it down, and so that the workload of billions of queries per day is spread efficiently.

DNS Property	What It Means
Distributed	No single server holds all DNS data. Records are spread across millions of servers, each responsible for a portion of the namespace
Hierarchical	Organised as a tree: root → TLD → domain → subdomain. Each level delegates authority for its subtree to the next level down
Redundant	Every zone has multiple authoritative nameservers. The 13 root server "addresses" are served by hundreds of physical machines via anycast
Cached	Resolvers and clients cache responses for the TTL duration, dramatically reducing query volume and speeding up repeat lookups
UDP-based	DNS uses UDP port 53 for speed (no connection setup overhead). Falls back to TCP port 53 for large responses and zone transfers

2. The DNS Namespace — A Hierarchical Tree

DNS names are read right to left, from the most general to the most specific. Every fully qualified domain name (FQDN) ends with a dot (.) representing the root, though this trailing dot is usually omitted in everyday use.

                             . (Root — the top of the tree)
                             │
              ┌──────────────┼──────────────────────────┐
             .com           .org           .net         .uk  ...  (Top-Level Domains / TLDs)
              │
      ┌───────┴───────┐
   google.com      cisco.com     example.com ...         (Second-Level Domains)
      │
   ┌──┴──────────┐
  www.google.com  mail.google.com  maps.google.com ...  (Subdomains / Third-Level)

  Reading "www.google.com.":
  └── . (root, implied)
      └── com (TLD — Top-Level Domain)
          └── google (Second-Level Domain — registered by Google)
              └── www (Subdomain / host — defined by Google's DNS)

Types of Top-Level Domains (TLDs)

TLD Type	Examples	Description
Generic (gTLD)	.com, .org, .net, .edu, .gov, .mil	The original generic TLDs; .com is the largest with over 160 million domains
New gTLD	.app, .tech, .cloud, .bank, .shop	Introduced since 2012; over 1,200 new gTLDs now exist
Country Code (ccTLD)	.uk, .de, .jp, .au, .sa, .cn	Two-letter codes assigned to countries and territories by ISO 3166
Infrastructure	.arpa	Reserved for internet infrastructure — notably in-addr.arpa for reverse DNS

FQDN vs. Relative Name: A Fully Qualified Domain Name (FQDN) includes every label from hostname to root: www.example.com. (note the trailing dot). A relative name like webserver is completed using the DNS search domain configured on the client — e.g., with search domain company.local, querying webserver resolves to webserver.company.local.

3. The Four Types of DNS Servers

Every DNS query involves up to four different types of servers, each with a distinct role. Understanding these roles is fundamental to CCNA DNS knowledge.

Server Type	Also Called	Role	Examples
DNS Resolver	Recursive resolver, recursive nameserver, DNS recursor	Receives queries from clients and performs the full resolution on their behalf — querying root, TLD, and authoritative servers as needed. Caches responses to serve future queries faster.	ISP DNS (assigned via DHCP), Google 8.8.8.8, Cloudflare 1.1.1.1, your office's DNS server
Root Nameserver	Root server	Knows the IP addresses of all TLD nameservers. Does not know the final IP of any domain — it only refers the resolver to the correct TLD server. There are 13 root server addresses (a.root-servers.net through m.root-servers.net), served by hundreds of physical machines globally via anycast.	a.root-servers.net (VeriSign), b.root-servers.net (ICANN), etc.
TLD Nameserver	TLD server	Manages a specific top-level domain (.com, .org, .net, .uk). Knows which authoritative nameservers are responsible for each domain registered under that TLD. Operated by domain registries (VeriSign for .com, PIR for .org, Nominet for .uk).	a.gtld-servers.net, b.gtld-servers.net (VeriSign, for .com/.net)
Authoritative Nameserver	Authoritative server, zone nameserver	Holds the actual DNS records for a specific domain. This is the definitive source of truth for that domain. The authoritative server answers with the actual IP address, MX records, etc. for the domain it manages. Responses from authoritative servers carry the `aa` (Authoritative Answer) flag.	ns1.example.com (operated by the domain owner or their DNS provider)

Stub resolver: There is actually a fifth component — the stub resolver built into every operating system. It is a minimal DNS client that takes queries from applications, checks the local hosts file and cache, then forwards to the recursive resolver. It does not perform full recursive resolution itself.

4. Step-by-Step DNS Resolution — The Full Query Path

When you type www.example.com in a browser for the first time (nothing cached), here is exactly what happens:

  Your Browser / Application
        │
        │ 1. "I need the IP for www.example.com"
        ▼
  Stub Resolver (OS)
        │ 2. Check hosts file → no entry
        │ 3. Check local DNS cache → not cached
        │ 4. Forward to recursive resolver (e.g., 8.8.8.8)
        ▼
  Recursive Resolver (8.8.8.8)
        │ 5. Check resolver cache → not cached
        │ 6. Ask root server: "Who handles .com?"
        ▼
  Root Server (a.root-servers.net)
        │ 7. "I don't know www.example.com, but .com is handled by:"
        │    "a.gtld-servers.net, b.gtld-servers.net ..."
        ▼
  Recursive Resolver
        │ 8. Ask TLD server: "Who handles example.com?"
        ▼
  TLD Nameserver (a.gtld-servers.net)
        │ 9. "I don't know www.example.com, but example.com is handled by:"
        │    "ns1.example.com (93.184.216.24)"
        ▼
  Recursive Resolver
        │ 10. Ask authoritative server: "What is www.example.com?"
        ▼
  Authoritative Nameserver (ns1.example.com)
        │ 11. "www.example.com has A record: 93.184.216.34 (TTL 3600)"
        │     [Response includes aa flag — Authoritative Answer]
        ▼
  Recursive Resolver
        │ 12. Cache the answer (93.184.216.34, TTL 3600 seconds)
        │ 13. Return answer to the client's stub resolver
        ▼
  Stub Resolver (OS)
        │ 14. Cache locally (for TTL duration)
        │ 15. Return 93.184.216.34 to the browser
        ▼
  Browser connects to 93.184.216.34 on port 443 (HTTPS)

This entire process — involving up to 8 network round-trips — typically completes in 50–300 milliseconds for an uncached query. Subsequent queries for the same name are served from cache in under 1 ms.

5. Recursive vs. Iterative Resolution

The two patterns of DNS resolution — recursive and iterative — describe who does the work of querying multiple servers.

Aspect	Recursive Resolution	Iterative Resolution
Who queries multiple servers	The recursive resolver does all the work — queries root, TLD, authoritative on the client's behalf	The client queries each server itself — root gives a referral, client queries the referred server, which gives another referral, etc.
What the client receives	Final answer (IP address) — the resolver handles all intermediate steps	A referral at each step — the client must follow each referral itself
Where it's used	Client → Recursive Resolver communication. The client sets the Recursion Desired (RD) flag; the resolver sets Recursion Available (RA) in the response.	Recursive Resolver → Root/TLD/Authoritative communication. The resolver itself uses iterative queries when resolving on behalf of a client.
Complexity burden	On the recursive resolver — the client sends one query, gets one answer	On the querying party — must handle referrals and follow delegation chain

In practice: Everyday clients (browsers, ping, SSH) use recursive resolution — they send one query to their configured DNS server (8.8.8.8, their ISP, their corporate DNS) and wait for a complete answer. The recursive resolver then uses iterative queries internally to follow the root → TLD → authoritative chain. You can observe iterative queries directly with dig www.example.com +trace, which forces your system to perform iterative resolution from the root.

6. DNS Caching and Time to Live (TTL)

Caching is the mechanism that makes DNS scale to handle billions of queries per day. Every DNS response includes a TTL (Time to Live) value — the number of seconds that a resolver or client is allowed to cache and reuse that response without querying again.

  DNS Response:
  www.example.com.   3600   IN   A   93.184.216.34
                     ↑
                  TTL = 3600 seconds (1 hour)
                  This response can be served from cache
                  for up to 1 hour before re-querying

  Caching Chain (each level caches independently):
  ┌──────────────────────────────────────────────────┐
  │ Authoritative Server  → Sets TTL (controls how  │
  │                          long the record is cached)│
  └──────────────────────────────────────────────────┘
             ↓ cached for TTL
  ┌──────────────────────────────────────────────────┐
  │ Recursive Resolver    → Caches and serves        │
  │ (8.8.8.8, ISP DNS)      subsequent requests      │
  │                          until TTL expires        │
  └──────────────────────────────────────────────────┘
             ↓ cached for remaining TTL
  ┌──────────────────────────────────────────────────┐
  │ OS / Stub Resolver    → Caches locally for       │
  │ (client machine)         TTL duration             │
  └──────────────────────────────────────────────────┘

TTL Values and Their Implications

TTL Range	Common Value	Use Case	Trade-off
Very short	60–300 seconds	Records about to be changed; failover setups; CDN health checks	More DNS queries, higher load on authoritative server; changes propagate quickly
Short	300–1800 seconds (5–30 min)	DNS migrations; before major changes; load-balanced records	Balance between propagation speed and server load
Standard	3600 seconds (1 hour)	Normal A records, MX records for stable infrastructure	Good balance — changes take up to 1 hour to propagate globally
Long	86400 seconds (24 hours)	Rarely-changing records — NS records, SOA records	Very low query volume; but changes take up to 24 hours to propagate everywhere
Very long	604800 seconds (7 days)	NS records for extremely stable delegations	Minimal server load; changes can take a week to fully propagate

Pre-migration best practice: Before changing a DNS record (e.g., moving a server to a new IP), reduce the TTL to 300 seconds at least 24 hours in advance. This ensures old cached entries expire quickly. After the migration, you can raise the TTL back to 3600+ once the new records are stable.

7. DNS Record Types — Complete Reference

DNS records are the individual entries stored in a DNS zone. Each record type serves a specific purpose. Understanding them is essential for CCNA and real-world DNS work.

Record Type	Full Name	Purpose	Example
A	Address	Maps a hostname to an IPv4 address. The most fundamental DNS record — the first type queried by default.	`www.example.com. 3600 IN A 93.184.216.34`
AAAA	IPv6 Address	Maps a hostname to an IPv6 address (128-bit). Queried automatically by IPv6-capable clients alongside A records.	`www.example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946`
CNAME	Canonical Name	Creates an alias pointing one hostname to another. The resolver follows the chain until it reaches an A/AAAA record. A CNAME cannot coexist with other record types for the same name (except RRSIG in DNSSEC).	`www.example.com. IN CNAME example.com.` → Resolver then looks up example.com A record
MX	Mail Exchange	Specifies the mail server(s) responsible for receiving email for the domain. Each MX record has a priority (lower number = higher preference). The sending mail server tries lower priorities first, falls back to higher numbers.	`example.com. IN MX 10 mail1.example.com.` `example.com. IN MX 20 mail2.example.com.`
NS	Name Server	Lists the authoritative nameservers for a domain. These records appear both in the domain's own zone (authoritative NS) and at the parent TLD level (delegation NS). At least two NS records are required for redundancy.	`example.com. IN NS ns1.example.com.` `example.com. IN NS ns2.example.com.`
PTR	Pointer	Reverse DNS lookup — maps an IP address back to a hostname. PTR records live in the special `in-addr.arpa.` (IPv4) or `ip6.arpa.` (IPv6) zones. Used for email authentication, logging, and security tools.	`34.216.184.93.in-addr.arpa. IN PTR www.example.com.` (Note: IP is reversed in the query name)
SOA	Start of Authority	Every DNS zone has exactly one SOA record. It contains zone metadata: the primary nameserver, responsible party email, zone serial number, and timing parameters (refresh, retry, expire, negative TTL).	`example.com. IN SOA ns1.example.com. admin.example.com. (` `2024041544 ; Serial` `7200 ; Refresh` `3600 ; Retry` `1209600 ; Expire` `3600 )` `; Negative TTL`
TXT	Text	Stores arbitrary text data. Used for email sender authentication (SPF, DKIM, DMARC), domain ownership verification (Google, Microsoft), and security policies.	SPF: `example.com. IN TXT "v=spf1 mx -all"` DMARC: `_dmarc.example.com. IN TXT "v=DMARC1; p=reject"`
SRV	Service Locator	Locates specific services by protocol. Contains priority, weight, port, and target hostname. Used by SIP (VoIP), XMPP (chat), Microsoft Active Directory (LDAP, Kerberos), and many other protocols.	`_ldap._tcp.example.com. IN SRV 0 5 389 dc01.example.com.` (Priority 0, Weight 5, Port 389, Target dc01.example.com)
CAA	Certification Authority Authorisation	Specifies which Certificate Authorities are authorised to issue SSL/TLS certificates for the domain. Prevents unauthorised certificate issuance.	`example.com. IN CAA 0 issue "letsencrypt.org"`
DNSKEY	DNS Key	DNSSEC public key. Used to verify digital signatures (RRSIG records) on DNS responses. Part of the DNSSEC chain of trust.	Contains ZSK (Zone Signing Key) and KSK (Key Signing Key) public keys

8. DNS Zones — What They Are and How They Work

A DNS zone is an administrative unit — a contiguous portion of the DNS namespace that is managed as a single entity by a particular organisation or DNS server. A zone contains all the DNS records for that portion of the namespace and is stored in a zone file on the authoritative nameserver.

Zone vs. Domain

The terms "zone" and "domain" are often confused. A domain is a subtree of the DNS namespace (e.g., example.com and everything under it). A zone is the portion of that domain that a particular nameserver is authoritative for — it may or may not cover the entire domain. If example.com delegates east.example.com to a different nameserver, the example.com zone ends at that delegation boundary, and east.example.com becomes its own separate zone.

  example.com zone (on ns1.example.com):
  ┌──────────────────────────────────────────────────────┐
  │  example.com.        SOA, NS, A, MX, TXT            │
  │  www.example.com.    A record                        │
  │  mail.example.com.   A record                        │
  │  east.example.com.   NS → ns1.east.example.com.      │ ← Delegation
  └──────────────────────────────────────────────────────┘

  east.example.com zone (on ns1.east.example.com — different server):
  ┌──────────────────────────────────────────────────────┐
  │  east.example.com.       SOA, NS                     │
  │  web.east.example.com.   A record                    │
  │  db.east.example.com.    A record                    │
  └──────────────────────────────────────────────────────┘

Primary and Secondary Zones

Zone Type	Description	Notes
Primary Zone	The master copy — all changes (adds, modifies, deletes) to zone records are made here. The SOA record's MNAME field identifies the primary server.	Can be stored as a flat text zone file or in a directory-integrated database (Active Directory DNS)
Secondary Zone	A read-only replica of a primary zone. Receives updates from the primary via zone transfer (AXFR for full, IXFR for incremental changes).	Provides redundancy and load distribution; checks the SOA serial number to determine if an update is needed
Stub Zone	Contains only NS records for a zone (no full copy of records). Used to improve name resolution performance within an organisation.	More lightweight than a secondary zone; useful for directing queries to the correct authoritative servers
Forward Zone	Standard zone mapping names to IPs (A, CNAME, MX records).	The most common zone type
Reverse Zone	Maps IPs back to hostnames (PTR records). Named using reversed IP octets with .in-addr.arpa suffix for IPv4.	e.g., the reverse zone for 192.168.1.0/24 is 1.168.192.in-addr.arpa

9. DNS Delegation — How Authority Is Passed Down

Delegation is the mechanism by which a parent zone transfers authority for a subtree to a child zone's nameservers. This is how the DNS hierarchy actually works in practice — each level trusts the next level down to manage its own portion.

  How google.com was delegated:

  Step 1: ICANN manages the root (.) zone
    → Root zone contains NS records for all TLDs:
       com. IN NS a.gtld-servers.net.  (delegates .com to VeriSign)

  Step 2: VeriSign manages the .com TLD zone
    → .com zone contains NS records for each registered domain:
       google.com. IN NS ns1.google.com.  (delegates google.com to Google)
       google.com. IN NS ns2.google.com.

  Step 3: Google manages the google.com zone
    → google.com zone contains actual records:
       www.google.com.   IN A  142.250.183.14
       mail.google.com.  IN MX 10 gmail-smtp-in.l.google.com.

  Glue Records:
  When a delegation's NS records point to hostnames within the same zone
  being delegated (e.g., ns1.google.com is inside google.com), the parent
  zone MUST include the A record for the NS hostname — these are "glue records."
  Without them, you'd need to resolve google.com to find out where ns1.google.com
  is — a circular dependency!

10. DNS and DHCP — How Clients Get Their DNS Server

Most devices on a network learn their DNS server address automatically via DHCP Option 6. When a DHCP server assigns an IP address, it also sends the DNS server address(es) in the same response — no manual configuration needed.

  DHCP ACK packet — what the server sends to the client:
  ┌─────────────────────────────────────────────────────┐
  │  Your IP address:    192.168.1.15                   │
  │  Subnet mask:        255.255.255.0    (Option 1)    │
  │  Default gateway:    192.168.1.1      (Option 3)    │
  │  DNS servers:        8.8.8.8          (Option 6)    │
  │                      1.1.1.1                        │
  │  Domain name:        company.local    (Option 15)   │
  │  Lease time:         86400 seconds    (Option 51)   │
  └─────────────────────────────────────────────────────┘

  After receiving this, the client:
  → Sets its DNS server to 8.8.8.8 and 1.1.1.1
  → Appends "company.local" when resolving short hostnames
  → Sends all DNS queries to 8.8.8.8 (8.8.8.8 handles full recursive resolution)

See: How DHCP Works | DHCP Overview | DHCP Server Configuration Lab

11. DNSSEC — DNS Security Extensions

Traditional DNS has no authentication — a resolver has no way to verify that the response it receives genuinely came from the authoritative server and wasn't tampered with in transit. DNSSEC (DNS Security Extensions) adds digital signatures to DNS records, allowing resolvers to cryptographically verify that responses are authentic and unmodified.

How DNSSEC Works

The zone owner generates a Zone Signing Key (ZSK) and a Key Signing Key (KSK) keypair.
Every record set in the zone is digitally signed with the ZSK, producing RRSIG records.
The KSK signs the ZSK (stored as a DNSKEY record), and the parent zone stores a hash of the KSK as a DS (Delegation Signer) record.
Resolvers with DNSSEC validation enabled follow this chain of trust from the root down to the zone, verifying signatures at each level.
If any signature fails to verify, the resolver returns SERVFAIL — protecting clients from spoofed responses.

Key DNSSEC Record Types

Record	Purpose
DNSKEY	Stores the public signing keys (ZSK and KSK) for the zone
RRSIG	Digital signature covering a specific record set — proves the records are genuine and unmodified
DS	Delegation Signer — hash of a zone's KSK stored in the parent zone, creating the chain of trust between parent and child
NSEC / NSEC3	Authenticated denial of existence — proves a name does NOT exist, preventing spoofed NXDOMAIN responses

DNSSEC flags in dig output: When dig shows ad in the flags, it means the response is DNSSEC-validated (Authenticated Data). When querying a DNSSEC-signed domain, use dig example.com +dnssec to see RRSIG records. If validation fails, you get SERVFAIL instead of the answer.

12. DNS Threats and Attacks

Because DNS is fundamental to all internet communication, it is a frequent target for attacks. Understanding these threats is important for network security and CCNA exam preparation.

Attack	How It Works	Defence
DNS Cache Poisoning	Attacker injects a forged DNS response into a resolver's cache — associating a legitimate domain with a malicious IP. All clients using that resolver are redirected to the attacker's server until the TTL expires.	DNSSEC (cryptographic validation), source port randomisation, transaction ID randomisation (all implemented in modern resolvers)
DNS Spoofing	Attacker intercepts a DNS query and sends a fake response before the real server replies — same result as cache poisoning but without cache persistence.	DNSSEC; DNS over TLS (DoT) or DNS over HTTPS (DoH) to encrypt queries
DNS Amplification DDoS	Attacker sends small DNS queries with the victim's IP as the source (spoofed) to open resolvers. DNS responses (up to 70x larger than the query) flood the victim. Open resolvers amplify the attack massively.	Disable open recursion on authoritative servers (restrict to authorised clients only); implement BCP 38 anti-spoofing at network edge; rate limiting
DNS Tunnelling	Attacker encodes data in DNS queries and responses to exfiltrate data or establish a command-and-control channel through firewalls that allow DNS traffic.	DNS traffic analysis; anomaly detection for unusually large TXT record queries; DNS firewall / RPZ (Response Policy Zone)
NXDOMAIN Hijacking	ISP or malicious resolver returns a valid IP (usually a search/ad page) for domains that should return NXDOMAIN. Prevents users from discovering misconfigured or non-existent domains.	Use a trusted, non-hijacking resolver (Cloudflare 1.1.1.1, Quad9 9.9.9.9); test with `dig nonexistent-domain.xyz`
DNS Flood / DoS	High-volume flood of DNS queries overwhelms the nameserver, making it unavailable for legitimate queries.	Anycast deployment of DNS infrastructure; rate limiting; DDoS mitigation services (Cloudflare, Akamai)

13. DNS Query Flow — What Happens Inside Your OS

Before a DNS query even leaves your computer, the OS performs several local checks. Understanding this resolution order helps diagnose why a hostname might resolve to an unexpected address.

  Application requests resolution of "webserver.company.com"
                │
                ▼
  ┌─────────────────────────────────────────────────────┐
  │  Step 1: Check hosts file                           │
  │  C:\Windows\System32\drivers\etc\hosts (Windows)   │
  │  /etc/hosts (Linux/macOS)                          │
  │  If found → return immediately (bypasses all DNS)   │
  └─────────────────────────────────────────────────────┘
                │ Not in hosts file
                ▼
  ┌─────────────────────────────────────────────────────┐
  │  Step 2: Check local DNS resolver cache             │
  │  (Windows: ipconfig /displaydns to view)            │
  │  (Linux: resolvectl statistics)                     │
  │  If cached and TTL not expired → return from cache  │
  └─────────────────────────────────────────────────────┘
                │ Not cached (or expired)
                ▼
  ┌─────────────────────────────────────────────────────┐
  │  Step 3: Send DNS query to configured DNS server    │
  │  (from DHCP Option 6 or manual configuration)       │
  │  UDP port 53 → DNS server IP                        │
  └─────────────────────────────────────────────────────┘
                │ If DNS server is unreachable
                ▼
  ┌─────────────────────────────────────────────────────┐
  │  Step 4: Try secondary/alternate DNS server         │
  └─────────────────────────────────────────────────────┘
                │ If all servers fail
                ▼
  ┌─────────────────────────────────────────────────────┐
  │  Step 5: mDNS (Multicast DNS) for .local names     │
  │  (Windows: LLMNR; Linux/macOS: Avahi/mDNS)         │
  │  Broadcasts on local subnet for .local resolution  │
  └─────────────────────────────────────────────────────┘
                │ If no response from any source
                ▼
            Name resolution fails → application error

14. Common DNS Misconceptions

"DNS changes propagate instantly."
DNS changes do not propagate — they expire. When you update a DNS record, the old cached entry persists on resolvers worldwide until its TTL runs out. If your A record has a 24-hour TTL, it could take up to 24 hours before all resolvers serve the new value. This is why lowering the TTL before a planned change is best practice.
"There are only 13 DNS root servers."
There are 13 root server names (a.root-servers.net through m.root-servers.net) and 13 corresponding IP addresses. However, each of these is served by many physical machines using anycast routing — in 2025 there are over 1,700 physical root server instances worldwide. The "13" refers to the number of distinct IP addresses in the root zone file.
"Your ISP's DNS server is the authoritative server for the websites you visit."
Your ISP's DNS is a recursive resolver — it queries other servers on your behalf and caches the results. It is not authoritative for any websites. The authoritative servers for a domain are operated by the domain owner or their DNS hosting provider (Cloudflare, AWS Route 53, GoDaddy DNS, etc.).
"DNS uses TCP."
DNS primarily uses UDP port 53 for its speed advantage (no connection setup). It falls back to TCP port 53 when responses are large (over 512 bytes, or over the EDNS0 limit), for zone transfers (AXFR), and when the tc (Truncated) flag is set in a UDP response.
"A CNAME can point to an IP address."
A CNAME must point to another hostname, never directly to an IP address. The resolver follows the CNAME chain until it reaches an A or AAAA record. Also, a CNAME cannot be created at the zone apex (e.g., you cannot CNAME example.com itself — only subdomains like www.example.com can be CNAMEs).
"Lower MX priority number means lower importance."
The opposite: a lower MX number = higher preference. Mail senders always try the lowest-numbered MX server first and only fall back to higher numbers if the preferred server is unreachable.

15. Key Points & Exam Tips

DNS translates hostnames to IP addresses — uses UDP port 53 (TCP for large responses and zone transfers).
DNS is hierarchical: Root (.) → TLD (.com, .org) → Domain (example.com) → Subdomain (www.example.com). Names read right-to-left from general to specific.
Four server types: Recursive resolver (does the work for clients), Root server (knows TLD servers), TLD server (knows authoritative NS for each domain), Authoritative server (holds actual zone records).
Recursive resolution: client asks resolver once, gets final answer. Iterative resolution: resolver queries root, TLD, authoritative in sequence — this is what the resolver does internally on the client's behalf.
TTL: how long a resolver can cache a DNS response. Lower TTL = faster propagation of changes but more queries. Higher TTL = less load but slower updates.
A record: hostname → IPv4. AAAA: hostname → IPv6. MX: mail servers (lower number = higher priority). CNAME: alias → another hostname. PTR: IP → hostname (reverse DNS). NS: authoritative nameservers. SOA: zone metadata. TXT: text (SPF/DKIM/verification).
Hosts file is checked before DNS — entries in it always override DNS.
DNS zone: administrative unit holding DNS records for a domain portion. Primary zone (master copy) vs secondary zone (read-only replica via zone transfer).
Glue records: A records for NS servers that are within their own zone — required to break circular DNS dependency during delegation.
DNSSEC: adds cryptographic signatures to DNS records (DNSKEY, RRSIG, DS). ad flag in dig = Authenticated Data (DNSSEC validated).
DNS cache poisoning — forged entries in resolver cache. DNSSEC prevents this. DNS amplification — DDoS using open resolvers. DNS tunnelling — data exfil via DNS.

16. How DNS Works Quiz

1. A user types `www.example.com` in their browser for the first time (nothing is cached). Tracing the query path, which server provides the final authoritative answer containing the A record IP address?

A. The root nameserver (a.root-servers.net) — it knows all domain records B. The TLD nameserver (a.gtld-servers.net) — it manages all .com records including A records C. The authoritative nameserver for example.com — it holds the zone's actual records and responds with the aa (Authoritative Answer) flag D. The user's ISP recursive resolver — it generates the answer from its own database

Correct answer is C. In the DNS hierarchy, the root server only knows which servers handle each TLD (.com, .org, etc.) — it does not hold A records. The TLD server only knows which nameservers are authoritative for each registered domain (e.g., who handles example.com) — it also has no A records. The authoritative nameserver for example.com is the definitive source: it holds the actual zone records and responds with the aa (Authoritative Answer) flag set. The ISP resolver is a middleman — it queries all three levels and returns the answer to the client, but the source of truth is always the authoritative server.

2. A recursive resolver receives a DNS query for `mail.example.com`. The resolver's cache is empty. Describe the exact sequence of servers the resolver queries and what each one returns.

A. Resolver → Authoritative server (direct) → gets A record; root and TLD are only used for .com domains B. Resolver → TLD server → gets referral to root → root returns A record C. Resolver broadcasts the query; whichever server responds first provides the answer D. Resolver → Root server (returns .com TLD NS addresses) → Resolver → TLD server (returns example.com authoritative NS addresses) → Resolver → Authoritative server (returns mail.example.com A record)

Correct answer is D. The recursive resolver always starts from the top of the DNS hierarchy (root) when its cache is empty. The root server doesn't know the A record — it returns referrals to the .com TLD servers. The TLD server doesn't know the A record either — it returns referrals to the authoritative nameservers for example.com. Only the authoritative server for example.com holds the actual mail.example.com A record and returns it. This iterative process is called "walking the DNS tree" and is exactly what dig mail.example.com +trace shows you in real time.

3. An A record for `app.company.com` has a TTL of 86400 seconds (24 hours). A DNS administrator changes the record to point to a new IP. A user who queried the record 23 hours ago still resolves to the old IP. Why, and what should the administrator have done in advance?

A. The DNS server failed to propagate the change — the admin must manually clear all resolver caches worldwide B. Resolvers cache responses for the full TTL duration — the old IP is cached for up to 24 hours. The admin should have lowered the TTL to 300 seconds at least 24 hours before the change, waited for old 86400-TTL entries to expire, then made the change C. DNS changes take exactly 48 hours globally — this is normal behaviour D. The authoritative server still has the old record — the change was not saved correctly

Correct answer is B. DNS does not "propagate" changes — resolvers worldwide simply serve whatever is in their cache until the TTL expires. A resolver that cached the old record 23 hours ago will keep serving it for another 1 hour (completing the 24-hour TTL). There is no way to force remote resolvers to discard their caches. The correct pre-migration procedure is to lower the TTL well in advance (commonly to 300 seconds, or even 60 seconds for critical services): 1) Lower TTL to 300s, 2) Wait 24+ hours for all old 86400s TTL caches to expire, 3) Make the DNS change, 4) Verify propagation, 5) Raise TTL back to 86400s after confirming everything works.

4. A domain's MX records are:
`example.com. MX 10 mail1.example.com.`
`example.com. MX 30 mail2.example.com.`
`example.com. MX 20 mail3.example.com.`
In what order does a sending mail server try these MX hosts?

A. mail1 (10) first, then mail3 (20), then mail2 (30) — lower MX priority number = higher preference; tried in ascending numerical order B. mail2 (30) first, then mail3 (20), then mail1 (10) — higher number means the primary mail server C. All three are tried simultaneously — the first to accept the connection wins D. The order depends on the sending server's preference, not the MX numbers

Correct answer is A. MX priority numbers work counter-intuitively: the lowest number is the highest priority. A sending mail server sorts MX records in ascending numerical order and tries them in that order. Here: mail1 (priority 10) is tried first as the preferred mail server. If it is unavailable, mail3 (priority 20) is tried next. mail2 (priority 30) is the last resort. This allows you to designate primary and backup mail servers — lower number = primary, higher number = fallback. Multiple MX records with the same priority number are tried in random order (load balancing).

5. A DNS administrator creates a CNAME record:
`shop.example.com. IN CNAME storefront.cdn.provider.com.`
A client queries for shop.example.com. Describe what the resolver does to return a final IP address to the client.

A. The resolver returns the CNAME record itself — the client must then perform a second query for storefront.cdn.provider.com B. The CNAME record contains an IP address embedded in the alias name — no further lookup needed C. The resolver follows the CNAME chain automatically — queries for storefront.cdn.provider.com and returns both the CNAME record and the final A record IP to the client in the same response D. CNAME queries are not forwarded — the resolver returns NXDOMAIN because shop.example.com has no A record

Correct answer is C. Recursive resolvers follow CNAME chains transparently. When the resolver encounters a CNAME record for shop.example.com, it immediately performs a follow-up query for the CNAME target (storefront.cdn.provider.com). This continues until an A or AAAA record is found. The full response returned to the client typically includes both the CNAME record and the final A record IP — so the client sees the complete chain. The client does not need to perform multiple queries manually. Note: CNAME records must always point to another hostname, never an IP address, and cannot be used at the zone apex (you cannot CNAME example.com itself).

6. What are "glue records" in DNS, and why are they essential during zone delegation?

A. Glue records are duplicate DNS entries that improve performance by pre-caching frequently accessed hostnames B. Glue records are A records for nameservers that are within their own delegated zone — without them, resolvers face a circular dependency (needing to resolve ns1.example.com to find example.com's NS, but needing example.com's NS to resolve ns1.example.com) C. Glue records are TXT records added to zones for SPF email authentication to "glue" sender policies together D. Glue records are optional metadata added by registrars for billing purposes

Correct answer is B. Glue records solve a fundamental circular dependency. Consider: example.com's NS record points to ns1.example.com. To resolve example.com, the resolver needs to find ns1.example.com's IP. But ns1.example.com is itself inside the example.com zone — so you'd need to query example.com's NS to find ns1.example.com, which requires finding ns1.example.com first. A circular dependency! The solution is for the parent zone (.com TLD) to include the A record (IP address) for ns1.example.com directly in its delegation response — these "extra" A records are glue records. They bootstrap the resolution of the NS hosts, breaking the circular dependency.

7. DNS cache poisoning attacks historically exploited predictable transaction IDs and source ports in DNS queries. How does DNSSEC defend against cache poisoning, and what does the `ad` flag in a dig response indicate?

A. DNSSEC encrypts DNS queries so attackers cannot see what is being queried; ad means the query used HTTPS transport B. DNSSEC randomises TTL values to make poisoning harder; ad means Additional Data is present in the response C. DNSSEC blocks all UDP DNS traffic; ad means the response came from an Authoritative DNS server D. DNSSEC adds cryptographic digital signatures to DNS records — even if a poisoned response is injected into a cache, a DNSSEC-validating resolver rejects it because the forged records lack valid signatures. ad = Authenticated Data — the response passed DNSSEC signature validation

Correct answer is D. DNSSEC adds digital signatures (RRSIG records) to DNS record sets. A DNSSEC-validating resolver cryptographically verifies these signatures against the public keys (DNSKEY records) in the zone. Even if an attacker injects a poisoned response, they cannot forge valid signatures without the private signing key — so the validation fails and the resolver returns SERVFAIL instead of the poisoned answer. The ad (Authenticated Data) flag in the DNS response header means the resolver successfully validated the DNSSEC signatures and confirms the response is genuine and unmodified. Note: DNSSEC does not encrypt DNS queries — that's the job of DoT or DoH.

8. A company's web server is at internal IP 10.10.10.80 and public IP 203.0.113.80. Internal users should reach it at 10.10.10.80; external users at 203.0.113.80. Both resolve via `www.company.com`. How is this achieved?

A. Split DNS — the internal DNS server has www.company.com → 10.10.10.80 (only served to internal queries); the external/public DNS server has www.company.com → 203.0.113.80 (served to internet queries) B. A single CNAME record points to both IPs, and the resolver selects the closest one C. The firewall rewrites the DNS response based on the client's source IP D. Two different domain names must be used — internal users use www.internal.com and external users use www.company.com

Correct answer is A. This is the classic split DNS (split-brain DNS) architecture. Two DNS servers authoritative for the same domain name give different answers based on who is asking. The internal DNS server — accessible only from the corporate network — returns the private IP (10.10.10.80) for www.company.com. The external/public DNS server (published in the public DNS hierarchy) returns the public IP (203.0.113.80). Internal users query the internal DNS (their DHCP-assigned DNS server) and get the private IP, connecting directly over the LAN. External users query public DNS and get the public IP. Same hostname, two different answers — based on which DNS server handles the query.

9. A client has `192.168.1.1 printer.local` in its hosts file, but the DNS server has `printer.local → 192.168.1.50`. When the client pings `printer.local`, which IP is used, and why?

A. 192.168.1.50 — DNS server responses always override local hosts file entries B. Both IPs are tried — the client sends requests to both simultaneously and uses whichever responds first C. 192.168.1.1 — the hosts file is checked before DNS in the OS resolution order; a hosts file entry always takes precedence over DNS D. The resolution fails — conflicting entries between hosts file and DNS cause an error

Correct answer is C. The OS name resolution process always checks the hosts file before querying DNS — on both Windows and Linux. The hosts file is the highest-priority local resolution mechanism. Because printer.local is found in the hosts file (pointing to 192.168.1.1), the OS returns that IP immediately and never sends a DNS query. The DNS server entry (192.168.1.50) is never consulted. This behaviour is intentional and is used in network administration for testing (temporarily overriding DNS) and for blocking (redirecting unwanted domains to 127.0.0.1). On Linux, this order is defined in /etc/nsswitch.conf — typically hosts: files dns.

10. An attacker sends thousands of DNS queries with a spoofed source IP of a victim server (10.0.0.50) to open DNS resolvers worldwide, querying for a TXT record that returns a 4000-byte response. The victim receives massive UDP floods. What attack is this, why is DNS particularly effective for it, and what configuration on DNS servers prevents participation?

A. DNS cache poisoning — prevented by DNSSEC on all authoritative servers B. DNS amplification DDoS — DNS is effective because a small query (~50 bytes) can generate a large response (~4000 bytes), amplifying traffic 80x. Prevented by disabling open recursion (restrict recursive queries to authorised clients only) and implementing BCP 38 anti-spoofing C. DNS zone transfer attack — prevented by restricting AXFR to trusted secondary servers D. DNS tunnelling — prevented by deep packet inspection of DNS queries

Correct answer is B. DNS amplification is a reflection/amplification DDoS attack that exploits the amplification factor of DNS: a small UDP query (50–100 bytes) can trigger a large DNS response (hundreds to thousands of bytes). By spoofing the source IP to the victim's address, the attacker directs this amplified response flood at the victim without revealing their own IP. TXT records (often used for SPF, DKIM) can return very large responses, making them popular for amplification. The primary defence on DNS servers is disabling "open recursion" — configure the resolver to only answer recursive queries from authorised clients (your own network), not from the entire internet. DNSSEC actually makes responses larger (adding RRSIG records), which can increase amplification — another reason to restrict open recursion regardless of DNSSEC status.

← Back to Home

How DNS Works – Domain Name System Explained

1. What Is DNS and Why It Exists

2. The DNS Namespace — A Hierarchical Tree

Types of Top-Level Domains (TLDs)

3. The Four Types of DNS Servers

4. Step-by-Step DNS Resolution — The Full Query Path

5. Recursive vs. Iterative Resolution

6. DNS Caching and Time to Live (TTL)

TTL Values and Their Implications

7. DNS Record Types — Complete Reference

8. DNS Zones — What They Are and How They Work

Zone vs. Domain

Primary and Secondary Zones

9. DNS Delegation — How Authority Is Passed Down

10. DNS and DHCP — How Clients Get Their DNS Server

11. DNSSEC — DNS Security Extensions

How DNSSEC Works

Key DNSSEC Record Types

12. DNS Threats and Attacks

13. DNS Query Flow — What Happens Inside Your OS

14. Common DNS Misconceptions

15. Key Points & Exam Tips

16. How DNS Works Quiz

1. A user types www.example.com in their browser for the first time (nothing is cached). Tracing the query path, which server provides the final authoritative answer containing the A record IP address?

2. A recursive resolver receives a DNS query for mail.example.com. The resolver's cache is empty. Describe the exact sequence of servers the resolver queries and what each one returns.

3. An A record for app.company.com has a TTL of 86400 seconds (24 hours). A DNS administrator changes the record to point to a new IP. A user who queried the record 23 hours ago still resolves to the old IP. Why, and what should the administrator have done in advance?

4. A domain's MX records are: example.com. MX 10 mail1.example.com. example.com. MX 30 mail2.example.com. example.com. MX 20 mail3.example.com. In what order does a sending mail server try these MX hosts?

5. A DNS administrator creates a CNAME record: shop.example.com. IN CNAME storefront.cdn.provider.com. A client queries for shop.example.com. Describe what the resolver does to return a final IP address to the client.

6. What are "glue records" in DNS, and why are they essential during zone delegation?

7. DNS cache poisoning attacks historically exploited predictable transaction IDs and source ports in DNS queries. How does DNSSEC defend against cache poisoning, and what does the ad flag in a dig response indicate?

8. A company's web server is at internal IP 10.10.10.80 and public IP 203.0.113.80. Internal users should reach it at 10.10.10.80; external users at 203.0.113.80. Both resolve via www.company.com. How is this achieved?

9. A client has 192.168.1.1 printer.local in its hosts file, but the DNS server has printer.local → 192.168.1.50. When the client pings printer.local, which IP is used, and why?

1. A user types `www.example.com` in their browser for the first time (nothing is cached). Tracing the query path, which server provides the final authoritative answer containing the A record IP address?

2. A recursive resolver receives a DNS query for `mail.example.com`. The resolver's cache is empty. Describe the exact sequence of servers the resolver queries and what each one returns.

3. An A record for `app.company.com` has a TTL of 86400 seconds (24 hours). A DNS administrator changes the record to point to a new IP. A user who queried the record 23 hours ago still resolves to the old IP. Why, and what should the administrator have done in advance?

4. A domain's MX records are:
`example.com. MX 10 mail1.example.com.`
`example.com. MX 30 mail2.example.com.`
`example.com. MX 20 mail3.example.com.`
In what order does a sending mail server try these MX hosts?

5. A DNS administrator creates a CNAME record:
`shop.example.com. IN CNAME storefront.cdn.provider.com.`
A client queries for shop.example.com. Describe what the resolver does to return a final IP address to the client.

7. DNS cache poisoning attacks historically exploited predictable transaction IDs and source ports in DNS queries. How does DNSSEC defend against cache poisoning, and what does the `ad` flag in a dig response indicate?

8. A company's web server is at internal IP 10.10.10.80 and public IP 203.0.113.80. Internal users should reach it at 10.10.10.80; external users at 203.0.113.80. Both resolve via `www.company.com`. How is this achieved?

9. A client has `192.168.1.1 printer.local` in its hosts file, but the DNS server has `printer.local → 192.168.1.50`. When the client pings `printer.local`, which IP is used, and why?