PREEMPTIVE_OS_DSGETDCNAME is recorded when a thread calls the Windows DsGetDcName function, which locates a domain controller for a given domain. It is the discovery step that precedes much authentication work: before validating a login or resolving an account, Windows must first find a DC to ask.
Slowness here therefore front-runs slowness everywhere else in the authentication family.
Is It a Problem?
At trace levels, no. When its average duration grows, DC discovery itself is struggling, and that has a short list of causes, all infrastructure-side: DNS misconfiguration (the classic), AD site/subnet definitions steering the server to distant DCs, or the nearby DCs being down or overloaded. The follow-on symptom set is slow Windows logins to SQL Server and elevated PREEMPTIVE_OS_AUTHENTICATIONOPS.
For a DBA, this wait’s value is evidence quality: it points below SQL Server with unusual precision.
Common Causes
- DNS problems delaying or misrouting DC location.
- AD site topology sending the server to remote DCs.
- Domain controller outages forcing rediscovery.
What To Do
- Check which DC the server resolves:
nltest /dsgetdc:<domain>from the SQL Server host, and whether it is the expected nearby one. - Verify DNS configuration on the host (the servers it queries, and their health).
- Escalate with specifics; slow
DsGetDcNameis an AD/DNS work item, not a SQL Server one.
How To See It
Rank it against everything else with Get-WaitStatistics, read together with the authentication wait family.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply