DNS redirection concepts appear in a city's captive-portal lab. Why does DNS matter for portal behavior—without needing firewall recipes?
Select an answer to reveal the explanation.
Short Explanation
The portal needs your browser to show up at the login URL—DNS tricks and HTTP interception are how many labs shove you there after you associate. It is not Bluetooth art, a WPS PIN billboard, or a way to dissolve Enterprise encryption.
Full Explanation
DNS matters for captive-portal behavior because portals often rely on DNS or HTTP interception to force browsers to the login page—without needing a firewall recipe dump to understand the concept. Municipal guest networks steer unauthenticated clients to an AUP/login experience. Assessors studying portal classes should recognize DNS/HTTP steering as the usual mechanism theme.
'DNS is unused; portals only rewrite Bluetooth beacons' fails because DNS is not unused in favor of rewriting Bluetooth beacons for portals. 'DNS exists solely to publish WPS PINs to the Internet' fails because DNS does not exist solely to publish WPS PINs to the Internet. 'DNS redirection permanently converts WPA2-Enterprise into open auth' fails because DNS redirection does not permanently convert WPA2-Enterprise into open authentication.
Exam caveat: concept literacy beats config dumps on exam-style questions. Operational check: on a civic lab guest SSID, observe the pre-auth DNS/HTTP redirect to the portal page, capture screenshots for training, and ensure production redirects stay on authorized infrastructure. Monitor for unexpected portal URLs that could indicate twins. In municipal wireless operations, record the rationale in the engagement notes so future assessors know which control or technique class was chosen and which failure modes the rejected options would create for city services.