At a university, remote staff reach campus services with a public resolver, but the same laptops fail only while the home router is handing out its own DNS. Where should diagnosis start?
Select an answer to reveal the explanation.
Short Explanation
When the lights work on the city grid and die on one house fuse, you check that fuse first. Start with the DNS resolver the home router hands the laptop, because the failure shows up only while that local resolver is in use. Replacing a WAN circuit, paging on BGP, or moving a data-center agent chases a fault that never leaves the endpoint.
Full Explanation
The failure is conditional on the resolver the home router gives the laptop, and the same laptops succeed when a public resolver is used. Diagnosis therefore starts by correcting the DNS resolver in front of that endpoint, before any change to the wide-area path, because the evidence already localizes the fault to name resolution on the user side. Replacing the campus WAN circuit that carries remote-access traffic would be reasonable if every remote path failed regardless of resolver, and that pattern is absent here. Raising a BGP alert covering the university public address space watches routing advertisements for the campus prefixes, which does not explain a failure that appears and disappears with the home resolver. Moving the data-center Enterprise Agent into a different campus rack changes where a central probe sits, and a probe move cannot repair the resolver the home router is handing out. Exam caveat: end-device items often include a healthy core on purpose, and the factor that changes with the failure is the fact to follow. Operational check: on one affected laptop, compare a lookup of a campus name using the home-router resolver with the same lookup using the public resolver, and confirm the break tracks the local resolver before any circuit or agent change is scheduled.