Branch stores at a retailer start resolving a corporate name to an unexpected address, and users reach the wrong site. Which reading fits that evidence?
Select an answer to reveal the explanation.
Short Explanation
If the street sign for your store is suddenly pointing at a different building, the road did not get narrower. You treat DNS answers that moved to an unexpected address as DNS hijacking. More bandwidth, a quality-of-service retune, or a new laptop does not explain a name that now resolves to the wrong place.
Full Explanation
Users reach the wrong site because the corporate name now resolves to an unexpected address. That is DNS hijacking: the answer itself was substituted, so the path that follows is toward the attacker's destination rather than the retailer's. Adding bandwidth assumes the circuit is congested. Busyness does not rewrite a DNS answer, and a larger circuit still delivers users to whatever address the resolver returned. Retuning quality of service may change how DNS packets are queued. It does not correct an answer that already points at the wrong address, and a higher class for those answers would only deliver the bad result faster. Replacing the laptop that first showed the address assumes an endpoint fault. The same unexpected answer at branch stores points at the resolver path, not at one device's hardware. Inspect where the stores get DNS, compare the answer with the address the name should have, and contain the hijack before any capacity or endpoint change. Exam caveat: a name that resolves to the wrong place is a security event even when the circuit and the laptop look healthy. Operational check: query the name from an affected store and from a known-good resolver, and compare the addresses.