Windows Server · Lesson 13
Review DNS zones, records, forwarders, recursion, interfaces, dynamic updates, and zone transfers while preserving the name resolution Active Directory and required services depend on.
DNS hardening is not about deleting unfamiliar records. It is about understanding which names and services must resolve, then reducing only the exposure that is clearly unnecessary.
Lesson Snapshot
Learning objectives
Review Windows Server DNS zones, records, forwarders, interfaces, recursion, dynamic updates, and transfer settings safely.
Explain why DNS is especially important on an Active Directory domain controller.
Use DNS Manager, Event Viewer, PowerShell, and client-side resolution tests to inspect DNS without deleting records blindly.
Recognize suspicious or overly broad DNS settings while preserving required name resolution.
Distinguish between forward lookup zones, reverse lookup zones, conditional forwarding, recursion, and zone transfers.
Verify DNS from an authorized client after any DNS configuration change.
Core concepts
A DNS administrative boundary containing records for a namespace, such as a domain or reverse-lookup network.
A DNS entry such as A, AAAA, CNAME, MX, NS, PTR, or SRV that maps names to addresses, services, or other DNS information.
A DNS server that receives queries this server cannot answer locally and attempts to resolve them on its behalf.
The process of resolving a DNS query by contacting other DNS servers until an answer is found.
Allows authorized clients or services to create or update DNS records automatically instead of relying only on manual changes.
Copies DNS zone data to another DNS server, usually for an authorized secondary-server relationship.
Core idea
On a Windows domain, authentication, Group Policy, domain discovery, and many applications depend on correct DNS behavior.
Active Directory warning
Records containing names such as _ldap, _kerberos, and _msdcs are normal in Active Directory environments.
Tool map
Server Manager → Tools → DNSQuick action
Win + R → dnsmgmt.msc
Primary GUI for reviewing DNS servers, zones, records, forwarders, server interfaces, recursion-related settings, and zone transfers.
DNS Manager → server → Forward Lookup ZonesQuick action
Expand the required zone and inspect records.
Review the zone that supports the scenario-required domain or application namespace.
DNS Manager → server → Reverse Lookup ZonesQuick action
Review PTR records when reverse resolution is part of the environment.
Reverse zones may be useful for logging, troubleshooting, and applications, but not every environment requires every reverse zone.
DNS Manager → right-click the DNS server → PropertiesQuick action
Review Interfaces, Forwarders, Advanced, Monitoring, and other applicable tabs.
Server-wide settings can affect every zone and client using the DNS server.
DNS Manager → right-click the zone → PropertiesQuick action
Review General, Name Servers, Zone Transfers, and applicable security settings.
Zone-level changes can affect domain registration, replication, secondary servers, and client resolution.
Event Viewer → Applications and Services Logs → DNS ServerQuick action
Review recent DNS Server warnings and errors.
Event evidence helps explain service failures, loading problems, update issues, and some configuration changes.
Start → search PowerShell → Run as administrator when requiredQuick action
Use DNS Server cmdlets for read-only inspection.
Cmdlets such as Get-DnsServerZone, Get-DnsServerResourceRecord, Get-DnsServerForwarder, and Get-DnsServerRecursion are useful when the DNS role tools are installed.
DNS and Active Directory
Active Directory clients use DNS to locate domain controllers and directory services.
Service records help clients find LDAP, Kerberos, Global Catalog, and other domain services.
Domain controllers register important DNS records automatically when DNS and Netlogon-related functions are healthy.
Domain clients normally need working DNS to find domain controllers and retrieve Group Policy reliably.
Broken DNS can appear to be an authentication problem because clients cannot locate the correct domain services.
DNS problems can interfere with communication between domain controllers and other infrastructure components.
Record types
A
Maps an IPv4 hostname to an IPv4 address.
Check whether the hostname and address match the required system.
AAAA
Maps an IPv6 hostname to an IPv6 address.
Confirm the record is intentional if IPv6 is part of the environment.
CNAME
Creates an alias that points one DNS name to another canonical name.
Verify the alias still points to an authorized, required host.
MX
Identifies mail servers for a domain.
Review only when mail service is part of the authorized environment.
NS
Identifies authoritative DNS servers for a zone.
Unexpected name-server entries deserve investigation.
PTR
Maps an IP address back to a hostname in a reverse lookup zone.
Useful for reverse resolution and troubleshooting.
SRV
Publishes the location of services, including important Active Directory services.
On a domain controller, do not delete unfamiliar SRV records without understanding their AD role.
Zone review
Is this zone required by the scenario?
Is the zone Active Directory-integrated, primary, secondary, or another supported type?
Which DNS servers are authoritative for the zone?
Are dynamic updates enabled, disabled, or restricted?
Are zone transfers enabled?
If transfers are enabled, which servers are authorized to receive them?
Are there unexpected or duplicate A, CNAME, NS, MX, PTR, or SRV records?
Are stale-looking records actually unused, or do clients/services still depend on them?
Does aging/scavenging apply to this zone?
How will required names be tested after a change?
Server review
Which network interfaces is DNS listening on?
Which forwarders are configured?
Is recursion required for the clients using this server?
Is this server exposed to networks that should not use it recursively?
Does the firewall allow only the DNS traffic the server role requires?
Is the DNS Server service running?
Does the server use root hints, forwarders, or both for external resolution?
Are conditional forwarders configured for any required internal namespace?
Is the server also an Active Directory domain controller?
What client-side tests prove the server is resolving names correctly?
PowerShell inspection
Get-Service -Name "DNS"Shows whether the DNS Server service is running.
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated, IsReverseLookupZone, DynamicUpdateInventories DNS zones and shows useful zone-type and dynamic-update information.
Get-DnsServerResourceRecord -ZoneName "example.local" | Select-Object HostName, RecordType, TimeStamp, RecordDataLists records in a selected zone. Replace example.local with the authorized zone.
Get-DnsServerForwarderShows the DNS servers used as forwarders.
Get-DnsServerRecursionShows recursion-related DNS server configuration.
Get-DnsServerSetting -All | Select-Object -ExpandProperty ListeningIpAddressShows configured DNS listening addresses when supported by the installed DNS Server module.
Get-WinEvent -LogName 'DNS Server' -MaxEvents 40 | Select-Object TimeCreated, Id, LevelDisplayName, MessageReviews recent DNS Server events for warnings, errors, and operational clues.
Resolve-DnsName "host.example.local" -Server "dns-server-name"Tests a specific name against the intended DNS server. Replace the example values with the authorized target.
Dynamic updates
Records are managed manually. This can reduce automatic changes but may not fit environments that rely on dynamic registration.
Allows a broader set of dynamic updates and can be riskier because unauthorized changes may be easier.
Available for Active Directory-integrated zones and uses domain security to control dynamic updates.
Do not change dynamic-update mode without considering domain clients, DHCP integration, server registration, and the scenario.
Zone transfers
Appropriate when no authorized secondary DNS server requires a copy of the zone.
If transfers are required, limit them to the DNS servers that actually need the zone.
Allowing zone transfers to arbitrary hosts can reveal the zone's records and internal naming structure.
Disabling transfers can break legitimate secondary DNS if the design depends on them.
Forwarders
Each forwarder should have an understood purpose and belong to the authorized environment or approved upstream resolver.
An unknown forwarder can redirect unresolved queries and deserves investigation.
Routes queries for a specific DNS namespace to designated DNS servers and may be required for trusts or partner namespaces.
If a forwarder is unreachable, clients may experience slow or failed external resolution depending on server configuration.
Recursion
Many internal DNS servers need recursion so clients can resolve names outside locally hosted zones.
Providing recursion to untrusted networks can create unnecessary exposure and may allow abuse.
Turning off recursion can break ordinary client resolution even when authoritative zones still work.
Firewall scope, interfaces, and network design can help limit who can query the server.
Aging and scavenging
Tracks eligible dynamically registered records over time so stale records can eventually be identified.
Removes eligible stale records according to configured aging and scavenging behavior.
Static records are generally treated differently from dynamically timestamped records and should not be assumed stale just because they are old.
Aggressive scavenging can delete still-needed records if the environment is not configured correctly.
Suspicious signals
A resolver outside the expected environment may redirect DNS queries or create an unnecessary dependency.
An unfamiliar authoritative DNS server in the zone deserves investigation.
Transfers allowed to any server expose zone data more broadly than necessary.
A new A or CNAME record pointing a trusted name to an unexpected system should be investigated.
Multiple records for the same name can cause intermittent or misleading resolution behavior.
The server may be reachable from networks that should not use the DNS service.
Troubleshooting
Symptom
Check
Confirm clients use the intended DNS server, verify the DNS service, inspect the AD-integrated zone and SRV records, test domain-name resolution, and review DNS Server events.
Symptom
Check
Review forwarders, recursion, root-hint behavior, firewall/network reachability, and whether the server is intended to resolve external names.
Symptom
Check
Inspect A/AAAA/CNAME records, duplicate entries, dynamic-update history, client cache, DNS server cache, and whether the application recently moved.
Symptom
Check
Active Directory replication, automation, Group Policy, DHCP registration, or management tooling may be restoring the setting or record.
Symptom
Check
Review firewall scope, listening interfaces, client DNS settings, routing, network profile, and whether queries are reaching the server.
Symptom
Check
Review Zone Transfers settings, authorized name servers, firewall/network access, secondary-server configuration, and DNS Server events.
Client verification
Resolve-DnsName example.localConfirms the client can resolve the required domain namespace.
Resolve-DnsName filesrv.example.localConfirms a required host record resolves to the expected address.
nslookup filesrv.example.local dns-server-nameTests the intended DNS server directly.
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.localOn an Active Directory domain, helps confirm expected LDAP domain-controller discovery records exist.
Change discipline
Read the scenario and identify required DNS namespaces.
Record the DNS server role and whether the server is a domain controller.
Record existing zones, forwarders, interfaces, and transfer settings.
Record the specific DNS record before changing it.
Confirm whether DHCP, AD, applications, or clients update the record dynamically.
Change one DNS setting or record at a time.
Avoid deleting unfamiliar SRV or infrastructure records blindly.
Verify internal name resolution.
Verify required external or forwarded resolution when applicable.
Verify from an authorized client, not only from the DNS server itself.
Decision cases
The DNS server forwards unresolved queries to an address not listed in the scenario documentation.
The address may be unauthorized, but removing it immediately could also break external resolution if it is legitimate.
Response
Identify the owner and network location of the forwarder, compare it with authorized architecture, test current resolution, then replace or remove it only when justified.
A required internal zone permits transfers to servers beyond the known secondary DNS hosts.
The zone is required, but transfer scope is broader than necessary.
Response
Identify legitimate secondary servers, preserve required redundancy, and restrict transfers to authorized systems.
The records contain names such as _ldap and _kerberos.
These records are normal and important in Active Directory environments.
Response
Preserve them, confirm domain-controller registration and resolution, and investigate only records that conflict with the actual AD design.
The server has multiple interfaces but only one network should use the DNS role.
Listening on unnecessary interfaces may broaden exposure.
Response
Confirm no required clients or replication path uses the interface, then restrict DNS listening only if the server role and network design support it.
Fictional defensive lab
Step 01
DC-PRACTICE is the required Active Directory domain controller and DNS server for CYBERSHIELD.LOCAL. Clients must resolve domain names and one approved external update site.
Step 02
Open DNS Manager and use PowerShell to record zones, forwarders, recursion state, listening interfaces, and the DNS service state.
Step 03
Inspect A, CNAME, NS, and SRV records. Preserve expected Active Directory records and identify one suspicious duplicate A record.
Step 04
One approved forwarder is documented. A second unknown forwarder exists. Zone transfers are enabled more broadly than the known secondary-server design requires.
Step 05
Preserve the required forwarder and legitimate zone-transfer target, remove only clearly unauthorized configuration, and correct the duplicate record after confirming the intended address.
Step 06
Confirm domain resolution, a required host, Active Directory SRV records, and the approved external update site all resolve correctly.
Common mistakes
Active Directory relies on SRV records that may look strange to students who have only worked with A records.
Clients may lose the ability to resolve names outside locally hosted zones.
Required external resolution or partner-domain lookups may depend on them.
Broad transfer access exposes zone information unnecessarily.
Servers, applications, or static infrastructure may still rely on old-looking records.
The server can resolve locally while clients fail because of firewall, interface, or client-configuration problems.
Reflection
Question 1
Why is DNS especially important to Active Directory?
Question 2
Why should unfamiliar SRV records not be deleted automatically?
Question 3
When can a forwarder be both useful and risky?
Question 4
Why can open recursion create unnecessary exposure?
Question 5
What is the difference between dynamic updates and zone transfers?
Question 6
What should be tested from a client after changing DNS settings?
Verification checklist
The DNS Server service is running.
Required forward lookup zones are present.
Required reverse zones remain intact when applicable.
Expected Active Directory SRV records remain available.
Forwarders match the authorized environment.
Zone transfers are limited to required secondary servers when transfers are used.
Dynamic-update mode matches the zone design and scenario.
DNS listens only on intended interfaces when interface restriction is used.
Required internal names resolve from an authorized client.
Required external or conditional-forwarded names resolve when applicable.
Competition checklist
Open DNS Manager or dnsmgmt.msc.
Review Forward Lookup Zones.
Review Reverse Lookup Zones when applicable.
Review server Interfaces.
Review Forwarders.
Review recursion behavior.
Review zone dynamic updates.
Review zone transfers and name servers.
Inspect important A, CNAME, NS, PTR, and SRV records.
Check DNS Server events.
Use Resolve-DnsName or nslookup for verification.
Verify from an authorized client after every major DNS change.
Next Windows Server lesson
Next, review DHCP authorization, scopes, leases, reservations, options, exclusions, bindings, audit logs, and the network dependencies that keep clients configured correctly.