At 07:55 the reports arrive together: "the internet is down," "I can't log in," "the printer is offline." They are usually one failure in a core service, wearing three costumes.
This is the article to keep open during the first ten minutes. Each row is a symptom you can observe from a user's device, the causes worth checking in order, and the first command that distinguishes them.
The table
| Symptom | Likely cause | First check |
|---|---|---|
| Page fails instantly with NXDOMAIN | Name does not exist in the zone, or the wrong zone answered | nslookup name server against each resolver |
| Page hangs, then fails | Resolver unreachable or forwarder loop | nslookup against the resolver IP directly |
| Some sites work, others time out | Forwarder problem, or IPv6 AAAA with no path | Query the failing name directly; check AAAA |
| Logins take 90 seconds, then fail | SRV records missing, or clients pointed at public DNS | nslookup -type=SRV _ldap._tcp.dc._msdcs.domain |
| Device shows 169.254.x.x | No DHCP response: relay, scope, or server | Check relay config, then scope lease count |
| Address works, nothing loads | Option 3 (gateway) wrong, or firewall policy | ipconfig / ip addr, then ping the gateway |
| Names fail, pings by IP work | Option 6 wrong or resolver unreachable from that VLAN | nslookup against each listed resolver |
| Intermittent auth failures, no pattern | Clock skew beyond five minutes | w32tm /query /status, compare to DC |
| Certificate errors on internal sites | Expired certificate, or name mismatch after a move | Open the certificate, check dates and SAN |
DNS: three failures that look identical
NXDOMAIN means the name does not exist. The zone answered and said no. Check the record, then check whether the client is asking the right zone (split horizon makes this common).
SERVFAIL means the resolver tried and could not complete the lookup. Usually a broken delegation, a DNSSEC validation failure, or an upstream resolver refusing.
Timeout means no answer at all. The resolver is unreachable, the forwarder is looping, or a firewall is dropping port 53.
These require different fixes, and a browser reports all three as "can't find the server."
Test from the resolver, not from the client
nslookup name 10.0.0.3 tells you what the resolver knows. nslookup name tells you what the client's
configured resolver does. When they disagree, the problem is between the client and the resolver, and
that is a DHCP or firewall question.
DHCP: the four-minute diagnosis
- Does the device have a
169.254address? If yes, no DHCP response reached it. - Is there a relay on that VLAN? A scope without a relay produces exactly this.
- Does the scope have free leases? Check the address pool, not the service state.
- Is there a second DHCP server answering? A rogue server gives an address with a useless gateway.
If the device has an address but no connectivity, the problem is options, not DHCP itself: compare option 3 and option 6 for that scope against the subnet they should be serving.
NTP: the failure that blames everything else
Kerberos allows five minutes of skew. Beyond that:
- Domain logins fail with "clock skew too great," or with a generic logon failure.
- Kerberos tickets are rejected by services.
- Logs from different devices cannot be correlated, which makes the next incident harder.
Check the source, not just the offset:
w32tm /query /status
w32tm /query /source
If the source is Local CMOS Clock, the machine is not syncing at all. If it is an external address
and the offset is large, the path to that source is blocked or the source is wrong.
Certificates: the scheduled outage
Every internal service with TLS has an expiry date. Put them in one calendar:
| Service | Typical validity | Owner |
|---|---|---|
| LDAPS on DCs | 1–2 years | Identity |
| VPN / RADIUS | 1 year | Network |
| Internal web apps | 1 year | Applications |
| Wi-Fi 802.1X server cert | 1–2 years | Network |
Expiry is predictable, which makes it inexcusable. A weekly check that warns at 30 days costs ten minutes to build and prevents an outage that looks like a network failure.
The runbook shape
Every core service should have one page with:
- What it does and who depends on it.
- How to verify it from a client, not from the server.
- The three most likely failures and the first command for each.
- How to fail over, and how to fail back.
- Who to call if the first three steps do not explain it.
Checklist
- You can distinguish NXDOMAIN, SERVFAIL, and timeout without a browser.
- You know which relay serves each VLAN, and where the scope lives.
- NTP source and offset are monitored on the PDC and one member server.
- Certificate expiry is in a calendar with 30-day warnings.
- Each core service has a one-page runbook with verification steps.
Next
Core services are the foundation everything else assumes. The next series builds policy on top of them: Firewalls and Policy Engineering.