October 30, 2026 · CertCrack Blog

How DNS Works: How Your Browser Turns a Domain Name Into an IP Address

Every time you type a website name like certcrack.com into a browser, something invisible happens before a single byte of the page loads: your computer has to find out which IP address that name points to. That job belongs to the Domain Name System, or DNS — often called the phone book of the internet. Without it, you would have to memorise strings of numbers for every site you visit. DNS is one of the most-tested networking topics in entry-level certifications, and it is also one of the first things you troubleshoot on a real help desk. Here is how it actually works, step by step.

Names for humans, numbers for machines

Computers find each other with IP addresses, such as 203.0.113.42 for IPv4 or a longer hexadecimal address for IPv6. People, on the other hand, remember names. DNS bridges the two: it is a global, distributed database that maps names to addresses (and to other information, as you will see below). It is distributed rather than stored on one giant server, which is why it keeps working even when parts of it fail, and why no single organisation owns the whole thing.

A domain name reads from specific to general, right to left. In www.certcrack.com, "com" is the top-level domain (TLD), "certcrack" is the second-level domain, and "www" is a host or subdomain. Above the TLDs sits the root of the whole tree, written as a dot. That hierarchy is what makes lookups efficient: a query walks down the tree, asking each level which server knows the next part.

The lookup, step by step

When you type a domain into your browser, the journey usually goes like this:

1. Local caches first. Your browser checks its own DNS cache, then your operating system checks its cache. If you visited the site recently, the answer may already be sitting there and the lookup ends here.
2. The recursive resolver. If there is no cached answer, your computer asks a recursive resolver — usually run by your internet provider, your employer, or a public service such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. "Recursive" means this server does the legwork for you: it chases the answer through the hierarchy and returns a single result.
3. The root servers. The resolver asks one of the 13 root server identities (letters A through M, each backed by many servers around the world using anycast routing). A root server does not know the address of certcrack.com, but it knows which servers handle the .com TLD, so it answers with a referral: "ask the .com servers."
4. The TLD servers. The resolver asks a .com TLD server, which likewise does not know the final address but knows which authoritative servers handle certcrack.com, and refers the resolver onward.
5. The authoritative name servers. These are the servers that actually hold the domain's records — typically run by the domain owner's DNS host. The authoritative server returns the real answer, for example the A record giving the site's IPv4 address.
6. Back to you, and cached along the way. The resolver hands the answer to your computer, and every server in the chain caches it for a limited time (see TTL below), so the next visitor's lookup is faster.

Most lookups take only tens of milliseconds, and thanks to caching, most of them never go beyond step 1 or 2.

Record types: DNS stores more than addresses

A zone file — the set of records an authoritative server holds for a domain — contains several record types, and exam questions love to test which is which:

• A record — maps a name to an IPv4 address. The workhorse of the web.
• AAAA record — maps a name to an IPv6 address (the four A's stand for the longer, 128-bit address).
• CNAME record — an alias: one name pointing to another name, so www.example.com can point to example.com.
• MX record — tells other servers where to deliver email for the domain.
• TXT record — free-form text, used for things like proving you own a domain and for email security policies (SPF, DKIM, DMARC).
• NS record — names the authoritative servers for a domain or subdomain.
• SOA record — marks the start of a zone and carries administrative details, including timers for secondary servers.
• PTR record — reverse DNS: maps an IP address back to a name, used by email servers and logging.
• SRV record — points to a service on a specific host and port, used by services such as Microsoft Active Directory and VoIP.

When a question asks "which record do you change to point a website at a new server?", the answer is almost always the A record (or AAAA for IPv6). When it asks about mail delivery, think MX.

Caching and TTL: why DNS changes take time

Every DNS record carries a Time To Live (TTL), measured in seconds, that tells resolvers how long they may cache it. A TTL of 3600 means "trust this answer for one hour." Caching is what makes DNS fast and resilient, but it is also why a DNS change does not take effect everywhere instantly: resolvers holding the old answer keep serving it until its TTL expires. That is the real explanation behind "DNS propagation" — there is no single moment when a change goes live everywhere; old cached answers simply age out, one resolver at a time. Lowering the TTL before a planned move is the standard trick to make a change spread faster.

DNS security: spoofing, and the fixes

Because classic DNS queries travel unencrypted and unauthenticated, attackers have ways to abuse it. In DNS spoofing (or cache poisoning), an attacker tricks a resolver into caching a false answer, sending visitors to a fake site. DNS tunnelling smuggles data out of a network hidden inside DNS queries, which most firewalls allow through by default. Exam questions also pair DNS with typosquatting — registering a lookalike domain — to catch users who mistype a name.

Two defences matter most. DNSSEC adds cryptographic signatures to DNS records, so a resolver can verify that an answer genuinely came from the domain's authoritative server and was not altered in transit. Encrypted DNS — DNS over TLS (DoT, port 853) and DNS over HTTPS (DoH, port 443) — encrypts the query itself, so nobody on the network path can read or tamper with it. DNSSEC proves the answer is authentic; DoT and DoH keep the question private. They solve different problems, and exam questions sometimes ask you to tell them apart.

Troubleshooting DNS like a technician

"Can I reach the site by IP but not by name?" is the classic clue that DNS is the problem, not the network. The toolkit is small and appears in A+ and Network+ questions constantly:

• nslookup (Windows, macOS, Linux) — query a name and see which server answered and what it returned.
• dig (macOS, Linux) — the more detailed version, showing the full answer, authority, and query time.
• ipconfig /flushdns (Windows) — clears a stale local cache; the macOS and Linux equivalents vary by version.
• Ping the name, then ping the IP — if the IP works but the name does not, you have isolated the fault to DNS.
• Check the client's configured DNS server addresses, and whether the problem follows one machine (local cache or settings) or every machine (the resolver or the records themselves).

A detail worth memorising: DNS normally runs on UDP port 53, because queries are small and fast, but it switches to TCP port 53 for larger responses and for zone transfers between servers. Questions that mention port 53 are almost always about DNS.

Exam connection

DNS shows up across the certifications this site covers. CompTIA A+ Core 1 (220-1201) tests DNS concepts and the troubleshooting commands above. Network+ (N10-009) goes deeper into record types, the resolution process, and DNS troubleshooting scenarios. CCNA (200-301) expects you to understand DNS as part of IP services, alongside DHCP. Security+ (SY0-701) approaches it from the threat side: DNS spoofing and poisoning, DNS tunnelling as an exfiltration method, and typosquatting. The same facts keep reappearing in different clothes: if you can explain the lookup chain, name the record types, and say what TTL does, you can answer most DNS questions on any of these exams.

Practical takeaway

Think of DNS as a chain of referrals: your computer asks a resolver, the resolver climbs down from the root to the TLD to the authoritative server, and caching at every step keeps it fast. When something breaks, work the chain backwards — local cache, resolver settings, records — and check whether the name or the number is the thing that fails. That mental model covers the exam questions, and it is exactly how you will debug "the internet is down" tickets that turn out to be DNS all along.

FAQ

What is the difference between a recursive resolver and an authoritative server?

A recursive resolver does the work for the client: it chases the answer through the hierarchy and returns one result. An authoritative server holds the actual records for a domain and gives the final, definitive answer. Your ISP or a public DNS service runs the resolver; your domain's DNS host runs the authoritative servers.

Why does a DNS change take hours to be visible everywhere?

Because resolvers cache old answers until their TTL expires. There is no central switch to flip: each resolver drops the old record on its own schedule, so the change spreads gradually rather than instantly.

If DNS goes down, is the internet down?

Effectively, yes, for name-based browsing — even though the network itself is fine, nothing can be found by name. That is why DNS is treated as critical infrastructure, and why misconfigured DNS is one of the most common causes of "the site is down" incidents that are not really outages at all.