10.2 DNS Records, Aging & Scavenging and the GlobalNames Zone

DNS Records, Aging & Scavenging and the GlobalNames Zone

1. DNS Record Management & AD DS Service Location (SRV Records)

Active Directory relies on Service Location (SRV) records (RFC 2782) to allow domain-joined workstations, member servers, and applications to locate domain controllers, Kerberos Key Distribution Centers (KDCs), Global Catalogs, and LDAP services.

+-----------------------------------------------------------------------------+
|                        SRV RECORD FORMAT & STRUCTURE                        |
|                                                                             |
|   _Service._Proto.Name   TTL   Class   SRV   Priority  Weight  Port  Target |
|   ------------------------------------------------------------------------- |
|   _ldap._tcp.dc._msdcs   600   IN      SRV   0         100     389   dc01...|
|     |      |    |                               |       |       |      |    |
|     |      |    +-- Subdomain / Scope           |       |       |      +Host|
|     |      +------- Transport Protocol (TCP/UDP)|       |       +Port       |
|     +-------------- Service Name                |       +Load Balancing     |
|                                                 +Preference (Lower First)   |
+-----------------------------------------------------------------------------+

Critical AD DS SRV Records:

1. _ldap._tcp.dc._msdcs.<DomainName>: Enables clients to locate domain controllers running LDAP directory services on TCP port 389.
2. _kerberos._tcp.<DomainName>: Identifies KDC authentication servers running on TCP port 88.
3. _gc._tcp.<ForestRootName>: Locates Global Catalog servers across the forest on TCP port 3268.
4. _kpasswd._tcp.<DomainName>: Locates Kerberos password change servers on TCP port 464.

# PowerShell: Querying and Creating Critical DNS Resource Records

# 1. Retrieve all SRV records for domain controller locator in contoso.com
Get-DnsServerResourceRecord -ZoneName 'contoso.com' -RRType SRV | 
    Where-Object { $_.HostName -like '_ldap._tcp*' }

# 2. Add an AD-Integrated Primary Forward Lookup Zone in the DomainDNSZones partition
Add-DnsServerPrimaryZone `
    -Name 'corp.contoso.com' `
    -ReplicationScope 'Domain' `
    -DynamicUpdate 'Secure'

# 3. Create an A record and alias CNAME record
Add-DnsServerResourceRecordA -ZoneName 'corp.contoso.com' -Name 'app01' -IPv4Address '10.10.4.50' -CreatePtr
Add-DnsServerResourceRecordCName -ZoneName 'corp.contoso.com' -Name 'fileshare' -HostNameAlias 'app01.corp.contoso.com.'

---

2. Zone Aging and Scavenging Mechanics

When dynamic updates are enabled, dynamically registered records accumulate over time. When laptops leave the organization, virtual machines are decommissioned, or DHCP leases change, orphaned DNS records remain in the zone. Aging and Scavenging is the automated mechanism that purges stale dynamic records.

+-----------------------------------------------------------------------------+
|                   DNS AGING AND SCAVENGING TIMELINE LIFECYCLE               |
|                                                                             |
|   [RECORD CREATED]                                                          |
|   Timestamp: Day 0                                                          |
|          |                                                                  |
|          v                                                                  |
|   +-----------------------+  NO-REFRESH INTERVAL (Default: 7 Days)          |
|   | Server IGNORES record |  - Dynamic updates with same IP do NOT advance  |
|   | timestamp refreshes   |    the timestamp.                               |
|   +-----------------------+  - Reduces Active Directory replication traffic.|
|          |                                                                  |
|          v Day 7                                                            |
|   +-----------------------+  REFRESH INTERVAL (Default: 7 Days)             |
|   | Server ACCEPTS record |  - Dynamic updates ARE accepted and advance     |
|   | timestamp refreshes   |    the timestamp back to Day 0.                 |
|   +-----------------------+                                                 |
|          |                                                                  |
|          v Day 14                                                           |
|   [RECORD BECOMES STALE]  ---> Record is eligible for Scavenging            |
|          |                                                                  |
|          v (Scavenging thread runs every 7 Days)                            |
|   [RECORD DELETED]        ---> Purged from Active Directory database        |
+-----------------------------------------------------------------------------+

Scavenging Parameters and Timers:

1. Record Timestamp: Static records have a timestamp of 0 (never scavenged). Dynamic records receive a timestamp reflecting the date and time of creation or refresh.
2. No-Refresh Interval (Default: 7 Days):
   • During this window, the DNS server accepts DNS query traffic and name changes, but suppresses timestamp updates if the IP address has not changed.
   • Purpose: Prevents massive AD DS replication storms across domain controllers caused by clients repeatedly updating their unchanged timestamps.
3. Refresh Interval (Default: 7 Days):
   • During this window, dynamic updates from the client are accepted, and the record timestamp is reset to the current time, restarting the No-Refresh interval.
4. Stale Threshold Calculation: $\text{Stale Threshold} = \text{Record Timestamp} + \text{No-Refresh Interval} + \text{Refresh Interval}$ With default 7-day intervals, a record becomes stale after 14 days without a refresh.
5. Scavenging Period (Server-Level Execution):
   • The recurring interval (default 7 days) at which the DNS server initiates the background scavenging thread to delete stale records.

[!IMPORTANT] The Dual-Level Activation Rule: Scavenging will NEVER execute unless it is explicitly enabled at both levels:

1. Server Level: The DNS server must be designated as a scavenging server.
2. Zone Level: Aging and scavenging must be enabled on the target zone properties. If enabled at the zone level but not at the server level, records age but are never deleted.

# PowerShell: Enabling Scavenging at Server and Zone Levels

# 1. Enable Aging on the target AD-integrated zone
Set-DnsServerZoneAging `
    -ZoneName 'corp.contoso.com' `
    -Aging $true `
    -NoRefreshInterval (New-TimeSpan -Days 7) `
    -RefreshInterval (New-TimeSpan -Days 7)

# 2. Configure Scavenging at the Server Level
Set-DnsServerScavenging `
    -ScavengingState $true `
    -ScavengingInterval (New-TimeSpan -Days 7)

# 3. Manually trigger an immediate scavenging cycle
Start-DnsServerScavenging -Verbose

---

3. GlobalNames Zone (GNZ) for Single-Label Name Resolution

Single-label names (e.g., http://payroll or http://intranet) were traditionally resolved using Windows Internet Name Service (WINS) or NetBIOS broadcasts. WINS is a legacy, non-routable protocol that does not support IPv6 and introduces substantial management overhead.

The GlobalNames Zone (GNZ) provides single-label name resolution across an entire Active Directory forest using standard, routable DNS infrastructure.

+-----------------------------------------------------------------------------+
|                     GLOBALNAMES ZONE RESOLUTION SEQUENCE                    |
|                                                                             |
|   [Client Browser] ---> Requests single-label name: http://erp              |
|          |                                                                  |
|          v                                                                  |
|   [Local DNS Server]                                                        |
|   1. Appends local DNS suffix search list (e.g., erp.corp.contoso.com)      |
|   2. If local lookup returns NXDOMAIN:                                      |
|   3. Checks authoritative GlobalNames Zone:                                 |
|      - Finds CNAME: erp -> app-prod-01.finance.contoso.com                  |
|   4. Resolves target FQDN and returns IPv4/IPv6 address to Client           |
+-----------------------------------------------------------------------------+

GlobalNames Deployment Rules:

1. Create an AD-Integrated forward lookup zone named explicitly GlobalNames.
2. Store the zone in the ForestDNSZones application partition to ensure all DNS servers in the forest hold a replica.
3. Enable GlobalNames support on every participating DNS server via PowerShell (Set-DnsServerGlobalNameZone -Enable $true).
4. Populate the zone primarily with CNAME records pointing to the canonical FQDN of target servers.