Windows / Active Directory / Investigation

Investigating DNS, Active Directory, and Domain Health

Follow the dependency chain from one affected client to DNS, domain-controller discovery, secure channels, replication, time, services, and logs. This guide collects and correlates evidence. It does not automate repairs or treat one command as proof of domain health.

Written by Published Last reviewed

Purpose

Investigation, not repair

Separate client, DNS, discovery, replication, time, service, and connectivity evidence before planning a change.

Audience

Working Windows administrators

Use the guide when domain symptoms cross more than one infrastructure dependency.

Examples

Synthetic only

The names corp.example, DC01, and CLIENT01 are documentation-safe placeholders.

Method

Observe, compare, correlate

Record the target, time, resolver, command, and result before drawing a conclusion.

1 · Investigation question

What is this investigation designed to answer?

Determine whether the observed symptom is associated with client configuration, AD DNS data, domain-controller discovery, a member-computer secure channel, domain-controller advertising or services, replication, time synchronization, authentication, or network connectivity.

Common symptom

Sign-in or trust errors

A user or computer cannot authenticate, reports a trust problem, or behaves differently when disconnected from the network.

Common symptom

Policies or directory changes lag

Group Policy, password, group-membership, or directory-object changes appear on some systems but not others.

Common symptom

Intermittent domain access

SYSVOL, NETLOGON, LDAP-dependent tools, or domain-aware applications work from one location but fail from another.

Common symptom

Conflicting health signals

DNS resolves while authentication fails, or replication looks healthy while one application remains unavailable.

2–4 · Boundaries and preparation

Set the safety boundary and record the starting state.

Keep discovery separate from remediation

Use an authorized account and the least privilege needed for each read. Do not change DNS settings, restart services, repair trust relationships, force replication, edit directory data, or restore a domain controller while following this guide.

Minimum record

Scope and time

Record affected devices, users, sites, subnets, and services; when the symptom began; time zone; recurrence; and the last known working time.

Minimum record

Recent change context

Record known network, DNS, firewall, virtualization, update, backup, restore, site, or domain-controller changes without assuming that the newest change caused the issue.

Minimum record

Test identity

Record the computer, interface, current user context, domain, selected DNS server, target domain controller, exact command, and test time.

Data handling

Protect environment evidence

Command output, logs, host names, addresses, site names, and directory details are sensitive operational data. Store them only in the approved private case location.

Phase 1 · Establish scope

Decide how wide the symptom is before testing deeply.

Compare one known-affected system with one known-unaffected system where practical. Determine whether the issue follows an endpoint, subnet, site, domain controller, user, or service.

Scope questions

Move from smallest impact to largest.

Does the issue affect one endpoint, every endpoint on one subnet, clients in one AD site, requests handled by one domain controller, or the entire domain? A domain-wide conclusion requires domain-wide evidence.

Phase 2 · Client DNS and network configuration

Confirm what the affected client is actually using.

Run these commands on the affected member computer. They identify the host and user context, interface configuration, gateway, suffixes, and configured DNS servers without changing them.

hostname
whoami
ipconfig /all
Get-NetIPConfiguration
Get-DnsClientServerAddress

Why the configured DNS servers matter

AD DS uses DNS so clients can locate domain controllers and domain controllers can communicate. Domain members should normally query approved DNS servers that host or correctly resolve the AD namespace. Public or ISP resolvers generally cannot answer private AD locator records; internal DNS can forward external queries when that design is approved.

Check the active interface, IP address, prefix, default gateway, DNS suffix, and ordered DNS-server list. A public resolver on a domain member is strong configuration evidence, but still record which interface is active and whether another resolver or policy is involved before concluding it is the only cause.

Phase 3 · DNS resolution and AD locator records

Ask DNS questions that match Active Directory discovery.

Use the published Test-KTDNS tutorial before running the script. Test-KTDNS v1.0.0 accepts Name, Type, and optional Server parameters and performs DNS-only queries.

Host record

Confirm a domain-controller name resolves.

.\Test-KTDNS.ps1 -Name DC01.corp.example -Type A

A successful A-record lookup proves only that the selected resolver returned an address for that name. It does not prove domain-controller advertising, authentication, replication, RPC, SMB, time, or overall domain health.

AD locator record

Query the LDAP domain-controller SRV record.

.\Test-KTDNS.ps1 -Name _ldap._tcp.dc._msdcs.corp.example -Type SRV

SRV locator records are more meaningful than one host A record when evaluating domain discovery because DC Locator queries records that advertise services and suitable domain controllers.

Resolver comparison

Compare approved internal DNS servers explicitly.

.\Test-KTDNS.ps1 -Name _ldap._tcp.dc._msdcs.corp.example -Type SRV -Server '192.0.2.53'
.\Test-KTDNS.ps1 -Name _ldap._tcp.dc._msdcs.corp.example -Type SRV -Server '192.0.2.54'

The addresses are documentation-only placeholders. Replace them only with approved internal resolvers, record which server produced each answer, and do not send private names to an untrusted resolver.

Built-in comparison

Use Resolve-DnsName when you need the native record shape.

Resolve-DnsName -Name _ldap._tcp.dc._msdcs.corp.example -Type SRV -Server 192.0.2.53 -DnsOnly

Resolve-DnsName is the Windows cmdlet underneath Test-KTDNS. Test-KTDNS adds validation, DNS-only behavior, and normalized output; the built-in cmdlet is useful when you need its native response fields.

Interpret external-name failures separately

A failed public internet lookup does not automatically prove AD DNS is unhealthy. Internal locator resolution and external forwarding are different questions and should be tested and recorded separately.

Phase 4 · Domain-controller discovery

Ask Windows which domain controllers it can locate.

nltest /dsgetdc:corp.example
nltest /dclist:corp.example

/dsgetdc exercises DC Locator for the named domain and returns a suitable domain controller and flags when discovery succeeds. /dclist lists domain controllers known for the domain. Successful discovery shows that the client could locate and contact a candidate through the locator process at that time; it does not prove that every controller is healthy, replication is current, authentication will succeed, or an application dependency is available.

Phase 5 · Member-computer secure channel

Test the secure channel only where the cmdlet is supported.

Test-ComputerSecureChannel -Verbose

Member computers only

Microsoft documents this cmdlet for domain-member computers and warns that running it on domain controllers can return false-positive errors. Run it from an elevated PowerShell session on the affected member computer. This guide intentionally performs no repair.

A True result supports that this member computer's secure channel worked for the test. It does not prove DNS, Group Policy, user authentication, SYSVOL access, replication, or every domain controller is healthy. A failure is a finding to correlate with DNS, discovery, time, connectivity, and logs before any repair is attempted.

Phase 6 · Domain-controller service and advertising checks

Run focused DCDiag tests and read each result in context.

Use a domain controller or an administrative workstation with the AD DS management tools installed. Use an elevated prompt and credentials permitted to query the target controller and read required resources. Verbose output can be substantial, and remote tests depend on services and network paths such as RPC and SMB.

dcdiag /test:dns /v
dcdiag /test:advertising
dcdiag /test:services
dcdiag /test:sysvolcheck
dcdiag /test:netlogons

DNS

Configuration and registration evidence

The DNS test covers basic connectivity, DNS client configuration, service and zone checks, and—depending on the selected subtests—record registration and other DNS functions.

Advertising

Locator role evidence

The Advertising test checks whether the controller advertises the roles it should. A pass still does not prove every dependent port or authentication path works.

Services

Required service-state evidence

The Services test checks AD-dependent service state and startup expectations. A stopped service is evidence to investigate, not automatically the root cause.

SYSVOL and NETLOGON

Different tests, different meaning

SysVolCheck validates the controller's SYSVOL-ready registry state. NetLogons validates that the running user can connect to and read the SYSVOL and NETLOGON shares.

Review every failure with the target controller, site, time, permissions, and network path. Do not turn a single warning into a repair instruction.

Phase 7 · Active Directory replication

Summarize the forest, then inspect failing inbound partners.

Run Repadmin on a domain controller or a workstation with the AD DS RSAT tools installed. These commands report replication state; they do not force replication.

repadmin /replsummary
repadmin /showrepl

/replsummary provides a high-level view of failures and replication age. /showrepl shows inbound replication status and the last attempt for each naming context and partner. Preserve the error code, source and destination controller, naming context, last success, failure count, and test time.

Possible category

Name resolution

A controller cannot resolve a partner's required DNS name or locator data.

Possible category

RPC or connectivity

The destination cannot reach the source through the required network path or service endpoint.

Possible category

Authentication or time

Access-denied, trust, Kerberos, or time-skew evidence may interrupt replication without identifying one universal cause.

Possible category

Lifecycle or topology

A controller may have been offline too long, restored improperly, or decommissioned incompletely, or the configured topology may not match connectivity.

If you add Active Directory PowerShell cmdlets to a separate investigation, install the Active Directory module through the applicable AD DS RSAT capability first. This guide does not require those cmdlets.

Phase 8 · Time, services, and logs

Check supporting signals over the same time window.

Time synchronization

Record status and the current source.

w32tm /query /status
w32tm /query /source

Record the source, last successful synchronization, stratum, and any visible offset or error. Time-related authentication problems require comparison between the affected member, its selected controller, and the domain time hierarchy; one source string alone is not a complete health test.

Domain-controller services

Inspect role-relevant services without changing them.

Get-Service -Name NTDS,DNS,Netlogon,Kdc,W32Time,ADWS,DFSR -ErrorAction SilentlyContinue |
    Select-Object Name, DisplayName, Status, StartType

The list covers Active Directory Domain Services, DNS Server, Netlogon, Kerberos Key Distribution Center, Windows Time, Active Directory Web Services, and DFS Replication where those roles and services are installed. Missing or stopped entries must be interpreted against the controller's installed roles and the original symptom.

Focused event review

Use a bounded time window and preserve provider context.

$since = (Get-Date).AddHours(-4)

Get-WinEvent -FilterHashtable @{LogName='Directory Service'; StartTime=$since; Level=2,3} -MaxEvents 100
Get-WinEvent -FilterHashtable @{LogName='DNS Server'; StartTime=$since; Level=2,3} -MaxEvents 100
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$since; Level=2,3} -MaxEvents 100
Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; StartTime=$since; Level=2,3} -MaxEvents 100

These are the Directory Service, DNS Server, System, and DFS Replication logs. Focus on events aligned with the symptom and other findings. A warning or stopped service without matching impact, timing, and dependency evidence is not proof of root cause.

13 · Evidence correlation

Separate what was observed from what it may mean.

Observation What it may indicate What it does not prove Safest next investigation step
Client points to a public DNS resolver. The client may be unable to resolve the private AD namespace and locator records. That DNS configuration is the only issue. Confirm the active interface and compare its configuration with an approved, working peer.
AD SRV records do not resolve. The selected resolver lacks, cannot reach, or cannot return required locator data. Every domain controller or the directory database has failed. Query the same record through each approved internal resolver and review registration and zone scope.
One internal DNS server answers while another does not. Resolver data, reachability, zone loading, delegation, or AD-integrated replication may differ. Which server contains the authoritative correct state. Preserve both responses and correlate them with DNS-server health and AD replication.
Domain-controller discovery fails. DNS locator data, Netlogon, site awareness, LDAP reachability, or client connectivity may be involved. The secure channel is broken or the domain is unavailable everywhere. Compare SRV results, client DNS configuration, site/subnet scope, and locator behavior from a working peer.
Replication summary shows failures. A named source/destination pair and naming context has a current replication problem. One universal root cause or that all authentication must fail. Use repadmin /showrepl and matching Directory Service events to preserve the exact error context.
Replication is healthy but user authentication remains affected. The issue may be local to discovery, time, secure channel, account state, Kerberos, connectivity, or the application. Authentication or DNS is healthy. Trace the affected user's actual client, selected controller, time, and service path.
Time source or status appears incorrect. The member or controller may not be following the intended domain time hierarchy. Time is the sole cause of the reported symptom. Compare status, source, and event timing across the affected system and relevant controller.
A retired domain controller still appears in DNS or AD. Decommissioning may be incomplete or stale data may remain. That deleting the visible record is safe or sufficient. Stop and review lifecycle records, role ownership, replication, backups, and metadata with an experienced AD administrator.
DNS tests pass but application connectivity still fails. Name resolution is only one completed dependency. RPC, SMB, LDAP, TLS, authentication, firewall, routing, or the application is healthy. Continue with the narrowest authorized connectivity and service check for the original application path.

14 · Escalation

Stop when the evidence exceeds routine investigation.

Escalate with the evidence collected so far when any of the following applies:

Broad controller failure

Multiple domain controllers fail simultaneously, replication failures are widespread, or SYSVOL or NETLOGON availability is uncertain.

Role or lifecycle uncertainty

FSMO role ownership is unclear, a controller may be stale or improperly restored, or decommissioning appears incomplete.

Complex directory recovery

Lingering objects, metadata cleanup, unsupported restoration, SYSVOL repair, or directory recovery may be involved.

Security concern

Credentials, compromise, ransomware, unauthorized change, or evidence-integrity concerns require incident-response handling.

Recovery readiness unknown

The operator cannot confirm current backups, recovery capability, change approval, or an accountable owner for remediation.

15 · Intentionally excluded

This guide does not provide operational repair steps.

Excluded actions include changing DNS server addresses; restarting domain services; resetting secure channels; forcing replication; seizing or transferring FSMO roles; metadata cleanup; removing domain controllers; editing AD-integrated DNS zones; modifying registry settings; repairing SYSVOL or DFS Replication; disabling security controls; restoring domain controllers; or bypassing authentication or execution policy.

Those actions require a separately scoped remediation plan, current backups, change approval, rollback and recovery planning, and environment-specific review by an experienced owner.

16 · Related KrippyTech resources

Continue with the appropriate learning or tool path.

DNS procedure

Use Test-KTDNS v1.0.0

Review checksum verification, approved parameters, normalized output, DNS-only behavior, and safe interpretation.

Open the Test-KTDNS tutorial

Published source

Review Test-KTDNS.ps1

Read the immutable v1.0.0 script before using it in an authorized environment.

Open the published script

Tool library

PowerShell Library

Review release requirements, supported records, packaging, and integrity guidance.

Open release details

Learning hub

Windows & Hybrid

Place DNS and domain evidence in the wider Windows infrastructure dependency chain.

Explore Windows & Hybrid

Microsoft technical references

Primary documentation used for this guide.