The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
To verify that a domain controller registered its Active Directory DNS records, run dcdiag /test:dns /DnsRecordRegistration /v /s:<DCName> on a computer with the Windows Server diagnostic tools. For a quick live lookup, query _ldap._tcp.dc._msdcs.<DomainFQDN> with nslookup. Use the domain’s DNS fully qualified domain name (FQDN), and query the DNS server that the affected clients actually use.
What Active Directory SRV records do
An SRV (service location) record tells clients which host offers a particular network service, along with details such as its port, priority, and weight. Active Directory Domain Controller (DC) Locator uses DNS to find domain controllers and services such as LDAP and Kerberos. Site-specific records help clients discover controllers associated with their Active Directory site. Microsoft describes the locator process in its DC Locator documentation.
Use the Active Directory DNS domain name, not just its NetBIOS short name. For example, if the DNS domain is corp.example.com and the NetBIOS name is CORP, use corp.example.com in DNS queries.
Free tools Windows power users keep installed
One-click scans. No signup required.
Start with a live SRV lookup
From Command Prompt, query the domain-controller LDAP locator record:
#1 Best Overall
- Mastering Active Directory: Design, deploy, and protect Active Directory Domain Services for Windows Server 2022, 3rd Edition
- ABIS BOOK
- Packt Publishing
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.comReplace corp.example.com with your AD DNS FQDN. To test a particular DNS server directly, append its IP address:
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com 10.0.0.10Use the address of a DNS server authoritative for, or able to resolve, the AD zone. The response identifies the DNS server queried and, for each returned SRV record, its priority, weight, port, and target hostname. LDAP normally uses port 389. The hostname should resolve to the expected controller address; check it separately if the response does not include an address:
nslookup dc01.corp.example.comA successful SRV answer proves that the queried DNS server returned that record. It does not establish that LDAP is listening, that the controller is reachable, or that Active Directory replication and authentication are healthy.
Other useful SRV queries
Check records relevant to the services and discovery path you are troubleshooting. These examples use the same domain FQDN unless noted:
Rank #2
nslookup -type=SRV _ldap._tcp.corp.example.com
nslookup -type=SRV _kerberos._tcp.corp.example.com
nslookup -type=SRV _kerberos._udp.corp.example.com
nslookup -type=SRV _gc._tcp.example.comThe global catalog query uses the forest DNS name; substitute your forest FQDN for example.com. Kerberos normally uses port 88, and global catalog LDAP commonly uses 3268. These are expected service ports, not reachability tests.
For site-aware discovery, substitute the exact Active Directory site name:
nslookup -type=SRV _ldap._tcp.Sitename._sites.dc._msdcs.corp.example.comA domain-wide query can succeed while a site-specific query is missing or incorrect. The applicable records vary with the forest, domain, site, controller roles, and configuration; do not treat one fixed list as universal. Depending on the environment, useful additional names include _ldap._tcp.pdc._msdcs.<DomainFQDN> and _ldap._tcp.<SiteName>._sites.<DomainFQDN>.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
You can also query interactively:
nslookup
set type=all
_ldap._tcp.dc._msdcs.corp.example.comOn Windows, PowerShell offers another direct lookup method:
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example.com
Resolve-DnsName -Type SRV _kerberos._tcp.corp.example.comValidate registration with DCDIAG
For the focused question “Did this controller register its required DNS records?”, run Microsoft’s DNS record-registration test:
dcdiag /test:dns /DnsRecordRegistration /v /s:DC01Replace DC01 with the domain controller name. The test checks required host A, GUID-based CNAME, and SRV registrations, including LDAP, global catalog, and PDC-related records as applicable. To test all domain controllers in the forest instead of targeting one, use:
dcdiag /test:dns /DnsRecordRegistration /v /eFor a broader DNS diagnosis of one controller, run:
dcdiag /test:dns /DnsAll /v /s:DC01/DnsRecordRegistration focuses on record registration. /DnsDynamicUpdate checks dynamic-update capability, while /DnsBasic checks basic DNS configuration, connectivity, service availability, and zone existence. /DnsAll runs the DNS test suite except the external-name resolution test. /s targets a controller, /e expands testing to all controllers in the forest, and /v includes successful results as well as warnings and errors. See Microsoft’s DCDIAG command reference for syntax and options.
Rank #4
To save output for troubleshooting, create the destination folder if needed, then redirect the results:
dcdiag /test:dns /DnsRecordRegistration /v /s:DC01 > C:TempDC01-dns.txtCheck the records in DNS Manager
- Open DNS Manager by running
dnsmgmt.msc. - Expand Forward Lookup Zones and open the zone for the AD DNS domain.
- Inspect the
_msdcshierarchy and the relevant_tcpfolders for_ldapand_kerberosSRV records. - Check the domain-wide and, when relevant, site-specific records. Confirm each SRV target is the expected controller FQDN.
- Resolve each target hostname and confirm it maps to the controller’s expected IP address.
Microsoft calls out locations such as Forward Lookup Zones/<DomainName>/_msdcs/dc/_tcp and Forward Lookup Zones/<DomainName>/_msdcs/dc/_sites/<SiteName>/_tcp. The console tree can differ when _msdcs is hosted as a separate integrated zone or represented through delegation. Follow the actual zone structure rather than assuming every DNS Manager view looks identical. Microsoft’s SRV record verification guide also describes the visual check.
Compare live DNS with Netlogon.dns
On the controller, inspect the record inventory maintained by Netlogon:
notepad %systemroot%System32ConfigNetlogon.dnsThis file lists records Netlogon believes it should register. It is useful when DNS is hosted on a non-Microsoft server or when you need to compare intended registrations with published DNS data. A record in Netlogon.dns is not proof that the DNS server accepted or serves it; query the relevant DNS server to confirm publication.
Best Value
Test whether Windows can locate a controller
After checking individual records, test DC Locator:
nltest /dsgetdc:corp.example.com /forceA successful result identifies a controller and its address and reports domain information. The /force option requests fresh discovery rather than relying on cached locator information. DC Locator queries DNS and contacts a returned controller to check availability, so this is a useful functional check, but it is not a substitute for inspecting individual SRV records. A successful result can also identify one suitable controller while another controller remains unhealthy. See Microsoft’s NLTEST reference.
If records are missing or wrong
- Confirm the name and resolver. Use the AD DNS FQDN, identify which DNS server answered, and repeat the lookup against the DNS server used by the affected client or controller. Different DNS views, forwarding paths, delegations, or replication delays can produce different answers.
- Check dynamic updates. Run
dcdiag /test:dns /s:DC01 /DnsDynamicUpdate. Confirm the zone and its update permissions are appropriate for your DNS architecture. For an AD-integrated zone, Microsoft recommends secure dynamic updates where applicable; do not assume that recommendation describes every third-party DNS design. - Check Netlogon and DNS configuration. On the controller, verify Netlogon is running with
Get-Service Netlogon. Check the DNS Client configuration and relevant System and DNS Server event logs. A running service alone does not prove that updates were accepted. - Review the zone, delegation, and update path. Confirm the controller can reach the DNS server responsible for the AD records and that the zone accepts the required updates. Microsoft’s DNS registration troubleshooting guidance covers dynamic-update issues.
- Force registration only after checking configuration. Restarting Netlogon triggers registration of DC locator records. The DNS Client registration command refreshes the host A record:
net stop netlogon
net start netlogon
ipconfig /flushdns
ipconfig /registerdnsRun the service commands from an elevated prompt and expect a brief service interruption while Netlogon restarts. Then repeat the SRV lookup, DCDIAG test, and DC Locator check. Microsoft explains these registration steps in its DNS verification guidance for AD replication.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →If records still fail to appear, investigate event logs, DNS permissions, delegation, and replication before considering manual record creation. Manually adding SRV records can mask the underlying update problem and leave stale records that need future maintenance. Advanced configurations can intentionally suppress particular Netlogon registrations; review them only if the environment is known to use such settings. See Microsoft’s guidance on Netlogon record registration behavior.
How to interpret common results
- The SRV query returns one or more targets. The queried server has an answer for that name. Confirm the expected controllers are present and each target hostname resolves correctly.
- The query returns no records or a name-not-found response. Confirm the FQDN and DNS server first. Then check the zone, update path, and whether the record is expected for that domain, site, or controller role.
- An SRV target has no usable address. The SRV record points to a hostname, so check that hostname’s A record and, where used, AAAA record. DCDIAG tests associated address and CNAME registration as well.
- Domain-wide discovery works but site-specific discovery fails. Check the exact site name and site-specific record path, then verify the controller’s AD site assignment.
- DCDIAG reports an AAAA-related failure. If IPv6 is not enabled on the controller, an AAAA test warning may be expected in that configuration; it does not by itself establish that SRV registration failed. Interpret it alongside the specific SRV, A, and CNAME results.
- NLTEST succeeds but one controller is still problematic. A successful discovery test may have selected another suitable controller. Test the affected controller directly with DCDIAG and query its relevant records.
What SRV verification does not establish
DNS registration is one part of Active Directory discovery, not a complete health check. Even a correct SRV response does not prove that LDAP or Kerberos is listening and reachable, RPC traffic is permitted, time synchronization is suitable for Kerberos, replication is healthy, or the selected controller is writable and appropriate for a particular operation. Continue with the relevant service, connectivity, replication, and authentication diagnostics for the original symptom.
For current Windows Server deployments, emphasize DNS-based discovery and the DNS FQDN. Microsoft documents changes to legacy NetBIOS-style locator behavior beginning with Windows Server 2025; do not assume older NetBIOS discovery expectations apply unchanged across versions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
