A township board finds a contractor’s rogue DHCP appliance answering on an access port. What DHCP snooping trust model stops offers from that port while allowing the real server path?
Select an answer to reveal the explanation.
Short Explanation
Untrusted access ports are ‘client only’—rogue DHCP offers get dropped. Trusted uplinks are where the real DHCP server or relay lives. Flip that and you’ve invited the contractor’s box to hand out addresses.
Full Explanation
DHCP snooping builds a binding table from legitimate DHCP transactions and drops DHCP server messages on untrusted ports. The correct trust model for a township board facing a contractor’s rogue DHCP appliance is to leave access ports untrusted and mark only uplinks toward legitimate DHCP servers or relays as trusted, so rogue offers on access ports are dropped.
Trusting every access port and untrusting only the DHCP server uplink inverts the model and invites rogue servers. Disabling snooping and relying on static /32 routes for each client fails to block rogue DHCP. Marking all ports untrusted including uplinks toward the legitimate server breaks valid DHCP delivery.
Exam caveat: access = untrusted, server/relay uplinks = trusted—trust inversion is the classic wrong answer.
Operational check: configure snooping with correct trust, verify the rogue appliance’s offers are dropped, confirm clients still lease from the real server, and review bindings for the township access layer. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.