At a logistics hub, clients that use one internal DNS resolver receive the wrong address for a warehouse application, while every other resolver returns the correct record. Which test should the assurance team run?
Select an answer to reveal the explanation.
Short Explanation
Picture one directory at the dock that lists the wrong door while the others are right. You check that directory with a DNS test against the resolver that returns the bad address. A call test, a page load, or a path probe can look fine while clients are still sent to the wrong host.
Full Explanation
A DNS test pointed at the resolver that returns the wrong address queries that server for the warehouse name and records the answer clients of that resolver actually receive. Peer resolvers already return the correct record, so the fault sits in one server's data rather than in routing, loss, or the application process. Hosts that use the bad resolver are directed to the wrong destination even when the path to the real host is healthy. A voice test scores call setup delay and media quality, and the warehouse application is not failing as a call. A web transaction may load the home page slowly or fail after clients are sent to the wrong host, but it does not identify which resolver published the differing record. A network test reports packet loss, latency, and jitter, and those path metrics can stay healthy while the name still resolves to the wrong address. The exam trap is treating a successful path measurement or a successful page load as proof that every resolver is handing out the same address. In production, query the suspect resolver and a resolver that working clients already use, ask both for the same warehouse name, and compare the addresses they return.