DNS - Domain Name System N10-009

Slide 1 of 10  |  N10-009 Obj 3.4  |  Network Operations
DNS: Domain Name System
The Internet's Phone Book
You type a name. The network needs a number. DNS bridges that gap.
A user calls the help desk: "I can't reach intranet.company.com but Google works fine." Over the next 10 slides we will trace exactly what DNS does, how a query flows through the hierarchy, what each record type means, and why their specific failure is pointing directly at an internal DNS problem.
10 Slides N10-009 Obj 3.4 Application Layer (Layer 7) Port 53 TCP/UDP
Slide 2 of 10
What DNS Actually Does
Humans use names. Routers use numbers. DNS is the translator running invisibly behind every connection.
The Core Job
DNS resolves fully qualified domain names (FQDNs) to IP addresses. When you type intranet.company.com, DNS finds the IP address that goes with that name so your machine knows where to send the packets.
Forward vs Reverse
A forward lookup goes name → IP. A reverse lookup goes IP → name. Reverse is used in logging, email spam checks (PTR records), and security tools that want to identify what a given IP belongs to.
Port & Protocol
DNS runs on port 53. UDP for standard queries (small, fast). TCP for zone transfers and responses over 512 bytes (needs reliability).
What Happens When You Type intranet.company.com
1. Check local cache
2. Check hosts file
3. Ask configured DNS resolver
4. Resolver queries hierarchy
5. Answer returned, cached
6. TCP connection proceeds
The user said Google works fine. That means their DNS resolver is reachable and public DNS is answering. The failure is specific to intranet.company.com — an internal zone the public DNS servers have no record of. The problem is in the internal DNS configuration.
Slide 3 of 10
The DNS Hierarchy
DNS is a distributed database organized as an inverted tree. Resolution starts at the root and works down.
Root Zone  .
13 root server clusters worldwide
↓ "I don't know company.com — ask the .com TLD servers"
.com TLD
.org TLD
.net TLD
.gov TLD
↓ "I don't know company.com records — ask ns1.company.com"
ns1.company.com
Authoritative Server
ns2.company.com
Secondary / Redundancy
↓ "intranet.company.com = 10.10.5.20"   (final answer)
Recursive Resolver
Your ISP or internal DNS
Authoritative server — holds the actual zone records for a domain. It gives the final, official answer. If this server is wrong or missing a record, resolution fails.
Recursive resolver — does the legwork for clients. It walks the hierarchy on your behalf, caches answers to speed up future requests, and returns the final IP.
Slide 4 of 10
DNS Record Types — Know These Cold
Each record type answers a different question. The exam will test your ability to match type to purpose.
A
Address (IPv4)
Maps a hostname to a 32-bit IPv4 address. The most common record.
AAAA
Address (IPv6)
Maps a hostname to a 128-bit IPv6 address. "Quad-A" record.
CNAME
Canonical Name
Alias that points one name to another name — not an IP. www.company.com → company.com.
MX
Mail Exchange
Specifies mail servers for a domain. Has priority values. Lower number = higher priority.
PTR
Pointer (Reverse)
Reverse lookup — maps an IP back to a hostname. Stored in in-addr.arpa zone.
NS
Name Server
Identifies the authoritative nameservers for a zone. Required for every domain.
TXT
Text Record
Free-form text. Used for SPF (email auth), DKIM keys, domain verification.
SRV
Service Locator
Points clients to services by protocol. Used by SIP, XMPP, Microsoft AD.
If intranet.company.com is missing its A record in the internal zone, resolution returns NXDOMAIN. That is the most likely cause of the user's failure. One missing record silently breaks every connection attempt.
Slide 5 of 10
Recursive vs Iterative Queries
These are two different conversation styles. Understanding both is required for the exam and for reading packet captures.
Client
Your laptop
→ recursive →
Recursive
Resolver
Company DNS / ISP
→ iterative →
Root Server
.
→ iterative →
TLD Server
.com
→ iterative →
Authoritative
ns1.company.com
Recursive Query
The client says: "Find the answer for me and return it." The resolver does all the work — walking the hierarchy, caching each referral — and returns the final IP. This is how your laptop talks to the resolver. You ask once; you get the answer.
Iterative Query
The resolver says to each server: "What do you know?" Each server either answers or returns a referral to the next server in the chain. The resolver follows those referrals itself. This is how resolvers talk to root, TLD, and authoritative servers.
1Client asks resolver recursively for intranet.company.com
2Resolver asks root: "Who handles .com?" Gets referral.
3Resolver asks .com TLD: "Who handles company.com?" Gets referral.
4Resolver asks ns1.company.com: "What is intranet.company.com?" Gets A record.
5Resolver caches the answer and returns IP to client.
Slide 6 of 10
Forward & Reverse Zones
Every DNS server organizes records into zones. Forward zones answer name-to-IP. Reverse zones answer IP-to-name.
Zone Type Direction Record Used Example Use Case
Forward Zone Name → IP A, AAAA, CNAME, MX, TXT... intranet.company.com → 10.10.5.20 All normal name resolution; what clients use every day
Reverse Zone IP → Name PTR 10.10.5.20 → intranet.company.com Server logs, email spam filtering (FCrDNS), security investigations
Stub Zone Delegation only NS + glue A records Pointer to child zone's nameservers Split-horizon setups; AD-integrated DNS delegation
Reverse Zone Naming
Reverse zones use the in-addr.arpa namespace for IPv4. The IP is written backwards: 10.10.5.20 lives in the zone 5.10.10.in-addr.arpa. IPv6 reverse zones use ip6.arpa.
Zone Transfer (AXFR)
The primary authoritative server copies zone records to secondaries via TCP port 53. This is called a full zone transfer (AXFR). A partial update is an IXFR. Zone transfers must be restricted — exposing them is a recon gold mine.
The internal zone for company.com must exist on the company's internal DNS server. If the server is configured to forward unknown queries to a public resolver, it will never find internal records. The forward zone company.com must be locally authoritative for intranet.company.com to resolve.
Slide 7 of 10
TTL, Caching & the SOA Record
DNS would be unusably slow if every query walked the full hierarchy. Caching is what makes it fast — and what causes stale-record failures.
TTL — Time to Live
Every DNS record has a TTL (in seconds). When a resolver caches a record, it holds it for that duration. After TTL expires, the resolver must re-query. A low TTL means faster propagation when records change. A high TTL means fewer queries but slower updates.

Common values: 300s (5 min) for dynamic resources, 86400s (24h) for stable records.
SOA — Start of Authority
Every zone has exactly one SOA record. It contains: the primary nameserver, the responsible admin email, a serial number (incremented on every change), and timing values (refresh, retry, expire, minimum TTL). The serial number drives zone transfer replication.
SOA Record Example
company.com. SOA ns1.company.com. admin.company.com. (
  2026032901 ; serial
  3600 ; refresh (1h)
  900 ; retry (15m)
  604800 ; expire (7 days)
  300 ) ; min TTL
Stale Cache = Stale Failure
If the A record for intranet.company.com was recently added but the resolver cached an NXDOMAIN, users may fail for up to TTL seconds even after the record exists. ipconfig /flushdns (Windows) or resolvectl flush-caches (Linux) clears the local cache.
Slide 8 of 10
Troubleshooting DNS
nslookup and dig are the primary tools. Wireshark catches what the tools miss. Know the output.
nslookup (Windows / Cross-Platform)
C:\> nslookup intranet.company.com
Server: 10.10.1.1
Address: 10.10.1.1#53
 
*** Can't find intranet.company.com: NXDOMAIN
// NXDOMAIN = name does not exist in DNS. A record is missing or zone is wrong.
C:\> nslookup intranet.company.com 8.8.8.8
// Querying a specific server (8.8.8.8). Useful to compare internal vs external DNS.
dig (Linux / macOS)
$ dig intranet.company.com
;; ANSWER SECTION:
intranet.company.com. 300 IN A 10.10.5.20
// 300 = TTL in seconds. IN = Internet class. A = record type.
$ dig @10.10.1.1 company.com MX
// Query specific server for MX records
$ dig -x 10.10.5.20
// Reverse lookup (PTR)
Wireshark DNS Filter
Filter: dns   or   dns.qry.name contains "company"
Look for: query (flags: QR=0) vs response (QR=1). RCODE of 3 = NXDOMAIN. Transaction ID links each query to its response. UDP port 53 for most queries.
Help desk workflow: Run nslookup intranet.company.com from the affected machine. If it returns NXDOMAIN, the A record is missing or the machine is using the wrong DNS server. Check ipconfig /all to confirm which DNS server the client is using.
Slide 9 of 10
DNS Security — DNSSEC, DoH, DoT
DNS was built without authentication. Decades of attacks followed. Three mitigations every Network+ candidate must know.
Threats
DNS SpoofingInjecting false records into a resolver's cache. Client gets wrong IP. Called cache poisoning.
DNS HijackingAttacker changes DNS settings on the client or router. All queries go to malicious server.
DNS AmplificationDDoS vector. Small query triggers large response. Source IP spoofed to be the victim.
PharmingRedirecting hostname to attacker IP via poisoned cache or modified hosts file.
DNSSEC
What it isDNS Security Extensions. Adds cryptographic signatures to DNS records.
RRSIGDigital signature on each record set. Proves the record came from the real authoritative server.
DNSKEYHolds the public key used to verify RRSIG signatures.
LimitationAuthenticates data integrity, not confidentiality. Queries are still visible on the wire.
DoH / DoT — Privacy
DoTDNS over TLS. Encrypts DNS traffic. Uses TCP port 853. Visible as a separate stream.
DoHDNS over HTTPS. DNS queries travel inside HTTPS (port 443). Blends with web traffic.
Why it mattersPrevents ISPs, attackers, and on-path observers from reading query names in transit.
Admin noteDoH bypasses corporate DNS controls. Security teams must decide whether to allow it.
Exam tip: DNSSEC protects integrity (data has not been tampered with). DoH/DoT protect confidentiality (queries cannot be read in transit). They solve different problems and are not mutually exclusive. A resolver can implement both simultaneously.
Slide 10 of 10  |  N10-009 Obj 3.4
Resolving the Help Desk Call
The user cannot reach intranet.company.com but Google works fine. Here is the diagnostic path you now own:

Run nslookup intranet.company.com on the affected machine. If you get NXDOMAIN, the A record for intranet.company.com is missing from the internal authoritative zone. Check the company's DNS server for a forward zone covering company.com. If the zone exists but the record is absent, add the A record. If the zone does not exist, the server is forwarding everything to a public resolver that has no knowledge of internal hostnames. Run ipconfig /all to confirm which DNS server the client is pointed at.

Google works because public DNS resolves public names. Internal names require an internal authoritative zone. That is the fundamental split DNS concept — and it is why this specific failure only affects internal resources.
1 DNS runs on port 53: UDP for standard queries, TCP for zone transfers and large responses.
2 Recursive resolvers do the work for clients. Authoritative servers hold the actual zone records. They are not the same thing.
3 Record types: A=IPv4, AAAA=IPv6, CNAME=alias, MX=mail, PTR=reverse, NS=nameserver, TXT=text/auth, SRV=service.
4 TTL controls cache duration. NXDOMAIN can be cached. Flush with ipconfig /flushdns (Windows) or resolvectl flush-caches (Linux).
5 DNSSEC adds cryptographic signatures for integrity. DoT (port 853) and DoH (port 443) add confidentiality.
6 Troubleshoot with nslookup or dig. NXDOMAIN = name not found. SERVFAIL = resolver could not reach authoritative server.