How DNS Works: Resolvers, Record Types and Troubleshooting

DNS terminology: resolvers, zones and name servers

• Stub resolver: the small client in your operating system that asks for an answer and waits.
• Recursive resolver: the server, usually run by your ISP, company or a public DNS provider, that does the full lookup on your behalf.
• Root servers: the top of the hierarchy, known by 13 names from a.root-servers.net to m.root-servers.net, each run as many anycast instances.
• TLD servers: servers for top-level domains such as .com, .org and .in.
• Authoritative servers: the servers that hold the actual records for a domain, set by its owner.
• Zone: the portion of the namespace an authoritative server is responsible for, such as example.com.

DNS queries normally use UDP port 53, with TCP port 53 used for large responses and zone transfers. The TCP/IP guide explains how those transport protocols differ.

How a DNS lookup works: recursive and iterative queries

Your device sends a recursive query to its resolver, meaning "give me the final answer". The resolver then makes iterative queries, where each server replies with either the answer or a referral to the next server to ask.

1. The browser and operating system check their own caches and the hosts file.
2. If there is no cached answer, the stub resolver asks the recursive resolver for www.example.com.
3. The resolver asks a root server, which refers it to the .com TLD servers.
4. The TLD server refers it to the authoritative name servers for example.com.
5. The authoritative server returns the record, and the resolver caches it and returns it to your device.

Every record carries a TTL (time to live) in seconds. Resolvers and clients may reuse a cached answer until the TTL expires. This is what people call DNS propagation: nothing is pushed around the internet; old answers simply expire from caches at different times. Lowering the TTL a day before a planned change shortens that window.

Common DNS record types

Email authentication lives in TXT records. SPF lists servers allowed to send mail for the domain, DKIM publishes a public key under a selector such as s1._domainkey.example.com, and DMARC at _dmarc.example.com tells receivers what to do when checks fail. These records help defend against spoofing, a topic covered in cybersecurity basics.

example.com.         3600  IN  A      192.0.2.10
example.com.         3600  IN  AAAA   2001:db8::10
www.example.com.     3600  IN  CNAME  example.com.
example.com.         3600  IN  MX     10 mail.example.com.
example.com.         3600  IN  TXT    "v=spf1 mx -all"
_dmarc.example.com.  3600  IN  TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
example.com.         3600  IN  CAA    0 issue "letsencrypt.org"

Querying DNS with dig and nslookup

dig is standard on Linux and macOS; nslookup is available on Windows, Linux and macOS. Both let you ask a specific server and see exactly what it returns.

dig example.com A +short          # IPv4 address only
dig example.com AAAA              # full answer with TTL
dig example.com MX +short         # mail servers
dig _dmarc.example.com TXT        # DMARC policy
dig @1.1.1.1 example.com          # ask a specific resolver
dig +trace example.com            # follow root -> TLD -> authoritative
dig -x 192.0.2.10                 # reverse (PTR) lookup

nslookup example.com
nslookup -type=mx example.com
nslookup example.com 8.8.8.8

Read the ANSWER SECTION for the records and the number before IN for the remaining TTL. The status field shows NOERROR, NXDOMAIN (the name does not exist) or SERVFAIL (the resolver could not get a valid answer).

The hosts file and encrypted DNS

The hosts file maps names to addresses locally and is usually checked before DNS. It lives at /etc/hosts on Linux and macOS and at C:\Windows\System32\drivers\etc\hosts on Windows. It is handy for testing a site on a new server, but a forgotten entry is a common cause of confusing faults, and malware sometimes edits it.

Classic DNS travels unencrypted. DNS over TLS (DoT) uses TCP port 853 and DNS over HTTPS (DoH) uses port 443 to encrypt queries between the client and resolver, which protects them from eavesdropping on the local network. Organisations often run their own encrypted resolver so security filtering and logging still work, as discussed in our network security overview.

Troubleshooting DNS step by step

1. Confirm basic connectivity: ping a known IP address. If that fails, the problem is not DNS.
2. Check which resolver you are using with ipconfig /all on Windows or resolvectl status on Linux systems running systemd-resolved.
3. Look up the name with dig or nslookup and note the status code.
4. Ask a different resolver and the authoritative server directly; if they disagree, a cache is still holding an old answer.
5. Check the hosts file for stale entries.
6. Flush the local cache with ipconfig /flushdns on Windows or resolvectl flush-caches with systemd-resolved, then test again.

Practical exercise: trace and document a domain

Choose a domain you own or manage, or use example.com.

1. Run dig +trace and note each root, TLD and authoritative server in the chain.
2. Query the A, AAAA, MX, NS, TXT, SOA and CAA records and write down each value and TTL.
3. Run the same A query twice against your resolver and watch the TTL count down.
4. Add a test entry to your hosts file, confirm the browser uses it, then remove it.

You are done when you have a one-page record sheet for the domain and can explain which server answered each step of the trace. DNS labs like this appear in the Networking Foundation course.

Common mistakes

• Blaming DNS before testing whether the target IP address is reachable at all.
• Making a DNS change with a long TTL still in place and expecting it to take effect at once.
• Publishing more than one SPF TXT record for a domain, which makes SPF evaluation fail.
• Leaving test entries in the hosts file after a migration.
• Pointing a CNAME at an IP address instead of a hostname.

Frequently asked questions