Before starting
An isolated Windows lab guest with a recorded, working network baseline and a checkpoint. Use the VM console so a network change cannot disconnect your administration session.
Introduce the fault
Inside the guest only, record its current IPv4 DNS setting, then temporarily set DNS to the documentation-only address 192.0.2.53. Do not change the Linux host, router, VPS, or a production resolver. This is an intentional fault, not a recommended DNS configuration.
Diagnose before changing anything
- Record scope, error text, and whether another device is affected. Check the guest adapter, address, gateway, and DNS using ipconfig /all. Compare with the healthy baseline before making changes.
- Use nslookup example.com and record the resolver it tries and the actual response or timeout. Separately check gateway reachability and a previously verified numeric-IP destination or service. A ping failure alone does not establish an outage because ICMP can be blocked.
- Compare the failing configured-resolver query with a query to a known-working resolver reachable in this lab. If numeric connectivity also fails, investigate the adapter and route before blaming DNS. Browsers may use DNS over HTTPS or cached results, so their behavior can differ from nslookup.
Make the smallest appropriate change
Restore the guest adapter’s original DNS setting, usually automatic DNS through DHCP for the NAT baseline. If needed, run ipconfig /flushdns inside the guest. Cache clearing alone does not fix an incorrect DNS server.
Verify with the affected user
Run nslookup example.com again and record successful resolution through the intended resolver. Then test the intended website or service. Confirm both name resolution and the user’s original task work.
Restore the baseline
Restore the exact recorded DNS settings or revert the lab checkpoint. Confirm the host’s network and the original VM were never changed.
Know when to escalate
Escalate when multiple users share the failure, the authorized resolver is unavailable, or gateway routing, firewall policy, or a broader provider outage is implicated.
Evidence to collect
- Sanitized adapter and DNS settings before and after
- Failed lookup and a separate connectivity check
- Successful lookup after restoring the resolver
- A short note about browser caching or DNS over HTTPS
INTERVIEW REFLECTION
What evidence showed that name resolution, rather than general connectivity, was the fault?
Write the ticket
Use the downloadable ticket template. Record the symptom, scope, timeline, checks, observed cause, action, verification, rollback, and escalation decision. Leave dates, elapsed time, root cause, and result blank until the exercise is performed.
Publication gate: replace “Planned” only after the exercise is reproducible and sanitized evidence has been reviewed. Describe it as an independent lab simulation.