Explain the DNS resolution process from client to authoritative server
Identify common DNS record types (A, AAAA, CNAME, MX, NS, PTR, SOA)
Describe DNS zone files and zone transfers
Explain the DHCP DORA process and lease lifecycle
Configure DHCP relay agents for multi-subnet environments
DNS -- The Internet's Phone Book
The Domain Name System translates human-readable domain names (like hexworth.com) into IP addresses (like 104.21.32.1). Without DNS, you would need to memorize IP addresses for every website. DNS is hierarchical, distributed, and uses port 53 (UDP for queries, TCP for zone transfers).
DNS Resolution Process
/* What happens when you type "hexworth.com" in your browser */1. Local Cache Check
Browser cache --> OS cache --> hosts file
// If found, no DNS query needed2. Recursive Resolver
Client sends query to configured DNS server (e.g., 8.8.8.8)
// This is typically your ISP's DNS or a public resolver3. Root Name Server
Resolver contacts a root server (13 root server clusters worldwide)
Root says: "I don't know hexworth.com, but .com is handled by these TLD servers"
4. TLD (Top-Level Domain) Server
Resolver contacts the .com TLD server
TLD says: "hexworth.com is delegated to these authoritative nameservers"
5. Authoritative Name Server
Resolver contacts hexworth.com's authoritative NS
Authoritative NS responds: "hexworth.com = 104.21.32.1"
6. Response Cached and Returned
Resolver caches the result (respecting TTL) and returns it to the client
DNS Record Types
Record
Purpose
Example
A
Maps hostname to IPv4 address
hexworth.com --> 104.21.32.1
AAAA
Maps hostname to IPv6 address
hexworth.com --> 2606:4700::6812
CNAME
Alias for another hostname
www.hexworth.com --> hexworth.com
MX
Mail server for the domain
hexworth.com --> mail.hexworth.com (priority 10)
NS
Authoritative nameserver
hexworth.com --> ns1.cloudflare.com
PTR
Reverse lookup (IP to hostname)
1.32.21.104.in-addr.arpa --> hexworth.com
SOA
Start of Authority -- zone metadata
Serial number, refresh, retry, expire timers
TXT
Arbitrary text (SPF, DKIM, verification)
"v=spf1 include:_spf.google.com ~all"
SRV
Service location (host + port)
_sip._tcp.hexworth.com --> sip.hexworth.com:5060
DNS Zone Files
A zone file is a text file on an authoritative DNS server that defines the records for a domain. It contains the SOA record, NS records, and all host records.
; Zone file for hexworth.com
$TTL 86400; Default TTL: 24 hours
@ IN SOA ns1.hexworth.com. admin.hexworth.com. (
2026031601; Serial (YYYYMMDDNN)3600; Refresh (1 hour)900; Retry (15 minutes)604800; Expire (7 days)86400; Minimum TTL
)
; Nameservers
@ IN NS ns1.hexworth.com.
@ IN NS ns2.hexworth.com.; Host records
@ IN A 104.21.32.1
www IN CNAME hexworth.com.
mail IN A 104.21.32.5
@ IN MX 10 mail.hexworth.com.
; Nameserver glue records
ns1 IN A 104.21.32.2
ns2 IN A 104.21.32.3
DNS Troubleshooting Commands
/* Query a specific record type */$ nslookup hexworth.com
$ nslookup -type=MX hexworth.com
/* Detailed query with dig */$ dig hexworth.com A
$ dig hexworth.com MX +short
$ dig @8.8.8.8 hexworth.com # query specific server/* Trace the full resolution path */$ dig hexworth.com +trace
/* Flush local DNS cache */C:\> ipconfig /flushdns # Windows$ sudo systemd-resolve --flush-caches # Linux (systemd)
DHCP -- Dynamic Host Configuration Protocol
DHCP automatically assigns IP addresses, subnet masks, default gateways, and DNS servers to devices. Without DHCP, every device would need manual IP configuration. DHCP uses UDP ports 67 (server) and 68 (client).
The DORA Process
DHCP uses a four-step process to assign an IP address:
D - Discover (Client --> Broadcast)
Client sends DHCP Discover to 255.255.255.255
"Is there a DHCP server out there?"
// Source IP: 0.0.0.0 (client has no IP yet)O - Offer (Server --> Client)
Server responds with an IP offer
"Here's 192.168.1.50 with a 24-hour lease"
// Includes: IP, mask, gateway, DNS, lease timeR - Request (Client --> Broadcast)
Client accepts the offer (broadcast so other servers know)
"I'll take 192.168.1.50 please"
// Broadcast because client still doesn't have the IP assignedA - Acknowledge (Server --> Client)
Server confirms the assignment
"Confirmed. 192.168.1.50 is yours for 24 hours."
// Client configures its network stack and starts using the IP
DHCP Lease Lifecycle
T1 Timer (50%)At 50% of the lease, the client attempts to renew directly with the original DHCP server (unicast).
T2 Timer (87.5%)If renewal fails, at 87.5% the client broadcasts a renewal request to any DHCP server.
Expiration (100%)If no server responds, the lease expires and the client must restart DORA from scratch.
ReleaseClient can voluntarily release its lease (ipconfig /release). The IP returns to the pool immediately.
DHCP Relay Agent
DHCP Discover messages are broadcasts -- they do not cross routers. When the DHCP server is on a different subnet, a DHCP relay agent (configured on the router) forwards DHCP broadcasts as unicast to the server.
/* Configure DHCP relay on a Cisco router */Router(config)# interface gi0/0 # interface facing clientsRouter(config-if)# ip helper-address 10.0.0.5# DHCP server IP/* ip helper-address also forwards:
- DNS (port 53)
- TFTP (port 69)
- NetBIOS (ports 137, 138)
- TACACS (port 49) */
Common DHCP Issue:
If clients get 169.254.x.x (APIPA) addresses, DHCP is failing. Check: Is the DHCP server running? Is ip helper-address configured on the gateway? Is the DHCP scope exhausted? Is there a rogue DHCP server on the network?
Key Takeaways
DNS resolves names to IPs through a hierarchical chain: cache, recursive resolver, root, TLD, authoritative
Key DNS records: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), NS (nameserver), PTR (reverse)
Zone files define all DNS records for a domain on the authoritative server
DHCP assigns IPs automatically via DORA: Discover, Offer, Request, Acknowledge
DHCP relay (ip helper-address) is required when server and clients are on different subnets
169.254.x.x (APIPA) means DHCP failed -- the client self-assigned a link-local address