DNS Fundamentals
Understand how readable domain names are resolved into records that computers can use to locate services.
- Certification
- CompTIA Network+
- Recommended study time
- 5h 55m
- Status
- Not started
Recommended study time
About 5h 55m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson23 min
About 2,949 words at a careful technical reading pace.
- Second pass with notes14 min
Re-read the harder parts and write your own notes.
- Work through the examples20 min
1 worked example and 3 practice questions.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Describe recursive and authoritative DNS resolution.
- Recognize A, AAAA, CNAME, MX, NS, TXT, and PTR records.
- Use DNS-specific reasoning to separate name-resolution failures from connectivity failures.
Start here
About 20 minutes of reading, in 8 short parts.
DNS is the distributed directory that turns names people can remember into addresses machines can route to. It is also, by a wide margin, the most common cause of failures that look like something else. Learning DNS properly makes you noticeably faster than colleagues who guess.
Where you meet it: Website and email failures, new service cutovers, certificate validation, Active Directory logons, and half of all 'the internet is broken' reports.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
DNS is a hierarchical, distributed, cached database. The hierarchy is read right to left: the root, then the top-level domain (com, org, uk), then the registered domain (example.com), then any subdomains (mail.example.com). No single server holds the whole database; each zone is delegated to servers that are authoritative for it.
Two roles matter. A recursive resolver works on behalf of the client, doing whatever queries are needed to produce a final answer and caching the result. An authoritative server holds the actual zone data for a domain and answers with authority. Your laptop talks to a resolver; a resolver talks to authoritative servers.
Key ideas
If you remember nothing else from this topic, remember these.
- DNS is read right to left through its hierarchy, root, then top-level domain, then registered domain, then subdomain, and no single server anywhere holds the entire database, since each zone is delegated to the servers authoritative for it.
- A recursive resolver works on behalf of a client to produce a final answer and caches it, while an authoritative server holds the actual zone data and answers with authority, and confusing which role a given server plays is a common source of misdiagnosis.
- TTL is the number of seconds any cache is allowed to keep an answer, and it directly explains why some users see a freshly changed record immediately while others still see the old value, since their resolvers hold different unexpired cached copies.
- The hosts file, when present, overrides DNS entirely for any name it lists, which makes it both a useful manual override for testing and a common source of a stubborn, hard-to-explain fault when an old entry is forgotten there.
- A CNAME record is an alias to another name and cannot coexist with other record types at the same name, which is specifically why it cannot be used at a domain's zone apex, where an SOA and NS records must also exist.
- Active Directory domain controllers publish SRV records specifically so clients can locate them, meaning a workstation pointed at the wrong DNS server can fail to log on to a domain in a way that looks identical to an account problem.
Diagnosing inbound email failure after a DNS record change
A worked example, step by step.
A company migrated its email provider yesterday. Outbound mail from the office works fine, but customers report their emails to the company are bouncing.
- 01Confirm the reported scopeAsk which direction is affected; the user confirms outbound mail from staff works normally, but inbound mail from external senders bounces with a delivery failure message.
- 02Check the relevant record typeRun nslookup -type=MX example.com to check the mail exchanger record, since inbound mail routing depends specifically on MX, not the A record used for the website.
- 03Read the returned valueThe MX record still points to the old provider's mail server, mail.oldprovider.com, even though the migration to the new provider happened yesterday.
- 04Check whether the record was actually updatedLog into the DNS zone management console and find that the MX record was in fact updated correctly to point to mail.newprovider.com two hours ago.
- 05Check the TTL that was setThe MX record's TTL was left at its original value of 86400 seconds, a full 24 hours, meaning many resolvers around the internet are still serving the old cached answer.
- 06Confirm this explains the partial symptomTest from a resolver known to have queried recently, such as a public DNS tool, and see mixed results: some report the new server, some still report the old one, matching the classic TTL-caching pattern.
- 07Apply the correct immediate actionLower the TTL for future changes going forward is the correct habit, but for this already-changed record, wait out the existing TTL window since a resolver already caching the old answer will not be forced to refresh early.
- 08Verify full recovery and document the lessonAfter the 24-hour TTL window fully elapses, confirm with the customers that inbound mail delivery has resumed, and document that future migrations must lower the TTL a day in advance of the cutover.
Outcome: The DNS record was changed correctly, but the long pre-existing TTL meant many resolvers worldwide continued serving the stale MX record for up to 24 hours, causing intermittent inbound mail bounces that resolved on their own once the TTL fully expired; the process fix was lowering the TTL well before any future cutover.
DNS Facts Worth Memorising
Worth keeping at hand while you work.
- A record
- Maps a hostname to an IPv4 address
- AAAA record
- Maps a hostname to an IPv6 address
- CNAME record
- An alias to another name; cannot coexist with other records at the same name
- MX record
- Mail exchanger for a domain, with a preference value; lower value is tried first
- TXT record
- Arbitrary text, used for SPF, DKIM, DMARC, and domain verification
- NS record
- Lists the servers authoritative for a zone
- SOA record
- Zone's primary server, admin contact, serial number, and refresh/retry timers
- PTR record
- Reverse lookup from IP address back to a hostname, held in a reverse zone
- SRV record
- Locates a service by protocol and port; used by Active Directory to find domain controllers
- TTL
- Time in seconds a cached answer may be kept before it must be re-queried
- Recursive resolver
- Performs lookups on behalf of a client and caches the result
- Authoritative server
- Holds the actual zone data and answers with authority for that zone
- Hosts file
- Local override file checked before DNS; an entry there beats any DNS answer
- Port 53
- Standard DNS port, UDP for typical queries, TCP for zone transfers or large responses
Common misunderstandings
What most beginners get wrong here.
Changing a DNS record takes effect everywhere immediately.
Resolvers around the internet may still hold a cached answer for as long as its TTL allows, so propagation can take minutes to a full day depending on the TTL that was set before the change.
A CNAME record can be used at the root of a domain, like example.com itself.
A CNAME cannot coexist with other records at the same name, and a zone apex must have SOA and NS records, so a CNAME cannot legally be placed there.
DNS failures always mean the whole internet connection is down.
DNS failure typically produces a very specific and partial symptom: names fail to resolve while the underlying IP connectivity works perfectly, which is why 'works by IP, fails by name' is the definitive signature of a DNS problem.
The hosts file is an outdated feature that no longer matters on modern systems.
The hosts file is still checked before DNS on every modern operating system, and a forgotten entry there is a real and confusing cause of faults that look like broken DNS.
A recursive resolver and an authoritative server are just two names for the same thing.
A recursive resolver does the work of finding an answer on a client's behalf and caches it, while an authoritative server holds the actual zone data being asked about; they play distinct roles in the same lookup.
Exam traps
How the question writers try to catch you out.
- A question describing 'works by IP address but fails by hostname' is testing recognition of a name resolution problem specifically, isolated from any general connectivity fault.
- MX record questions expect you to know that a lower preference value is tried first, which is the reverse of what some candidates assume.
- Expect questions distinguishing SPF, DKIM, and DMARC as all being published via TXT records, each serving a different email authentication purpose.
- A scenario describing inconsistent results across different users right after a DNS change is testing understanding of TTL and caching, not a broken or incomplete change.
- Domain login failure questions that describe a workstation pointed at a public DNS server instead of the internal DNS server are testing SRV record and Active Directory DNS dependency, not an account or password issue.
Check yourself
Answer in your head first, then reveal. This is not scored.
A website was moved to a new server yesterday, and some users see the new site while others still see the old one. What single DNS concept explains this?
Why should the TTL on a record be lowered a day before a planned migration rather than at the moment of the change?
A domain-joined workstation cannot log on to the domain, and the error suggests it cannot find a domain controller, but the account and password are confirmed correct. What should you check?
Why can a CNAME record not be placed at the apex of a domain, such as directly at example.com?
Inbound mail to a company bounces, but outbound mail and the website both work fine. Which record type should be checked first, and why?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
DNS maps names to typed records. A client usually asks a recursive resolver, which checks its cache and, when necessary, follows referrals from root servers to top-level-domain servers and authoritative servers. The authoritative server holds the source records for a DNS zone. Time to live, or TTL, tells caches how long a response may be reused.
Why It Matters
A service can be reachable by IP address but fail by name, making DNS a distinct troubleshooting layer. Administrators also use DNS for mail routing, service aliases, verification, and reverse lookups. Understanding caches and authority explains why a correct record change may not appear everywhere immediately.
How It Works
- A client sends a query to a recursive resolver.
- On a cache miss, the resolver follows referrals toward an authoritative server.
- The returned typed record is cached for its TTL.
Where You See It
- Website access, email routing, service aliases, domain verification, and reverse lookups.
Key Terms
- Resolver
- A service that obtains DNS answers for clients, often using recursion and caching.
- Authoritative server
- A server that holds the official records for a DNS zone.
- A / AAAA
- Records mapping a name to an IPv4 or IPv6 address.
- CNAME
- A record making one name an alias of another name.
- MX
- A record identifying mail servers for a domain.
- TTL
- The period a resolver may cache a DNS response.
Examples
- A browser asks its configured resolver for a site's address before it can start the web connection.
- After an A record changes, some users may receive the older cached address until its previous TTL expires.
Common Problems
- Wrong record value
- Stale cache
- Missing zone record
- Unreachable resolver
- Record-type confusion
How It Fails
- A service can work by IP but fail by hostname.
- Some users can receive an old cached answer after a record change.
- A broken delegation can prevent resolvers from finding authority.
How to Troubleshoot
- Confirm basic IP connectivity first.
- Query the expected record type with nslookup or dig.
- Compare resolvers, inspect authority, and account for TTL.
Practical Knowledge
- Use A/AAAA for addresses, CNAME for aliases, MX for mail, and TXT for published text.
- Separate resolver, cache, authoritative record, and service failures.
Exam Coverage
- Recursive and authoritative resolution
- Common DNS record types
- TTL, caching, and name-resolution troubleshooting
Interview Questions
- What is the difference between a recursive resolver and an authoritative server?
- A site works by IP but not name. What does that indicate?
Worked examples
Each calculation is shown one step at a time, then you try it yourself before revealing the answer.
Trace a DNS lookup step by step
A workstation opens www.example.com for the first time. What happens before the first packet reaches the web server?
- 1. Local checksThe resolver checks its own cache, then the hosts file. A stale entry here explains a machine that reaches the wrong server while everyone else is fine.
- 2. Recursive resolverThe query goes to the configured DNS server, usually learned by DHCP. If that server has a cached answer within its TTL, it replies immediately.
- 3. Root and TLDWith no cache, the resolver asks a root server, which refers it to the .com name servers, which refer it to the authoritative servers for example.com.
- 4. Authoritative answerThe authoritative server returns the A record (IPv4) or AAAA record (IPv6) for www.example.com.
- 5. Cache and connectThe answer is cached for its TTL, then the workstation opens a TCP connection to that IP on port 443.
Answer: Name resolution is a chain: cache → hosts file → recursive resolver → root → TLD → authoritative. Test the chain with nslookup or dig; if the IP is correct but the page fails, the fault is below DNS.
Now you try
A site works by IP but not by name. Where is the fault?
Which record type maps a name to an IPv6 address?
Why does a record change take hours to appear everywhere?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Query A, AAAA, and MX records for a domain and compare the answers.
- 02When testing a failure, compare access by hostname with access by a known IP address.