Skip to content
BytePath
BytePath v0.0.35

DNS Fundamentals

Networking Learning Path · Step 8Available

DNS is a distributed name system. This lesson separates client, recursive resolver, authoritative data, and cache so that troubleshooting does not stop at simply changing the DNS server.

Difficulty
Beginner
Duration
65 minutes
Practice
Compare queries
Quiz
3 questions

Before you start

Who is this for?

For IT beginners who want to understand name resolution correctly and diagnose it.

Prerequisites

  • IPv4 and routing basics
  • Basic idea of client and server

What you'll be able to do

  • Distinguish recursive and authoritative roles
  • place key record types
  • explain TTL, cache, and negative answers
  • narrow DNS problems with targeted queries

Practical outcome

You can draw the path client → recursive resolver → authoritative server and derive the next test from a response code.

1. Names and addresses are different layers

Section titled “1. Names and addresses are different layers”

Applications use names like www.example.com; IP routing needs a destination address. DNS does not translate every packet, but provides information that a client then uses. A successful DNS answer therefore guarantees neither routing, a reachable TCP port, nor a working web application.

A fully qualified domain name describes the position in the hierarchical namespace. From right to left are root, top-level domain, registered domain, and further labels. DNS names are not the same as URLs: https://www.example.com:443/docs additionally contains scheme, port, and path.

2. The resolution path

Section titled “2. The resolution path”
Client→Recursive Resolver→Root→TLD→Authoritative Server

The client usually works as a stub resolver and queries a configured recursive resolver. The resolver first checks its cache. If a usable answer is missing, it follows referrals through the DNS hierarchy until an authoritative server provides the data for the responsible zone.

  • Recursive resolver: answers client requests through cache and further queries.
  • Authoritative server: provides authoritative records for zones it is responsible for.
  • Root and TLD servers: refer to the next responsible level; they do not store every host address on the internet.

Enterprise resolvers can add internal zones, forwarders, filters, and logging. Any public resolver therefore cannot necessarily resolve internal names.

3. Key record types

Section titled “3. Key record types”
Record Purpose Example
A Name to IPv4 web.example.com → 192.0.2.20
AAAA Name to IPv6 web.example.com → 2001:db8::20
CNAME Alias to another name portal → web.example.com
MX Mail server for a domain Priority and target name
TXT Text data Verification, SPF, or other policies
NS Authoritative nameservers Zone delegation
PTR Reverse resolution IP address to name
SOA Zone administrative data primary server, serial number, timers

A CNAME points to a name, not directly to an IP. Mail servers from an MX record are in turn resolved by A or AAAA. Reverse DNS uses its own zones and does not appear automatically from an A record.

4. Cache and TTL

Section titled “4. Cache and TTL”

Records have a Time to Live (TTL). Resolvers may cache answers for that time. Caching reduces load and latency, but means changes are not visible everywhere at the same moment.

Even negative answers can be cached. If a name is queried shortly after it is removed, a resolver may still have the previous non-existence stored. “Propagation” is therefore often a combination of updated authoritative data, delegation, and expiring caches—not a magical global replication event.

Before a planned change, a timely reduced TTL can shorten the transition. However, it does not act retroactively on answers already stored with a higher TTL.

5. UDP, TCP, and encrypted transports

Section titled “5. UDP, TCP, and encrypted transports”

Classic DNS uses port 53 over UDP and TCP. Many normal queries run over UDP; TCP is used for certain large answers, zone transfers, and fallback situations, among other things. Modern clients can use DNS over TLS or DNS over HTTPS. These encrypted paths do not change the meaning of DNS records, but they do influence which resolver is actually queried and where diagnostics or policies apply.

6. Read response codes

Section titled “6. Read response codes”
  • NOERROR with answer: the name and requested type were answered.
  • NOERROR without a matching record: the name may exist, but not with the desired type.
  • NXDOMAIN: the queried name does not exist according to the authoritative answer.
  • SERVFAIL: the resolver could not produce a valid answer, for example due to reachability or validation errors.
  • REFUSED: the server refuses the request based on its policy.

DNSSEC signs DNS data and enables verification of authenticity and integrity. It does not encrypt the query and does not automatically make a web service trustworthy; TLS remains a separate layer.

7. Diagnosis without guesswork

Section titled “7. Diagnosis without guesswork”
Terminal window
Resolve-DnsName www.example.com -Type A
Resolve-DnsName example.com -Type MX
Terminal window
dig www.example.com A
dig example.com MX
dig @192.0.2.53 internal.example A

First check which resolver is configured and actually being used. Then compare the name, record type, response code, TTL, and server. Query the authoritative server directly when you need to distinguish cached from published zone data. Use example domains and only approved internal servers.

If the IP connection works but the name does not, DNS is plausible. If DNS answers correctly and HTTPS fails, move on to checking routing, port, TLS, and application instead of trying more resolvers.

Common mistakes

Section titled “Common mistakes”
  • Equating DNS names, URLs, and search paths.
  • Confusing NXDOMAIN with “server unreachable”.
  • Querying only A and ignoring existing AAAA answers.
  • Not considering cache and TTL after a change.
  • Expecting a public resolver for private internal zones.
  • Confusing DNSSEC with transport encryption.
Mini-lab

Trace a DNS answer

Difficulty
Beginner
Estimated time
20 min
Topics
DNS, Records, Caching
Requirements
nslookup, Resolve-DnsName or dig

Objective: Compare a configured resolver with an authoritative answer and document what each result proves.

  1. Choose a safe public example domain and query A, AAAA, MX, and NS.
  2. Record the response code, answer, TTL, and responding server.
  3. Repeat one query and explain why the TTL may decrease.
  4. Query a clearly non-existent subdomain and record the negative response.
  5. Explain which successful result proves only name resolution—not HTTPS availability.
Expected resultDifferent record types answer different questions. A cached recursive response can have a lower remaining TTL than authoritative data. A successful address answer provides a target but does not test routing, firewall, TLS, or the application.

Knowledge check

Section titled “Knowledge check”

Multiple Choice

DNS knowledge check

0 / 3

What you should now be able to do

Section titled “What you should now be able to do”
  • distinguish resolvers and authoritative servers;
  • correctly assign A, AAAA, CNAME, MX, NS, TXT, and PTR;
  • explain caching behavior with TTL and negative answers;
  • derive a meaningful next test from response code and record type.