DNS explained for CompTIA Network+ (N10-009)

What does DNS actually do?

DNS, the Domain Name System, turns human friendly names into machine addresses. You type a name your brain can hold, and DNS hands your computer the IP address it needs to send traffic. Name in, number out, that is the core job.

Think of the contacts app on your phone. You tap a name, not a ten digit number, and the phone dials the right line. DNS is that contacts app for the entire internet, sitting between the names people use and the addresses machines route on. The value is not only convenience. Names are stable while addresses change, so DNS gives you one clean layer of indirection between the two. Move a website to a new server, update a single record, and every visitor follows automatically without changing anything on their side.

For Network+ this is why DNS touches so many other topics. Web browsing, email delivery, and even security controls all lean on it, so a broken DNS record can look exactly like a broken server even when the server is perfectly healthy. Learn the lookup path and the main record types and you can reason through most of what both the exam and a real help desk will ask.

Where does DNS sit on the Network+ exam?

On N10-009, DNS lives in Domain 1.0, Networking Concepts, under objective 1.4, common networking ports, protocols, services, and traffic types. The single fact to lock in: DNS uses port 53, on both UDP and TCP.

Most lookups are tiny, so DNS uses UDP on port 53 for ordinary queries. UDP is fast and connectionless, which fits a request that usually fits in one packet. TCP on port 53 covers the heavier cases: zone transfers that copy records between servers, responses too large for a single UDP datagram, and DNSSEC signed answers. So when an exam question asks which transport DNS uses, the honest answer is both, and knowing the reason will beat a memorized flashcard every time.

DNS is old and carefully specified, and the core behavior still traces back to RFC 1035. That stability is why the same port and the same record types have anchored the protocol for decades. If you want the full blueprint and where DNS fits among the other Domain 1.0 concepts, our CompTIA Network+ overview lays out the domains and their weights.

How does a DNS lookup travel from name to IP address?

A lookup hops through a short chain of servers. Your device asks a resolver, the resolver asks a root server, then a top level domain server, then the authoritative server that finally holds the answer.

Start at your device. A small piece of the operating system called the stub resolver takes the request first. It checks its own cache and the local hosts file, and if it has no answer it forwards the query to a configured recursive resolver, often run by your ISP or a public provider.

The recursive resolver does the real legwork. If the answer is not already cached, it walks the hierarchy from the top. It asks a root server, which does not know the address but knows who runs each top level domain, so it points toward the TLD servers for .com, .org, or whatever suffix applies. The TLD server likewise does not hold the final answer, but it knows which authoritative name servers are responsible for the specific domain. The authoritative server is the one with the real record, and it returns the answer back up the chain.

Then caching takes over. Every record carries a TTL, a time to live measured in seconds, that tells resolvers how long they may keep the answer before asking again. High TTLs cut traffic and speed up repeat lookups. Low TTLs let changes spread faster. That one number explains why a DNS change can feel instant for one person and slow for another. They are simply holding cached answers with different amounts of life left.

Which DNS record types does N10-009 test?

Records are the individual entries inside a DNS zone, each one a name mapped to a value of a specific type. The exam expects you to recognize the common types on sight and know what each one points to.

The email authentication cluster is worth a second look, because it surprises people. SPF lists which servers may send mail for a domain, DKIM publishes a public key so receivers can verify a message signature, and DMARC tells receivers what to do when SPF or DKIM checks fail. All three live inside plain TXT records, which is how a single record type quietly underpins a large share of modern email trust and shows up again when you study for Security+.

• A: maps a hostname to an IPv4 address. This is the everyday workhorse record.
• AAAA: maps a hostname to an IPv6 address. Same idea as an A record, just the longer address format.
• CNAME: an alias that points one name at another name rather than directly at an address.
• MX: the mail exchanger, which names the mail server that accepts email for a domain and carries a priority value so backups are clear.
• TXT: free form text, used today mostly for email authentication, since SPF, DKIM, and DMARC all publish their policies as TXT records.
• NS: the name server record, which delegates a zone to the authoritative servers responsible for answering for it.
• PTR: the pointer record, the reverse of an A record, mapping an IP address back to a name for reverse DNS lookups.
• SOA: the start of authority, one per zone, holding zone metadata such as the primary server, an admin contact, a serial number, and default timers.

What DNS problems show up at a help desk?

Most DNS tickets take one of four shapes: the wrong resolver, a stale cache, a bad record, or a name that genuinely does not exist. Recognize the four and you can triage a DNS complaint in minutes.

Two tools settle most of these quickly. nslookup and dig let you query a specific record type, and even a specific server, so you can prove whether an answer is wrong at the source or only stale on the client. That distinction is the whole game in DNS troubleshooting. Our guide to Network+ troubleshooting tools walks through the exact commands and how to read what they return.

• Wrong resolver: a device points at a DNS server it cannot reach or should not use, so names fail while raw IP addresses still work. When IP works and names do not, check the configured resolver first.
• Stale cache: a record changed, but a resolver or the local device is still serving the old cached answer until the TTL expires. On Windows, ipconfig /flushdns clears the local cache and forces a fresh lookup.
• Bad record: a typo in an A record, a missing MX, or a CNAME aimed at the wrong target sends traffic somewhere wrong or nowhere at all. The server is healthy, the record is not.
• NXDOMAIN: the resolver returned a definite answer that the name does not exist. Sometimes that is correct, and sometimes it means a record was never created or was deleted by mistake.

How to make DNS stick before exam day

DNS rewards understanding over memorizing. Hold three anchors and the topic falls into place. First the job: names to IP addresses. Second the path: device to resolver to root to TLD to authoritative, then cached according to TTL. Third the records: A and AAAA for addresses, CNAME for aliases, MX for mail, TXT for email authentication, NS for delegation, PTR for reverse lookups, and SOA for zone metadata. Add the one hard fact, port 53 on both UDP and TCP, and you have covered what objective 1.4 asks about DNS. The fastest way to cement any of it is active recall, so quiz yourself on the record types and the lookup order until the sequence feels obvious rather than memorized. When you are ready to drill it in context, our study mode keeps DNS right next to the ports, protocols, and troubleshooting topics it connects to.