AZ-802 DNS and DHCP explained
Implement and manage an on-premises and hybrid networking infrastructure is worth 10–15% of AZ-802, and in practice it is two services: DNS and DHCP. Name resolution covers AD integration, zones and records, forwarding, hybrid resolution with Azure, DNS policies and DNSSEC. IP addressing covers DHCP scopes, reservations, failover and troubleshooting. Remote access, VPN, IPAM and the other networking roles from AZ-800 are not in this outline.
DNS
AD integration
An AD-integrated zone is stored in Active Directory rather than a file, so every DC running DNS can update it, and it supports secure dynamic updates, where only authenticated domain members can register records. Its replication scope decides where copies live:
| Scope | Replicates to |
|---|---|
| All DNS servers in the forest | DCs running DNS in every domain |
| All DNS servers in the domain | DCs running DNS in this domain |
| All domain controllers in the domain | Every DC, for compatibility with older DCs |
| Custom application partition | DCs you enlist |
The _msdcs zone holds the SRV records clients use to find domain controllers. If they are missing, nltest /dsgetdc fails and a DC can reregister them by restarting the Netlogon service.
Zones and records
Primary zones are writable; secondary zones are read-only copies via zone transfer; stub zones hold only the NS, SOA and glue records of another zone and update themselves. Record types to know: A, AAAA, CNAME, MX, SRV, PTR (in reverse lookup zones) and NS. Aging and scavenging remove stale dynamic records; both the server and the zone need it enabled.
Forwarding
| Mechanism | Use |
|---|---|
| Forwarder | Everything the server cannot resolve goes to one set of servers |
| Conditional forwarder | Queries for one domain go to specific servers |
| Stub zone | Like a conditional forwarder, but learns the target’s name servers automatically |
| Root hints | Fallback when no forwarder answers |
Conditional forwarders can be stored in AD and replicated to other DNS servers, which saves configuring each one.
Hybrid name resolution
Azure private DNS zones are only answered from inside Azure, by the platform resolver at 168.63.129.16, which on-premises servers cannot reach. Azure DNS Private Resolver bridges the gap:
- An inbound endpoint gives on-premises DNS servers an IP address in the virtual network. Point a conditional forwarder for the private zone at it.
- An outbound endpoint with a forwarding ruleset lets Azure resources resolve on-premises domains by forwarding to your DNS servers.
Before Private Resolver existed, the same result needed DNS forwarder VMs in Azure; you may still see that design in answer options.
DNS policies and DNSSEC
DNS policies make a Windows DNS server answer differently depending on the client subnet, the time of day, the interface the query arrived on or the query type. Typical uses are split-brain DNS, geo-location based answers and blocking queries for a domain. You define client subnets and zone scopes, then add a query resolution policy with Add-DnsServerQueryResolutionPolicy.
DNSSEC signs a zone so resolvers can verify that answers are authentic. The key signing key signs the DNSKEY set; the zone signing key signs the records. A validating resolver needs a trust anchor. On clients, the Name Resolution Policy Table, set through Group Policy, decides whether DNSSEC validation is required for a namespace.
DHCP
Scopes and options
A scope is a range of addresses for one subnet, with exclusions and a lease duration. Options, such as the router (003), DNS servers (006) and DNS domain name (015), can be set per server, per scope or per reservation, and the most specific wins. A reservation ties an address to a MAC address. Superscopes group scopes for one physical network with several logical subnets. A DHCP relay agent or the router’s IP helper forwards requests from subnets without a DHCP server.
A DHCP server in an AD domain must be authorised in AD before it hands out leases.
High availability
| Method | How it works | Use |
|---|---|---|
| Failover, load balance | Both servers serve clients, split by percentage | Two servers in one site |
| Failover, hot standby | One active, one standby that takes over | Main site plus backup site |
| Split scope | Each server holds part of the range, e.g. 80/20 | Older method; no lease sharing |
DHCP failover works between two servers per scope and replicates lease information. Maximum client lead time (MCLT) limits how long a partner can extend leases on its own, and state switchover interval decides when a partner assumes the other is down.
Troubleshooting addresses
A client with a 169.254.x.x address (APIPA) did not reach a DHCP server: check the relay agent, the scope’s free addresses, authorisation and the firewall. An address conflict points at a static assignment inside the scope; enable conflict detection or add an exclusion. In Azure, never set a static IP inside the guest OS: assign it on the NIC instead, or the VM can lose connectivity.
Sample questions
Question 1. On-premises servers must resolve records in an Azure private DNS zone named corp.internal. You deploy Azure DNS Private Resolver in the linked virtual network, which is reachable over VPN. What should you configure on the on-premises DNS servers?
- A. A forwarder to 168.63.129.16
- B. A secondary zone for corp.internal
- C. A conditional forwarder for corp.internal to the inbound endpoint’s IP address
- D. A conditional forwarder to the outbound endpoint’s IP address
Show answer
Answer: C
On-premises DNS servers should send queries for corp.internal to the Private Resolver’s inbound endpoint through a conditional forwarder. The platform resolver 168.63.129.16 is not reachable from outside Azure. A secondary zone needs zone transfers, which private DNS zones do not offer. The outbound endpoint handles queries from Azure to on-premises, the opposite direction.
Want more questions like this? Full AZ-802 practice tests →
Question 2. Clients in the 10.20.0.0/16 subnet must receive the internal address of app.contoso.com, while all other clients receive the public address, from the same Windows DNS servers. What should you implement?
- A. A client subnet, a zone scope and a query resolution policy
- B. A stub zone for contoso.com
- C. A conditional forwarder for app.contoso.com
- D. DNS round robin with both A records
Show answer
Answer: A
DNS policies with a client subnet and a separate zone scope let one Windows DNS server return different answers for the same name depending on the client’s subnet, which is split-brain DNS. A stub zone and a conditional forwarder change where queries go, not the answer per client. Round robin returns the addresses in rotation to everyone.
Want more questions like this? Full AZ-802 practice tests →
Question 3. A new Windows DHCP server is installed in the domain and a scope is activated, but clients on its subnet still receive no addresses. The server's event log shows it is not serving clients. What is the most likely cause?
- A. Option 003 is not configured
- B. The DHCP server is not authorised in Active Directory
- C. Conflict detection attempts are set to 0
- D. No reservations exist in the scope
Show answer
Answer: B
In an AD domain, a DHCP server must be authorised in Active Directory before it serves clients; an unauthorised server stops the service from leasing. A missing router option leaves clients with an address but no gateway. Conflict detection and reservations do not stop leases for other clients.
Want more questions like this? Full AZ-802 practice tests →
What to practise
Create an AD-integrated zone with secure updates, a stub zone and a conditional forwarder. Sign a lab zone with DNSSEC and check it with Resolve-DnsName -DnssecOk. Set up a split-brain policy for one name. Then build two DHCP servers, configure failover in hot standby mode, stop the active server and watch the standby take over after the state switchover interval.