Lesson 24 of 60 intermediate

DNS Deep Dive

The service that breaks everything indirectly

Open interactive version (quiz + challenge)

Real-world analogy

DNS is the switchboard of the internet. Every time you type a name, a DNS server converts it to a number. When the switchboard is slow, confused, or lying, every app looks broken — but the phones are fine.

What is it?

DNS is the naming layer of the internet and every enterprise. It rarely breaks spectacularly, but it quietly breaks everything else when it misbehaves. Mastering DNS mental models is a junior-to-mid jump.

Real-world relevance

Internal users can’t access the new portal. External users can. A junior checks split-horizon config and finds the internal DNS zone missing the new record. Adds it, TTL low. Fifteen minutes later everyone is back. No firewall team needed.

Key points

Recursive vs authoritative — Recursive resolvers ask on behalf of your client (ISP resolver, 1.1.1.1, 8.8.8.8). Authoritative servers hold the real answers (e.g., the DNS servers responsible for contoso.com). Every lookup eventually reaches an authoritative server.
Record types you must know — A: name → IPv4. AAAA: name → IPv6. CNAME: alias to another name. MX: mail servers for a domain. TXT: arbitrary text (SPF/DKIM/verification). SRV: service discovery (AD uses this). PTR: reverse IP → name.
TTL and caching — Every record has a TTL (time to live) telling resolvers how long to cache the answer. Low TTLs = fast change, higher load. High TTLs = efficient, slow change. Know how to clear caches (ipconfig /flushdns, scutil equivalents).
Split-horizon DNS — Enterprises often serve different answers internally vs externally (e.g., ‘portal.bank.local’ returns an internal IP on the LAN and a DMZ IP from the internet). Great for security; confusing when misconfigured.
DNS forwarders and conditional forwarders — A forwarder says ‘I don’t know; ask this upstream DNS.’ A conditional forwarder says ‘for this zone specifically, ask this server.’ Essential in M&A scenarios and hybrid cloud environments.
Common DNS failures — Wrong DNS server in client config, stale cache, missing/expired records, typos in zone files, mismatched TTLs, AD SRV records not reachable, DNSSEC misconfig, NXDOMAIN on legitimate records.
Tools: dig, nslookup, Resolve-DnsName — dig (Linux/macOS): rich output, show query path. nslookup: works everywhere but terse. Resolve-DnsName (PowerShell): modern Windows equivalent. Learn all three; interviewers love this topic.
DNSSEC — trust but verify — Signs DNS answers so resolvers can verify authenticity. Mostly invisible — until a misconfiguration breaks resolution for some TLDs. Know the name and the failure mode.

Code example

// DNS diagnostic flow

1) What does the client see?
   ipconfig /all                    # which DNS servers?
   nslookup portal.contoso.com
   Resolve-DnsName portal.contoso.com -Server 10.10.10.10

2) Ask different resolvers to isolate
   nslookup portal.contoso.com 1.1.1.1
   dig @8.8.8.8 portal.contoso.com

3) Clear local cache if stale
   ipconfig /flushdns
   Clear-DnsClientCache

4) Check zone authority (where the record should live)
   dig NS contoso.com
   whois contoso.com

5) Record-level check
   dig MX contoso.com
   dig TXT contoso.com
   dig _dmarc.contoso.com TXT

Line-by-line walkthrough

1. DNS diagnostic flow
2. Step 1 — what the client sees
3. Check configured DNS servers
4. Resolve via default
5. Resolve via a specific server
6. Blank separator
7. Step 2 — isolate resolver problems
8. Force 1.1.1.1
9. Force 8.8.8.8
10. Blank separator
11. Step 3 — clear local cache
12. Windows flush
13. PowerShell cache clear
14. Blank separator
15. Step 4 — zone authority
16. dig NS records
17. Whois ownership
18. Blank separator
19. Step 5 — record-specific checks
20. MX
21. TXT
22. DMARC TXT

Spot the bug

New CEO’s email to customer keeps going to spam.
Junior tells the sender ‘your email is fine; the customer’s spam filter is the problem.’

Need a hint?

Which DNS records should you check before blaming the recipient?

Show answer

Check the sender’s own DNS: SPF (TXT), DKIM (TXT selector), DMARC (TXT _dmarc) records. Missing or broken SPF/DKIM/DMARC is a leading cause of legitimate mail being marked spam. Validate these before escalating externally.

Explain like I'm 5

DNS is the phonebook. Your phone asks ‘what’s the number for portal?’ and someone else answers. If the phonebook is wrong, you call the wrong number. If the phonebook is slow, everyone complains their phone is broken.

Fun fact

Cloudflare’s public DNS service (1.1.1.1) commits to never logging your personal DNS queries — audited annually. Many enterprises still use their own internal DNS anyway because of AD SRV records and split-horizon needs.

Hands-on challenge

Using dig, query an A record, an MX record, and a TXT record for a public domain. Explain each result in plain English. Then flush your local cache and re-run.

More resources

DNS explained (Cloudflare) (Cloudflare Learning)
dig manual (ISC BIND docs)
DNS for admins (deep dive) (John Savill)

Open interactive version (quiz + challenge) ← Back to course: IT Jobs Bootcamp