On event days at a stadium, the same application name resolves to different addresses from the venue resolvers than from the club offices, by design of split-horizon DNS. Which test checks that behavior?
Select an answer to reveal the explanation.
Short Explanation
Two neighborhoods keep two different phone books on purpose, and you read each book where it lives. Split-horizon DNS that differs by site is checked with a DNS test from the venue and from the club offices. A path probe, a phone call, or a ticket-page load does not compare the two records.
Full Explanation
Split-horizon DNS is designed to return different addresses for the same name depending on which site asks, so a DNS test from the venue resolvers and from the club-office resolvers is what checks that behavior. The evidence that matters is the pair of records, not the quality of the path between the two sites. A network test of loss and jitter between the venue and the offices measures the path and does not display the addresses each site's resolvers return. A voice test from a venue handset to the club places a call and does not query DNS from both resolver sets. A web transaction that loads the public ticket page from one site uses the resolver at that site and does not line the two site-specific records up together. The exam trap is loading a page from one location and assuming the name is handled the same way from the other site. In production, query the application name from the venue resolvers and from the club-office resolvers, then compare the addresses with the split the design calls for. A path test can still be useful later if a correct address is unreachable, but it does not prove the split itself.