A library consortium compares SSH management sessions that use a three-way handshake with lightweight DNS queries on the same municipal network. What contrast is most accurate?
Select an answer to reveal the explanation.
Short Explanation
SSH is like booking a reserved table—three-way handshake, then the meal. Many DNS lookups are more like shouting a quick question across the room with UDP. Different jobs, different overhead.
Full Explanation
Library-consortium SSH management sessions use TCP's three-way handshake and connection state, while many DNS queries on the same municipal network use lightweight UDP queries/responses without that session setup. The accurate contrast is overhead versus lightness: TCP sessions add handshake and state for reliable interactive management (SSH), whereas typical small DNS lookups ride UDP for speed and simplicity. That comparison is what the stem asks the team to recognize.
DNS always requires a TCP three-way handshake before every tiny query fails because most ordinary DNS queries use UDP; TCP is used for specific cases (e.g., truncated responses, zone transfers), not "always" for every tiny query. SSH runs exclusively over UDP to avoid any connection state fails by concept—SSH is TCP-based and depends on connection-oriented delivery. Both SSH and DNS forbid any transport headers on municipal networks fails as nonsense; both use standard IP transport headers.
Exam caveat: SSH → TCP + handshake; typical DNS query → UDP. Know the exceptions (DNS over TCP) without turning them into "always."
Operational check: Capture an SSH session setup and observe the three-way handshake before shell traffic; capture a routine DNS lookup and observe a UDP query/response without TCP handshake. If someone claims every DNS query must TCP-handshake first, correct that operational misconception against what the wire shows.