DNS Bug: Windows Server Registers Duplicate SRV Records with Uppercase Computer Names

Table of Contents

DNS Bug: Windows Server Registers Duplicate SRV Records with Uppercase Computer Names

This article addresses a specific issue within Windows Server environments where the Domain Name System (DNS) functionality inadvertently registers duplicate Server Location (SRV) records for Domain Controllers (DCs). This occurs when a DC’s computer name includes uppercase letters, leading to potential inconsistencies and operational challenges within the network infrastructure. This guide provides a comprehensive overview of the problem, its underlying cause, and detailed resolution steps, including a crucial update from Microsoft and various workarounds. The information presented is particularly relevant for systems running Windows Server 2019 and Windows Server 2016.

Understanding the Problem: Duplicate SRV Records

Active Directory Domain Services (AD DS) relies heavily on DNS for proper functioning, particularly for locating services and domain controllers. SRV records are a critical component of this reliance, as they provide information about available services, including the hostnames and port numbers of DCs. When these records are duplicated or inconsistent, it can lead to various complications.

This specific bug manifests when domain controllers running Windows Server 2016 or later have computer names that incorporate uppercase characters. Instead of maintaining a single, consistent SRV record for such a DC, the DNS system registers two distinct records. One record will list the computer name entirely in lowercase, while the other will preserve the original mixed-case format, creating an ambiguity that can disrupt normal operations.

Symptoms of Duplicate SRV Records

The primary symptom of this issue is the presence of redundant SRV records within your AD DS-integrated DNS zones. You will observe this particularly for domain controllers whose computer names contain uppercase letters. For instance, a DC named WinServ16.contoso.com might have SRV records registered as both winserv16.contoso.com and WinServ16.contoso.com. This duality in record registration can lead to several adverse effects across your domain environment.

Such duplicate entries can cause client machines and other domain controllers to experience intermittent connectivity problems when attempting to locate and authenticate against these DCs. Replication issues between domain controllers might also arise, leading to inconsistencies in Active Directory data. Furthermore, applications and services that query DNS for DC locations may exhibit unpredictable behavior or even fail, as they encounter conflicting information. The inconsistency can also complicate troubleshooting and management of your DNS infrastructure, requiring additional effort to identify and correct the correct records.

The Root Cause: Case Sensitivity in DNS

The underlying cause of this duplicate SRV record issue lies in a subtle yet significant change in how the Windows Server DNS functionality handles the RDATA (Resource Data) segment of SRV records, coupled with a lack of case sensitivity during record comparison. In earlier versions, specifically Windows Server 2012 R2 and prior, the DNS service was designed to convert all characters in the RDATA segment to lowercase before registration. This ensured uniformity, regardless of the computer’s actual name casing.

However, with Windows Server 2016 and subsequent versions, the DNS functionality was updated to accept and preserve both uppercase and lowercase letters within the RDATA segment. This change alone would not be problematic if the DNS server’s record checking mechanism was also updated to be case-insensitive. Unfortunately, when the DNS server attempts to determine if an SRV record for a specific computer name already exists, it performs a case-sensitive comparison. Consequently, an entry like winserv16.contoso.com is treated as entirely distinct from WinServ16.contoso.com, leading to the registration of a new record rather than an update or recognition of an existing one.

This behavior can manifest in several common deployment scenarios:

  • Upgraded Environments: If all DNS servers and domain controllers in your domain have been upgraded from Windows Server 2012 R2 (or an earlier version) to Windows Server 2016 (or a later version), the DNS database may begin generating extra SRV records for any DC with uppercase characters in its computer name. The previous lowercase records might persist, and new mixed-case records are added.
  • New Windows Server 2016+ DCs in Older Domains: In a domain where all existing DNS servers and DCs run Windows Server 2012 or earlier, if you introduce a new Windows Server 2016 member server, install the DNS server role, and then promote it to a domain controller, this new DC can register duplicate SRV records if its computer name contains uppercase characters. The older DNS servers would expect lowercase, while the new DC attempts to register mixed-case.
  • DNS Role Transfer in Mixed Environments: Consider a domain with a mix of Windows Server versions, where the primary DNS server is an older DC (Windows Server 2012 or earlier) and a secondary DNS server is a newer Windows Server 2016 DC. If the primary DNS server becomes unavailable and the Windows Server 2016 DC assumes the role of the new primary, it may then start registering additional SRV records for any DC that has uppercase characters in its computer name, due to its updated behavior.

The core issue is that the registration mechanism now allows mixed case, but the conflict detection mechanism does not adequately account for it, leading to the erroneous creation of redundant entries.

Resolution: Applying the Microsoft Update

Microsoft has acknowledged this issue and released a crucial update to mitigate and resolve the problem of duplicate SRV record registration. It is highly recommended to apply this update to all affected Windows Server domain controllers to ensure proper and consistent DNS operation. The update introduces a new Group Policy setting designed to enforce the use of lowercase hostnames when registering domain controller SRV records, thereby preventing the underlying cause of the duplicates.

The following table outlines the relevant updates for the affected Windows Server versions:

Version Release
Windows Server 2019, v1903 March 24, 2020 - KB4541335 (OS Builds 18362.752 and 18363.752)
Windows Server 2019, v1809 March 17, 2020 - KB4541331 (OS Build 17763.1131)
Windows Server 2016 March 17, 2020 - KB4541329 (OS Build 14393.3595)

New Group Policy Setting

Upon installing the update, a new Group Policy policy setting becomes available through the NETLOGON.ADMX file. This policy offers a centralized mechanism to manage how domain controllers register their SRV records.

Policy Name Use lowercase DNS host names when registering domain controller SRV records
Policy Path Computer Configuration\Policies\Administrative Templates\System\Net Logon\DC Locator DNS Records\
Policy Values
  • 1 (default). The policy is enabled. This setting actively purges duplicate DNS SRV records. When the update is installed on a DC, this configuration becomes part of its default local settings, ensuring lowercase registration.
  • 0. The policy is disabled. Under this setting, the problematic behavior will persist, meaning DCs with uppercase characters in their computer names will continue to register SRV records that include those uppercase characters. This value should only be used in emergency situations or for testing purposes and is not recommended for typical production environments.

If the policy is left unconfigured or its value is missing, the Domain Controller will revert to the new default local configuration, treating the policy as if it were enabled. This ensures that the corrective behavior is applied even without explicit policy configuration.

The update also adds a corresponding registry entry, which is primarily for reference and advanced troubleshooting:
* Registry Subkey: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Netlogon\Parameters
* Registry Entry: DnsSrvRecordUseLowerCaseHostNames
* Data Type: REG_DWORD

Implementation and Cleanup

A significant advantage of this update is that it does not require a restart of the Netlogon service or the entire computer after installation. This minimizes disruption to critical services. When the update is applied or the policy is enabled, the Netlogon service will make a “best-effort” attempt to automatically remove existing DNS records that contain uppercase characters, thereby cleaning up previously created duplicates.

The recommended approach is to install the update (or enable the policy if it was previously disabled) and then allow a grace period of one to two days. This duration provides sufficient time for the Netlogon service to acquire and apply the new setting, and for these changes to replicate throughout your Active Directory and DNS environment. After this waiting period, you should diligently examine your DNS records for any remaining duplicate entries. While the policy aims for comprehensive cleanup, it is possible that some stubborn duplicate records might be missed and require manual intervention.

To review your DNS SRV records, you can utilize the following Windows PowerShell command:

Get-DnsServerResourceRecord -ZoneName "contoso.com" -RRType Srv

Replace "contoso.com" with your actual domain name. This command provides a comprehensive list of all SRV records in the specified zone, allowing you to identify any lingering duplicates. Should you find any, they can be manually removed using another PowerShell command:

Remove-DnsServerResourceRecord -ZoneName "contoso.com" -RRType Srv -Name "<hostname of record to delete>" -RecordData "<recorddata of record to delete>"

Ensure to replace placeholders <hostname of record to delete> and <recorddata of record to delete> with the precise values of the duplicate record you intend to remove. Carefully identify the incorrect, uppercase-containing record for deletion. Disabling the policy, if ever necessary, does not require any subsequent cleanup actions as it simply allows the old behavior to resume.

Visualizing the Resolution Process

Here’s a simple flowchart illustrating the recommended resolution process:

mermaid graph TD A[Identify Affected DCs] --> B{Are Updates Installed?}; B -- No --> C[Install KB4541335 / KB4541331 / KB4541329]; B -- Yes --> D[Verify Group Policy 'Use lowercase DNS host names...']; C --> D; D -- Enabled/Default --> E[Wait 1-2 Days for Netlogon and Replication]; D -- Disabled --> F[Enable Group Policy 'Use lowercase DNS host names...']; F --> E; E --> G[Review DNS SRV Records via PowerShell]; G -- Duplicates Found --> H[Manually Remove Duplicates via PowerShell]; G -- No Duplicates --> I[Resolution Complete]; H --> I;

It is crucial to prioritize the installation of the official Microsoft update. This fix not only addresses existing duplicates but also prevents the problem from recurring by enforcing a consistent naming convention for SRV record registration.

Workaround 1: Preventing Duplicate SRV Records Proactively

While the Microsoft update provides the definitive solution, several proactive measures can be taken to prevent the registration of duplicate SRV records from occurring in the first place, especially if you cannot immediately deploy the update. These workarounds focus on maintaining consistent naming conventions for your domain controllers.

  • Enforce Lowercase Computer Names: Before promoting any member server to a domain controller, or prior to upgrading an existing DC to Windows Server 2016 or a later version, ensure that its computer name consists solely of lowercase characters. This simple step aligns with the behavior of older DNS versions and prevents the mixed-case registration issue.
  • Standardize Naming Conventions: Review and update any internal build processes, IT automation tools, or scripts that are responsible for creating, modifying, or querying computer names. Ensure that these tools consistently enforce the use of lowercase characters for all domain controller names. This consistency across your environment is key to prevention.
  • Segment DNS Topology for Mixed Environments: In domains with a mix of Windows Server versions, consider configuring your DNS topology to segment DCs based on their operating system versions. For example, configure domain controllers running Windows Server 2016 or later to exclusively use DNS servers that also run Windows Server 2016 or later. Similarly, ensure that DCs running Windows Server 2012 R2 or earlier use DNS servers of the same or older version. This segregation helps prevent the interaction of conflicting case-handling behaviors between different DNS server versions.

Workaround 2: Removing Duplicate SRV Records Post-Occurrence

If you have already encountered this issue and have duplicate SRV records in your environment, and applying the update immediately isn’t feasible, you can implement one of the following methods to resolve the problem. These methods involve renaming your domain controllers to use only lowercase characters. It’s important to exercise caution when renaming domain controllers, as it’s a critical infrastructure change. Depending on your specific deployment and the number of affected DCs, you may need to manually reconfigure settings or delete specific files.

Important Note: Should you encounter any unforeseen issues or instability after renaming a Domain Controller using any of the methods below, it is strongly advised to revert the DC’s name to its original content as a first troubleshooting step.

Method 1: Rename a DC in a Single-DC Domain

If your domain consists of only a single domain controller, the process is relatively straightforward. You can follow the standard procedure for renaming a Domain Controller without needing to demote and repromote it. The key is to change the DC’s computer name to a new name that contains only lowercase characters.

Strong Recommendation: For production environments, it is highly recommended that any domain contains at least two domain controllers. A single point of failure can render your entire domain unavailable if that sole DC experiences any issues. Implementing redundancy is a critical aspect of maintaining domain stability and availability.

Method 2: Rename DCs in a Multi-DC Domain

For environments with multiple domain controllers, a more involved process is required for each affected DC to ensure a clean removal of duplicate records and proper re-registration.

  1. Demote the Domain Controller: Begin by demoting the affected domain controller. This removes its Active Directory Domain Services role. Following the demotion, ensure you perform thorough metadata cleanup in Active Directory to remove any lingering references to the demoted DC. Detailed guidance on these procedures can be found in Microsoft documentation regarding “Demoting Domain Controllers and Domains” and “AD Forest Recovery - Cleaning metadata of removed writable domain controllers.”
  2. Rename the Computer: After demotion and metadata cleanup, rename the demoted server’s computer name. Crucially, ensure the new name consists solely of lowercase characters.
  3. Promote the Computer: Once the computer is renamed, promote it back to a domain controller in your domain. This process will register new, correctly formatted SRV records.

After all affected domain controllers have undergone this demotion, renaming, and promotion cycle and are back online, the duplicate (mixed-case) SRV records should be absent from your DNS zones.

Method 3: Rename DCs and Remove All Stored SRV Records (Advanced Cleanup)

If Method 1 and Method 2 do not yield satisfactory results, or if you require a more aggressive cleanup of DNS records, this method provides a comprehensive approach for each affected DC. This method involves manually clearing specific Netlogon files that store DNS registration information.

  1. Demote the Domain Controller and Clean Metadata: Similar to Method 2, first demote the affected domain controller and perform a thorough metadata cleanup within Active Directory. This ensures that AD no longer holds references to the old DC.
  2. Perform Cleanup on the Demoted Computer:
    • Rename the Computer: Change the computer’s name to use only lowercase characters. This is a critical step to prevent re-creation of the issue.
    • Stop the Netlogon Service: Open an elevated Command Prompt window and execute the command net stop netlogon. This temporarily halts the service responsible for registering DC locator records.
    • Delete Netlogon Files: Navigate to the C:\Windows\System32\config\ folder and delete the following two files:
      • netlogon.dnb
      • netlogon.dns
        These files store cached DNS registration information for the Netlogon service. Deleting them ensures a fresh registration upon service restart.
  3. Manually Clean DNS Records on Another DC: On another functioning domain controller within your domain, open Server Manager, select Tools, and then choose DNS. In DNS Manager, navigate through the Forward Lookup Zones and meticulously locate and delete any remaining SRV records associated with the previously demoted domain controller. This step removes any records that might have persisted.
  4. Start the Netlogon Service: On the renamed computer, open an elevated Command Prompt window and run the command net start netlogon. This will restart the Netlogon service, which will then initiate a new, clean registration of SRV records using the newly configured lowercase computer name.
  5. Promote the Renamed Computer: Finally, promote the renamed computer back to a domain controller. This completes the re-integration of the DC with its new, consistent naming convention.

By following Method 3, you ensure a complete reset of the DNS registration for the domain controller, effectively eliminating duplicate SRV records and preventing their recurrence from that specific DC.

Conclusion

The issue of Windows Server registering duplicate SRV records due to uppercase characters in domain controller names can lead to significant operational challenges, impacting client connectivity, authentication, and Active Directory replication. Understanding the change in DNS functionality from Windows Server 2016 onward is key to comprehending the problem’s root cause. The most effective and recommended solution is to apply the official Microsoft update, which introduces a Group Policy setting to enforce lowercase hostname registration for SRV records.

While proactive measures like standardizing to lowercase computer names and careful DNS topology planning can prevent the issue, various workarounds involving demotion, renaming, and re-promotion are available for environments already affected. Always prioritize the installation of security and feature updates to ensure the stability and security of your infrastructure.

We hope this detailed guide helps you diagnose, understand, and resolve this specific DNS bug in your Windows Server environment. Your experiences and insights are valuable! If you’ve encountered this issue or implemented any of these solutions, please share your thoughts or questions in the comments below.

Post a Comment