Active Directory SRV Records

What DNS entries (SRV Records) does Windows 2000/2003 add when you create a domain?


In order for Active Directory to function properly, DNS servers must provide support for Service Location (SRV) resource records described in RFC 2052, A DNS RR for specifying the location of services (DNS SRV). SRV resource records map the name of a service to the name of a server offering that service. Active Directory clients and domain controllers use SRV records to determine the IP addresses of domain controllers. Although not a technical requirement of Active Directory, it is highly recommended that DNS servers provide support for DNS dynamic updates described in RFC 2136, Observations on the use of Components of the Class A Address Space within the Internet. [Note: SRV records are still actively used in Active Directory environments on Windows Server 2016, 2019, 2022, and 2025.]
The Windows 2000 DNS service provides support for both SRV records and dynamic updates. If a non-Windows 2000 DNS server is being used, verify that it at least supports the SRV resource record. If not, it must be upgraded to a version that does support the use of the SRV resource record. For example, Windows NT Server 4.0 DNS servers must be upgraded to Service Pack 4 or later to support SRV resource records. A DNS server that supports SRV records but does not support dynamic update must be updated with the contents of the Netlogon.dns file created by the Active Directory Installation wizard while promoting a Windows 2000 Server to a domain controller. The Netlogon.dns file is described in the following section. [Note: This remains applicable today when using non-Windows DNS servers such as BIND. Manual entry of SRV records via Netlogon.dns is still required in such cases.]
So now you understand that Windows 2000 domains rely heavily on DNS entries. If you enable dynamic update on the relevant DNS zones, W2K creates these entries automatically:

🎬 Watch This Week in IT.


  • _ldap._tcp.<DNSDomainName>

Enables a client to locate a W2K domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain dpetri.net would query the DNS server for _ldap._tcp.dpetri.net.

  • _ldap._tcp.<SiteName>._sites.<DNSDomainName>

Enables a client to find a W2K domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.dpetri.net for a domain controller in the Lab site of dpetri.net).

  • _ldap._tcp.pdc._ms-dcs.<DNSDomainName>

Enables a client to find the PDC flexible single master object (FSMO) role holder of a mixed-mode domain. Only the PDC of the domain registers this record.

  • _ldap._tcp.gc._msdcs.<DNSTreeName>

Enables a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the tree will register this name. If a server ceases to be a GC server, the server will deregister the record.

  • _ldap._tcp. ._sites.gc._msdcs.<DNSTreeName>

Enables a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.dpetri.net).

  • _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSTreeName>

Enables a client to find a domain controller in a domain based on the domain controller’s globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.

  • <DNSDomainName>

Enables a client to find a domain controller through a normal Host record.

After running DCPROMO, A text file containing the appropriate DNS resource records for the domain controller is created. The file called Netlogon.dns is created in the %systemroot%System32config folder and contains all the records needed to register the resource records of the domain controller. Netlogon.dns is used by the Windows 2000 NetLogon service and to support Active Directory for non-Windows 2000 DNS servers.  [Note: While DCPROMO as a separate tool is deprecated starting in Windows Server 2012, the Netlogon.dns file is still generated automatically during DC promotion via Server Manager or PowerShell.]
If you are using a DNS server that supports the SRV resource record but does not support dynamic updates (such as a UNIX-based DNS server or a Windows NT Server 4.0 DNS server), you can import the records in Netlogon.dns into the appropriate primary zone file to manually configure the primary zone on that server to support Active Directory. [Note: This remains a valid approach when integrating modern Active Directory with non-Windows or manually managed DNS services.]

FAQs

How do I troubleshoot missing Active Directory SRV Records in a multi-domain environment?

To troubleshoot missing Active Directory SRV Records across multiple domains, start by using the DNS Management Console to verify record replication, run dcdiag /test:dns for comprehensive diagnostics, and ensure that the DNS servers are properly authorized for secure dynamic updates for each domain in the forest.

Can Active Directory SRV Records be manually created, and what are the risks?

While Active Directory SRV Records can be manually created, it’s not recommended as it can lead to replication issues and service location failures. If manual creation is necessary, ensure exact compliance with Active Directory naming conventions and maintain detailed documentation of all manual entries.

How do Active Directory SRV Records impact performance across different sites?

Active Directory SRV Records significantly influence cross-site performance by directing clients to the nearest domain controllers through site-specific SRV records, reducing authentication times and network traffic when properly configured with site-aware DNS settings.

What are the best practices for backing up Active Directory SRV Records?

Best practices for backing up Active Directory SRV Records include maintaining regular DNS database backups, documenting all custom SRV record configurations, and implementing automated monitoring systems to detect and alert on critical SRV record changes or deletions.

How do you migrate Active Directory SRV Records during a domain upgrade?

When migrating Active Directory SRV Records during a domain upgrade, first export existing records, verify DNS zone configurations in the new environment, ensure proper replication of SRV records across all DNS servers, and implement a staged migration approach to maintain service continuity.

Links

Windows 2000 Deployment Planning Guidelink out ico
Troubleshooting Common Active Directory Setup Issues in Windows 2000 – 260371link out ico
Setting Up the Domain Name System for Active Directory – 237675link out ico
Information About Configuring Windows 2000 for Domains with Single-Label DNS Names – 300684link out ico