Monitoring Benefit
The Domain Records test verifies that each DC or RODC can resolve the domain-scoped service locator records from its configured network interface, against each DNS server that interface is configured to use.
These are the records clients and other domain controllers use to find the domain's services. If they cannot be resolved the domain is still running, but nothing can locate it — which presents as logon failures, Group Policy not applying, time sync drifting and password changes failing, all at once and with no obvious common cause.
What it checks
| Record | What depends on it |
|---|---|
| PDCSRV | Locating the PDC emulator — password changes, account lockout processing, and the authoritative time source for the domain |
| KDCSRV | Locating a KDC for Kerberos authentication |
| DCSRV | Locating a domain controller at all — the general DC locator |
The results page shows Interface, Record, DNS Server and Status. You will see three rows per configured DNS server — the set repeats for each one, so a DC with two DNS servers shows six rows. That repetition is the point: it proves every DNS server the DC relies on can answer, not just the first one that happens to respond.
This is the domain-scoped counterpart to Forest Records Status, which checks the forest-wide global catalog records.
How do we verify the results?
The ENow agent runs a WMI query periodically to collect the DNS records. This information is not logged, but the results are cached on the monitored server:
\Program Files (x86)\ENow\Mailscape Agent\Cache\NetworkAgentMessage.xml
To reproduce the check by hand, run the following on the DC or RODC, substituting your own DNS zone:
Get-DnsServerResourceRecord -ZoneName "yourdomain.com"That returns the whole zone and the output can be very long. To test the individual locator records the way the monitoring does — one record, against one named DNS server — query them directly instead:
Resolve-DnsName -Type SRV _ldap._tcp.pdc._msdcs.yourdomain.com -Server <dns server>
Resolve-DnsName -Type SRV _kerberos._tcp.dc._msdcs.yourdomain.com -Server <dns server>
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.yourdomain.com -Server <dns server>Run each against every DNS server the interface is configured with. A record that resolves from one server and not another is the exact condition this test exists to catch, and it is invisible if you only query the default.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| One record fails against one DNS server only | That server's copy of the zone. Check replication between DNS servers, and whether the zone is AD-integrated on both. |
| All three records fail against one DNS server | That DNS server cannot serve the zone at all — check it is running, authoritative, and reachable from this interface. |
| All records fail on every DNS server | Look at the DC's own registration. Restarting the Netlogon service re-registers the locator records. |
| PDCSRV fails, the others pass | Often follows an FSMO role move. Confirm where the PDC emulator role now lives and that its records registered. |
| Records missing after a new DC is promoted | Registration can lag promotion. If it persists, check dynamic update is permitted on the zone. |
| Intermittent failures | Usually scavenging removing records faster than they re-register, or two DNS servers disagreeing. Compare the record's timestamp on each server. |
Comments
0 comments
Article is closed for comments.