📂 Course: Active Directory Administration 📦 Module: 5 of 8 🎯 Exam: AZ-800 ⏱ Read time: ~26 min
AZ-800 Exam Alignment AZ-800
Deploy and manage DNS and DHCP services: Configure AD-integrated DNS zones, understand SRV records, set up DHCP scopes and failover, and integrate DNS and DHCP to support Active Directory.
Know why AD-integrated DNS zones are preferred over standard primary/secondary zones for AD environments
Understand the role of SRV records in AD — domain controllers register these at startup to advertise their services
Know DHCP scope, exclusion range, reservation, and option configuration
Understand DHCP failover and its two modes: Hot Standby and Load Balance
Exam Tip: AZ-800 tests DNS heavily. Know that AD-integrated zones use multi-master replication (any DC can accept updates), replicate via AD replication (not zone transfers), and can use secure dynamic updates only. Also know that if SRV records are missing (e.g. after DNS corruption), re-register them with netlogon service restart or nltest /dsregdns.
DNS and DHCP are the silent foundations that make Active Directory function. Without DNS, domain controllers cannot be located and Kerberos authentication fails. Without DHCP, clients cannot receive IP addresses to communicate with the network. Both services integrate deeply with AD — understanding this integration is essential for any administrator responsible for a Windows domain environment.
🌐 Active Directory-Integrated DNS Zones
AD DS requires DNS to function. When you install the first domain controller, the AD DS setup wizard installs and configures DNS automatically. AD-integrated zones are the recommended zone type for all AD environments.
Zone Type
Storage
Replication
Dynamic Updates
Use For AD?
AD-Integrated
AD DS database (NTDS.dit), replicated via AD
Multi-master — any DC/DNS server can accept updates. Replicates via AD replication, not DNS zone transfers.
Secure only — only domain-joined machines can register records
✅ Yes — recommended
Primary
Text file (zone.dns) on single server
One-way via zone transfer to secondary servers
Secure or non-secure
❌ No — single point of failure
Secondary
Read-only copy, text file
Receives zone transfers from primary only
No dynamic updates
❌ No — read-only copy
SRV Records — How Clients Find Domain Controllers
When a domain controller starts the NETLOGON service, it automatically registers SRV records in DNS. These records are how clients locate services in the domain:
SRV Record
Purpose
_ldap._tcp.techcareers.local
Points to LDAP servers (all DCs). Used by clients to find a DC for directory queries.
_kerberos._tcp.techcareers.local
Points to Kerberos KDC servers (all DCs). Used for authentication.
_ldap._tcp.dc._msdcs.techcareers.local
DC locator records. Used by domain-joined machines to find a DC during startup.
_ldap._tcp.pdc._msdcs.techcareers.local
Points specifically to the PDC Emulator DC.
_ldap._tcp.gc._msdcs.techcareers.local
Points to Global Catalog servers.
⚠️ Missing SRV Records — The Hidden AD Killer
If SRV records disappear from DNS (corrupted zone, DNS scavenging misconfiguration, manual deletion), clients cannot locate domain controllers. Symptoms include: logon failures, “domain not found” errors, Group Policy not applying, and Kerberos errors. Fix by restarting the NETLOGON service on each DC (Restart-Service netlogon) or running nltest /dsregdns — this triggers re-registration of all SRV records.
🔌 DHCP Integration with Active Directory
DHCP servers in an AD environment must be authorised in Active Directory before they will serve IP addresses. This prevents rogue DHCP servers from handing out incorrect addresses.
DHCP Console› IPv4 › New Scope
DHCP Console — DC01.techcareers.local | IPv4
🔌 DHCP
🏠 DC01.techcareers.local
📱 IPv4
🎼 Scope [10.0.1.0]
🔄 Address Pool
⏳ Leases
⚡ Reservations
⚙️ Scope Options
⚙️ Server Options
Scope: London Workstations [10.0.1.0/24]
Setting
Value
Address Range
10.0.1.1 — 10.0.1.254
Exclusions
10.0.1.1 — 10.0.1.20 (servers/infrastructure)
Lease Duration
8 days
Option 003 Router
10.0.1.1
Option 006 DNS
10.0.1.10, 10.0.1.11 (DC01, DC02)
Option 015 DNS Domain
techcareers.local
PowerShell — DNS & DHCP Configuration
# Create an AD-integrated DNS zoneAdd-DnsServerPrimaryZone-Name'techcareers.local'-ReplicationScope'Domain'-DynamicUpdate'Secure'# Add a conditional forwarderAdd-DnsServerConditionalForwarderZone-Name'partner.com'-MasterServers 8.8.8.8 -ReplicationScope'Domain'# Re-register SRV records after DNS issueRestart-Service netlogon
# Authorise DHCP server in Active DirectoryAdd-DhcpServerInDC-DnsName'DC01.techcareers.local'-IPAddress'10.0.1.10'# Create a DHCP scopeAdd-DhcpServerv4Scope-Name'London-Workstations'-StartRange'10.0.1.21'-EndRange'10.0.1.254'-SubnetMask'255.255.255.0'-LeaseDuration'8.00:00:00'# Configure scope options (router, DNS servers, DNS domain name)Set-DhcpServerv4OptionValue-ScopeId'10.0.1.0'-Router'10.0.1.1'-DnsServer'10.0.1.10','10.0.1.11'-DnsDomain'techcareers.local'# Configure DHCP failover (Hot Standby)Add-DhcpServerv4Failover-Name'London-Failover'-ScopeId'10.0.1.0'-PartnerServer'DC02.techcareers.local'-Mode'HotStandby'-ServerRole'Active'
💡 Best Practices
Always use AD-integrated DNS zones — they provide multi-master updates, AD-replicated replication, and secure dynamic updates without requiring zone transfers
Configure domain controllers as their own primary DNS server pointing to 127.0.0.1 or the DC’s own IP, with a secondary pointing to another DC
Never point domain clients to external DNS servers (8.8.8.8) as their primary — they must resolve internal AD DNS records first
Enable DHCP failover for every production scope — a single DHCP server outage will prevent new clients from getting IP addresses
Use Load Balance mode (50/50 split) for DHCP failover when both DHCP servers are in the same site; use Hot Standby when they are in different sites
Set DHCP Option 015 (DNS Domain Name) and Option 006 (DNS Servers) at scope level so clients automatically get the correct DNS configuration
🎓 Interview Q&A
Q: What is the difference between a DNS conditional forwarder and a stub zone?
A conditional forwarder forwards queries for a specific DNS domain to a designated DNS server (e.g. forward all queries for partner.com to 192.168.1.50). It is a simple static configuration — the forwarder doesn’t know about the partner’s zone structure; it just sends queries to a server. A stub zone also resolves queries for another domain, but it maintains a partial copy of the target zone containing only NS (Name Server) records. Stub zones automatically update when NS records change — making them more resilient than conditional forwarders for long-term relationships. Stub zones are preferred when you need automatic NS record updates (e.g. in complex multi-domain forest trust scenarios).
Q: Why must DHCP servers be authorised in Active Directory?
DHCP authorisation in AD prevents rogue DHCP servers from handing out incorrect IP addresses, default gateways, or DNS server addresses to clients — an attack that could intercept or redirect network traffic. When a Windows DHCP server starts, it checks Active Directory for its own entry in the list of authorised DHCP servers. If it finds itself in the list, it starts serving leases. If not, it shuts down and logs an event. Note: this protection only works for Windows DHCP servers — non-Windows DHCP servers (Linux, network appliances) bypass this check entirely and must be controlled at the network switch level (DHCP snooping).
Q: A newly joined workstation cannot log on. DNS and DC are reachable. What DHCP-related issue could cause this?
The most likely DHCP issue is that the workstation received incorrect DNS server addresses from DHCP — pointing to an external or wrong DNS server instead of the domain’s internal DNS. This prevents the machine from resolving AD SRV records needed for DC location and Kerberos. Check the workstation’s IP configuration with ipconfig /all and verify: (1) the IP address is in the correct subnet, (2) the DNS server addresses point to domain controllers (not 8.8.8.8 or ISP DNS), and (3) the DNS suffix is techcareers.local. If wrong, check DHCP scope options 006 (DNS servers) and 015 (DNS domain name).
🎯 AZ-800 Mock Test
Module 5 — DNS & DHCP Integration
5 questions · Scenario-based · Pass mark: 70%
Question 1 of 5
After migrating AD DNS from a standard primary zone to an AD-integrated zone, what key benefit is gained regarding zone updates?
AOnly the PDC Emulator DC can accept DNS updates, improving write consistency
BAll domain controllers running DNS can accept dynamic updates (multi-master), and the zone replicates via AD replication instead of zone transfers
CExternal clients on the internet can now perform secure updates to the DNS zone
DDNS zone transfers are no longer required between primary and secondary DNS servers
✅ Correct: B. AD-integrated DNS zones use multi-master replication — any DC running the DNS server role can accept DNS updates. The zone data is stored in the AD database and replicates via AD replication, not DNS zone transfers. This eliminates the single point of failure of a standard primary zone and makes DNS more resilient.
Question 2 of 5
Users report they cannot log on to the domain. You confirm the DCs are online and reachable. Running nslookup _ldap._tcp.techcareers.local returns no results. What is the most likely cause?
ADHCP is not providing correct IP addresses to clients
BThe domain functional level is too low to support SRV records
CKerberos tickets have expired and need to be re-issued
DAD SRV records have been removed from DNS — clients cannot locate a domain controller to authenticate against
✅ Correct: D. The _ldap._tcp.techcareers.local SRV record is used by clients to locate domain controllers. If it returns no results, SRV records have been deleted or the DNS zone is corrupted. Fix: restart the NETLOGON service on each DC (Restart-Service netlogon) to trigger SRV record re-registration, or run nltest /dsregdns.
Question 3 of 5
A new DHCP server has been installed on the network but clients on that subnet are not receiving leases from it. The server is online and the scope is configured. What must you do?
AAuthorise the DHCP server in Active Directory using Add-DhcpServerInDC
BAdd the DHCP server’s computer account to the Domain Admins group
CRestart the DHCP server service on the domain controller
DCreate a DHCP reservation for the new server in the existing scope
✅ Correct: A. Windows DHCP servers must be authorised in Active Directory before they will serve leases. An unauthorised DHCP server detects this and shuts itself down to prevent rogue DHCP activity. Run Add-DhcpServerInDC -DnsName 'server.domain.local' -IPAddress 'x.x.x.x' or use the DHCP console to authorise.
Question 4 of 5
You want DHCP failover so that if the primary DHCP server fails, the secondary takes over all lease responsibilities. Both servers are in separate sites. Which DHCP failover mode is most appropriate?
ALoad Balance mode — both servers share 50% of leases at all times
BActive-Active mode — both servers handle leases simultaneously with auto-rebalancing
CHot Standby mode — one server is active, the other is passive and takes over only when the primary fails
DSplit scope — each server handles 80/20 of the scope range
✅ Correct: C.Hot Standby mode keeps one server active and one passive. The standby server activates only when the primary fails. This is recommended for servers in different sites to avoid IP conflicts and ensure clean failover. Load Balance mode is better suited for same-site deployments where both servers are equally accessible.
Question 5 of 5
A client workstation’s DNS settings show 8.8.8.8 as its primary DNS server. The workstation cannot authenticate to the domain. What is the correct fix?
AUpdate the DHCP scope Option 006 (DNS Servers) to point to internal domain controllers, then release and renew the lease on the client
BAdd a DNS forwarder on the DC pointing to 8.8.8.8 to route internal queries externally
CRejoin the workstation to the domain — domain join will fix the DNS settings automatically
DRestart the NETLOGON service on the domain controller to re-register DNS records
✅ Correct: A. 8.8.8.8 (Google DNS) cannot resolve internal AD SRV records or hostnames, so the client cannot locate a DC. The root cause is a misconfigured DHCP scope Option 006. Fix the scope option to point to domain controllers, then on the client run ipconfig /release and ipconfig /renew to get the corrected DNS settings. Always point AD clients to internal DNS first.
🔒
This module is locked — Complete Module 4 and pass its mock test to unlock this module.
Complete the quiz above (70%+) to unlock Module 6: AD Sites & Replication