Module 08 - Slide 1 of 22

DNS & Name Resolution

Master the Domain Name System - the foundation of network communication

What You'll Learn

  • DNS architecture and hierarchy
  • Zone types and configuration
  • Record types (A, AAAA, CNAME, MX, PTR, SRV)
  • Forwarding and conditional forwarding
  • Troubleshooting DNS issues

Why It Matters

  • Active Directory requires DNS
  • Users access resources by name
  • Email routing depends on MX records
  • Service discovery uses SRV records
  • Most outages trace to DNS issues
FAILSAFE Context: After the datacenter incident, DNS servers were corrupted. Understanding DNS is critical for recovery - without it, nothing works by name.
DNS translates names to addressesYour laptopwww.corp.localhuman-readablequeryDNS serverlookup tablewww → 10.0.0.42mail → 10.0.0.50answerWeb server10.0.0.42machine-readableWithout DNS, every connection needs a remembered IPDNS is the phonebook of the internet (and your AD)
Module 08 - Slide 2 of 22

DNS Fundamentals

DNS (Domain Name System) translates human-readable names to IP addresses. It's a distributed, hierarchical database.

DNS Resolution Flow

Client
hexworth.local
→
Local DNS
DC01
→
Forwarder
8.8.8.8
→
Root DNS
.

Key Concepts

  • FQDN - Fully Qualified Domain Name (e.g., dc01.hexworth.local)
  • Zone - A portion of the DNS namespace managed by a server
  • Record - An entry mapping a name to data (IP, alias, mail server)
  • TTL - Time To Live, how long to cache a record
Recursive resolution: how a lookup walks the treeClient1Recursive DNS2Root .3TLD .com4Auth corp.comAAnswer ✓1. Query www.corp.com?2. Who handles .com?3. Who handles corp.com?4. What is www.corp.com?
Module 08 - Slide 3 of 22

DNS Hierarchy

DNS uses a tree structure with the root at the top:

                    . (Root)
                    │
        ┌───────────┼───────────┐
        │           │           │
       com         org         local
        │                       │
    google                  hexworth
        │                       │
      www                     dc01
DNS namespace is a tree, root on topRoot ..com.org.localmicrosoftcontosocorpacmewwwmaildc01apiFQDN reads right-to-left: www.contoso.com.host . subdomain . SLD . TLD . root

Domain Levels

Domain Levels

Level Example Description
Root . (dot) Top of hierarchy, 13 root server clusters worldwide
TLD .com, .org, .local Top-Level Domain, managed by registries
Second-Level hexworth.local Your organization's domain
Subdomain dc01.hexworth.local Hosts and child domains
DNS namespace is a tree, root on topRoot ..com.org.localmicrosoftcontosocorpacmewwwmaildc01apiFQDN reads right-to-left: www.contoso.com.host . subdomain . SLD . TLD . root
Module 08 - Slide 4 of 22

DNS Zone Types

Primary Zone

  • Read/write copy of zone data
  • Only one primary per zone
  • Source for zone transfers
  • Can be AD-integrated

Secondary Zone

  • Read-only copy of zone data
  • Multiple secondaries allowed
  • Provides redundancy
  • Gets data via zone transfer

AD-Integrated Zones

When DNS is AD-integrated:

  • Zone data stored in Active Directory (not files)
  • Replicated with AD replication
  • Multi-master - any DC can update
  • Secure dynamic updates
  • Recommended for AD environments
Best Practice: Always use AD-integrated zones in Active Directory environments. This provides automatic replication, security, and fault tolerance.
Four ways to host a DNS zonePrimaryread-write mastercorp.com.dnsflat filewritable✓ updates here✗ single pointBest for: simplesmall orgSecondaryread-only mirrorcorp.com.dnscopy from primaryread-only✓ redundancy⚠ AXFR/IXFRBest for: HA withoutAD integrationAD-Integratedmulti-masterin AD databasereplicates with ADwritable on any DC✓ secure dynamic✓ ACL via ADBest for: AD DSdomainsStubjust NS recordsSOA + NS onlyno recordspointer only✓ tiny footprintdelegation onlyBest for: cross-zonerouting hints
Module 08 - Slide 5 of 22

Forward & Reverse Lookup

Forward Lookup Zone

Name → IP Address

Query: dc01.hexworth.local Answer: 192.168.1.10
  • Most common lookup type
  • Users and apps use this
  • Contains A, AAAA, CNAME records

Reverse Lookup Zone

IP Address → Name

Query: 10.1.168.192.in-addr.arpa Answer: dc01.hexworth.local
  • Used for logging, security
  • Email spam checking
  • Contains PTR records
Note: Reverse lookup zones use the IP address backwards with .in-addr.arpa suffix. For subnet 192.168.1.0/24, create zone 1.168.192.in-addr.arpa
Two directions: name to IP, IP to nameForward LookupA or AAAA recordwww.corp.localresolves to10.0.0.42Zone: corp.localwww IN A 10.0.0.42Reverse LookupPTR record10.0.0.42reverses towww.corp.localZone: 0.0.10.in-addr.arpa42 IN PTR www.corp.local
Module 08 - Slide 6 of 22

DNS Record Types

Type Purpose Example
A Maps hostname to IPv4 address dc01 → 192.168.1.10
AAAA Maps hostname to IPv6 address dc01 → 2001:db8::1
CNAME Alias pointing to another name mail → exchange01.hexworth.local
MX Mail exchanger for domain hexworth.local → mail.hexworth.local (priority 10)
Common record types and what they storeAwww → 10.0.0.42IPv4AAAAwww → 2001:db8::1IPv6CNAMEstore → wwwaliasMXcorp → mail.corpmailSRV_ldap._tcp → dc01serviceTXT"v=spf1 -all"textPTR42 → www.corpreverseNScorp → dc01name srvSOAauthority datazoneCAAletsencrypt.orgcert authDNSKEYDNSSEC pubkeyDNSSECEach record has a TTL

DNS Record Types (cont.)

Type Purpose Example
PTR Reverse lookup (IP to name) 10.1.168.192 → dc01.hexworth.local
SRV Service location _ldap._tcp → dc01.hexworth.local:389
NS Name server for zone hexworth.local → dc01.hexworth.local
SOA Start of Authority (zone info) Serial, refresh, retry, expire, TTL
Active Directory Critical: SRV records are essential for AD. Clients use them to find domain controllers, LDAP servers, Kerberos, and Global Catalogs.
Common record types and what they storeAwww → 10.0.0.42IPv4AAAAwww → 2001:db8::1IPv6CNAMEstore → wwwaliasMXcorp → mail.corpmailSRV_ldap._tcp → dc01serviceTXT"v=spf1 -all"textPTR42 → www.corpreverseNScorp → dc01name srvSOAauthority datazoneCAAletsencrypt.orgcert authDNSKEYDNSSEC pubkeyDNSSECEach record has a TTL
Module 08 - Slide 7 of 22

SRV Records & Active Directory

Active Directory relies heavily on SRV records for service discovery:

# Key AD SRV Records in _msdcs.hexworth.local: _ldap._tcp.dc._msdcs.hexworth.local → dc01.hexworth.local:389 _kerberos._tcp.dc._msdcs.hexworth.local → dc01.hexworth.local:88 _gc._tcp.hexworth.local → dc01.hexworth.local:3268 _kpasswd._tcp.hexworth.local → dc01.hexworth.local:464

SRV Record Format

_service._protocol.name TTL class SRV priority weight port target

_ldap._tcp.hexworth.local. 600 IN SRV 0 100 389 dc01.hexworth.local. Priority: 0 (lower = preferred) Weight: 100 (load balancing between same priority) Port: 389 (LDAP port) Target: dc01.hexworth.local (the server)
Troubleshooting Tip: If clients can't find domain controllers, check SRV records first: nslookup -type=srv _ldap._tcp.dc._msdcs.hexworth.local
SRV records: how clients find servicesWorkstationneeds to log onqueryPS> Resolve-DnsName _ldap._tcp.corp.local -Type SRVName Priority Weight Port Target_ldap._tcp.corp 0 100 389 dc01.corp.localDC01LDAP on 389Key AD SRV records:_ldap._tcpdomain controllers_kerberos._tcpauthentication_gc._tcpglobal catalog_kpasswd._tcppassword changeAD adds these automatically when DCs come onlineDelete them at your peril, no client can find AD
Module 08 - Slide 8 of 22

DNS Forwarding

Forwarders send queries for external domains to another DNS server instead of using root hints.

Standard Forwarders

  • Forward ALL external queries
  • Typically ISP or public DNS
  • Common: 8.8.8.8, 1.1.1.1
  • Reduces root server load
# Point all external queries to Google DNS PS C:\> Set-DnsServerForwarder -IPAddress "8.8.8.8","8.8.4.4"
# Expected output: # ────────────────────────────── IPAddress # ────────────────────────────── 8.8.8.8 8.8.4.4

Conditional Forwarders

  • Forward SPECIFIC domains only
  • Used for partner/trust domains
  • More targeted than standard
  • Essential for AD trusts
# Forward partner.com queries to their DNS PS C:\> Add-DnsServerConditionalForwarderZone -Name "partner.com" -MasterServers "10.20.1.10"
# Expected output: # ────────────────────────────── ZoneName ZoneType # ────────────────────────────── partner.com Forwarder
Best Practice: Use conditional forwarders for trusted partner domains rather than secondary zones. This maintains separation while enabling resolution.
Forwarder: send unknown queries upstreamClientgithub.com?Internal DNSauthoritative for corpnot authoritative for .comforward8.8.8.8Google publichandles .com .net etcTwo flavors:Conditional forwarderIf query is for partner.com → ask 10.20.0.5Useful for cross-org or merged AD forestsCatch-all forwarderIf nothing else matches → ask 8.8.8.8Avoids hitting root + TLD servers directly
Module 08 - Slide 9 of 22

Dynamic DNS Updates

Dynamic updates allow clients to automatically register their DNS records:

Setting Description When to Use
None No dynamic updates allowed Static-only environments
Nonsecure and Secure Any client can register Non-AD environments only
Secure Only Only authenticated clients Recommended for AD
Dynamic updates: clients register themselvesPC01got 10.0.0.78updateDNS Servercreates A recordcorp.local zonePC01 A 10.0.0.78TTL: 3600 Type: DHCPPC01got 10.0.0.92updateDNS Serveroverwrites A recordcorp.local zonePC01 A 10.0.0.92replaced 10.0.0.78Secure dynamic update (AD-integrated only):Kerberos-authenticated, only the original owner can modify the record

How It Works

How It Works

  1. Client boots and gets IP from DHCP
  2. Client sends dynamic update to DNS server
  3. DNS server authenticates client (if secure)
  4. A record created/updated for client
  5. DHCP can also register PTR records

Lock down the zone so only authenticated AD clients can register records.

# Restrict dynamic updates to authenticated clients only PS C:\> Set-DnsServerPrimaryZone -Name "hexworth.local" -DynamicUpdate "Secure"
# Expected output: # ───────────────────────────────────────────────────────────── ZoneName DynamicUpdate ZoneType # ───────────────────────────────────────────────────────────── hexworth.local Secure Primary
Dynamic updates: clients register themselvesPC01got 10.0.0.78updateDNS Servercreates A recordcorp.local zonePC01 A 10.0.0.78TTL: 3600 Type: DHCPPC01got 10.0.0.92updateDNS Serveroverwrites A recordcorp.local zonePC01 A 10.0.0.92replaced 10.0.0.78Secure dynamic update (AD-integrated only):Kerberos-authenticated, only the original owner can modify the record
Module 08 - Slide 10 of 22

DNS Troubleshooting

Test the resolver from the command linenslookup, Resolve-DnsName, ipconfigPS> Resolve-DnsName www.corp.local Name Type TTL Section IPAddress www.corp.local A 600 Answer 10.0.0.42PS> Resolve-DnsName -Server 8.8.8.8 microsoft.com bypass internal DNS, force a specific resolverPS> Clear-DnsClientCache wipe the local stub resolver cachePS> ipconfig /flushdns same idea, traditional commandPS> _

Essential Commands

Essential Commands

Resolve a hostname to its IP address using the default DNS server.

# Look up the A record for a server by name PS C:\> nslookup dc01.hexworth.local
# Expected output: # ───────────────────────────────────────────────── Server: dc01.hexworth.local Address: 192.168.1.10 Name: dc01.hexworth.local Address: 192.168.1.10

Query a specific record type like MX to find the mail servers for a domain.

# Look up the mail exchanger records for the domain PS C:\> nslookup -type=mx hexworth.local
# Expected output: # ───────────────────────────────────────────────── hexworth.local MX preference = 10, mail exchanger = mail.hexworth.local

Use Resolve-DnsName for richer PowerShell output with object properties.

# PowerShell-native DNS query with typed output PS C:\> Resolve-DnsName -Name "dc01.hexworth.local" -Type A
# Expected output: # ───────────────────────────────────────────────── Name Type TTL Section IPAddress # ───────────────────────────────────────────────── dc01.hexworth.local A 3600 Answer 192.168.1.10
Test the resolver from the command linenslookup, Resolve-DnsName, ipconfigPS> Resolve-DnsName www.corp.local Name Type TTL Section IPAddress www.corp.local A 600 Answer 10.0.0.42PS> Resolve-DnsName -Server 8.8.8.8 microsoft.com bypass internal DNS, force a specific resolverPS> Clear-DnsClientCache wipe the local stub resolver cachePS> ipconfig /flushdns same idea, traditional commandPS> _

Cache Management Commands

Flush the local DNS cache on a client machine when stale records cause problems.

# Clear the local client DNS resolver cache PS C:\> Clear-DnsClientCache

On the DNS server itself, flush the server-side cache to force fresh lookups.

# Clear the DNS server's forwarding cache PS C:\> Clear-DnsServerCache

Inspect what records are currently cached on the local client.

# Display all entries in the client DNS cache PS C:\> Get-DnsClientCache
# Expected output: # ───────────────────────────────────────────────────────────── Entry RecordName Data TTL # ───────────────────────────────────────────────────────────── dc01.hexworth.local A 192.168.1.10 3542 mail.hexworth.local A 192.168.1.20 1800

Common Issues

  • Stale records: Enable scavenging to remove old records
  • Missing SRV records: Re-register DC with nltest /dsregdns
  • Wrong DNS server: Check client DNS settings
  • Forwarder timeout: Verify forwarder connectivity
Test the resolver from the command linenslookup, Resolve-DnsName, ipconfigPS> Resolve-DnsName www.corp.local Name Type TTL Section IPAddress www.corp.local A 600 Answer 10.0.0.42PS> Resolve-DnsName -Server 8.8.8.8 microsoft.com bypass internal DNS, force a specific resolverPS> Clear-DnsClientCache wipe the local stub resolver cachePS> ipconfig /flushdns same idea, traditional commandPS> _
Module 08 - Slide 11 of 22

DNS Scavenging

Scavenging automatically removes stale (old) DNS records that are no longer valid.

Scavenging removes stale records over timeDay 0PC01 registers A record → timestamp setNo-refresh interval (7 days), Refresh interval (7 days)Day 1-7no-refresh window → timestamp will not updatePC01 keeps using same IP, no churn on DNSDay 8-14refresh window → PC01 re-registers, timestamp updatesActive records stay aliveDay 15+if PC01 never came back → record marked staleScavenger job (runs weekly) deletes itStale records cause hard-to-debug name collisions otherwise

Why Scavenging Matters

Scavenging removes stale records over timeDay 0PC01 registers A record → timestamp setNo-refresh interval (7 days), Refresh interval (7 days)Day 1-7no-refresh window → timestamp will not updatePC01 keeps using same IP, no churn on DNSDay 8-14refresh window → PC01 re-registers, timestamp updatesActive records stay aliveDay 15+if PC01 never came back → record marked staleScavenger job (runs weekly) deletes itStale records cause hard-to-debug name collisions otherwise

Why Scavenging Matters

Why Scavenging Matters

  • DHCP clients may get new IPs but old records remain
  • Decommissioned servers leave orphaned records
  • Stale records cause failed connections
  • Zone becomes cluttered and hard to manage

Configuration

Turn on automatic scavenging at the server level with a 7-day interval.

# Enable scavenging on the DNS server every 7 days PS C:\> Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00
# Expected output: # ───────────────────────────────────────────────── ScavengingState ScavengingInterval # ───────────────────────────────────────────────── True 7.00:00:00
Scavenging removes stale records over timeDay 0PC01 registers A record → timestamp setNo-refresh interval (7 days), Refresh interval (7 days)Day 1-7no-refresh window → timestamp will not updatePC01 keeps using same IP, no churn on DNSDay 8-14refresh window → PC01 re-registers, timestamp updatesActive records stay aliveDay 15+if PC01 never came back → record marked staleScavenger job (runs weekly) deletes itStale records cause hard-to-debug name collisions otherwise

Why Scavenging Matters (cont.)

Enable aging on the specific zone so stale records get timestamped.

# Turn on record aging for the hexworth.local zone PS C:\> Set-DnsServerZoneAging -Name "hexworth.local" -Aging $true
# Expected output: # ───────────────────────────────────────────────── ZoneName AgingEnabled # ───────────────────────────────────────────────── hexworth.local True

Verify the current scavenging configuration on the server.

# Check the current scavenging settings PS C:\> Get-DnsServerScavenging
# Expected output: # ───────────────────────────────────────────────── NoRefreshInterval RefreshInterval ScavengingInterval ScavengingState # ───────────────────────────────────────────────── 7.00:00:00 7.00:00:00 7.00:00:00 True
Caution: Scavenging must be enabled on BOTH the server AND the zone. Enable on only one or two DNS servers to prevent accidental record deletion.
Scavenging removes stale records over timeDay 0PC01 registers A record → timestamp setNo-refresh interval (7 days), Refresh interval (7 days)Day 1-7no-refresh window → timestamp will not updatePC01 keeps using same IP, no churn on DNSDay 8-14refresh window → PC01 re-registers, timestamp updatesActive records stay aliveDay 15+if PC01 never came back → record marked staleScavenger job (runs weekly) deletes itStale records cause hard-to-debug name collisions otherwise
Module 08 - Slide 12 of 22

Module Summary

Key Takeaways

  • DNS is hierarchical - root → TLD → domain → hostname
  • AD-integrated zones provide security and replication
  • SRV records are critical for Active Directory
  • Forwarders handle external resolution
  • Secure dynamic updates prevent unauthorized registrations
  • Scavenging keeps zones clean
Module 8 takeawaysResolutionrecursive walkHierarchyroot → TLD → domainZonesAD-Integrated winsRecordsA, CNAME, MX, SRVForwardingconditional + catch-allDynamicDHCP + secure updateScavengingstale records purgedReady for DNS labs and quiz

PowerShell Quick Reference

List every DNS zone hosted on the server to see what is configured.

# Show all forward and reverse lookup zones PS C:\> Get-DnsServerZone
# Expected output: # ───────────────────────────────────────────────── ZoneName ZoneType IsAutoCreated IsDsIntegrated # ───────────────────────────────────────────────── hexworth.local Primary False True 1.168.192.in-addr.arpa Primary False True _msdcs.hexworth.local Primary False True

Create a new A record to map a hostname to an IP address in a zone.

# Add a host (A) record for a new server PS C:\> Add-DnsServerResourceRecordA -Name "web01" -ZoneName "hexworth.local" -IPv4Address "192.168.1.50"
# Expected output: # ───────────────────────────────────────────────── HostName RecordType Timestamp RecordData # ───────────────────────────────────────────────── web01 A 0 192.168.1.50
Module 8 takeawaysResolutionrecursive walkHierarchyroot → TLD → domainZonesAD-Integrated winsRecordsA, CNAME, MX, SRVForwardingconditional + catch-allDynamicDHCP + secure updateScavengingstale records purgedReady for DNS labs and quiz

Listing and Testing

View all DNS records within a specific zone to audit its contents.

# List every record in the hexworth.local zone PS C:\> Get-DnsServerResourceRecord -ZoneName "hexworth.local"
# Expected output: # ───────────────────────────────────────────────── HostName RecordType Type RecordData # ───────────────────────────────────────────────── @ SOA 6 [dc01.hexworth.local] @ NS 2 dc01.hexworth.local. dc01 A 1 192.168.1.10 web01 A 1 192.168.1.50

Use Resolve-DnsName to test name resolution from the client perspective.

# Query DNS the PowerShell way PS C:\> Resolve-DnsName -Name "web01.hexworth.local"
# Expected output: # ───────────────────────────────────────────────── Name Type TTL Section IPAddress # ───────────────────────────────────────────────── web01.hexworth.local A 3600 Answer 192.168.1.50
Start GUI Lab → PowerShell Lab → Take Quiz →
Module 8 takeawaysResolutionrecursive walkHierarchyroot → TLD → domainZonesAD-Integrated winsRecordsA, CNAME, MX, SRVForwardingconditional + catch-allDynamicDHCP + secure updateScavengingstale records purgedReady for DNS labs and quiz
Course Home