Reconstruct transport sessions, address allocation and name resolution without overstating what network evidence proves.
55 min 165 XPSkills: Transport analysis, Core service flows, DNS evidence
Brief
At Halcyon Clinics, a new ward can reach a server by address but not by name. The change owner blames a failed TCP handshake because the DNS capture has no SYN packets. Meanwhile an auditor has been handed a resolver log as proof that a patient file left the network. Both claims confuse the service being used with the evidence actually collected.
You will follow a connection from transport selection through address assignment and name resolution. Your job is to distinguish delivery from application success, a cached answer from a fresh lookup, and an address lease from an authenticated person. Those distinctions determine whether a firewall rule, incident timeline or audit assertion is defensible.
A port number suggests a service; a packet or log proves only the activity visible at its collection point.
Transport state is not application success
TCP provides an ordered byte stream with sequence numbers, acknowledgements, retransmission and flow control. For a new connection, client SYN seq=100 is followed by server SYN+ACK seq=700 ack=101, then client ACK seq=101 ack=701. SYN consumes one sequence number. ACK identifies the next byte expected, not proof that the application processed earlier bytes. A completed handshake does not prove successful authentication or encryption.
UDP sends independent datagrams without a transport handshake, ordered delivery or transport retransmission. Applications may add recovery themselves. A missing UDP response could mean loss, filtering, a silent service or a capture gap; it is not a missing TCP ACK. TCP FIN requests orderly closure and consumes a sequence number; RST abruptly resets a connection. PSH encourages prompt delivery of buffered data, while ACK marks an acknowledgement field as valid. Repeated SYNs without replies suggest a failed connection attempt, not a proven intrusion.
For network-access controls, retain timestamped flow records, firewall decisions and appropriately scoped packet captures. An auditor asking whether a service was reachable needs direction, both endpoints, protocol and capture location. A SYN seen at the client cannot by itself establish that it reached the server.
TCP establishes sequence state; UDP does not establish transport connection state.
Ports describe service conventions, not guarantees
A flow is distinguished by source address, source port, destination address, destination port and transport protocol. A client might use TCP source port 51020 to destination port 443; its reply reverses those endpoints. Common destination conventions are SSH on TCP 22, SMTP relay on TCP 25, HTTP on TCP 80, HTTPS commonly on TCP 443, LDAP on TCP 389, and remote desktop on TCP 3389, with UDP also used by some remote desktop implementations. DNS uses UDP and TCP 53; NTP commonly uses UDP 123. HTTP/3 can use UDP 443, so a TCP-only rule is not equivalent to every form of HTTPS.
Most ordinary DNS questions fit UDP, but truncated responses can trigger TCP retry and DNS zone transfers use TCP. Blocking TCP 53 can produce selective failures even while small lookups work. LDAP on 389 and mail relay on 25 are not inherently encrypted merely because their port is familiar; encryption upgrades require separate verification. Nonstandard ports are possible, and an unauthorized program can listen on a conventional one.
Least-privilege firewall rules must specify transport, direction, source population and destination scope rather than just a service nickname. Preserve the approved rule, change authorization, observed flows and a test of denied traffic. An auditor should ask whether the observed protocol matches the authorized service, not whether the destination port looks reassuring.
DHCP binds a lease, not a person
On an initial IPv4 allocation, DHCP Discover, Offer, Request and Acknowledge form DORA. A client without an address commonly broadcasts from 0.0.0.0 UDP 68 to 255.255.255.255 UDP 67. A server offers an address and options; the client's initial broadcast Request names its selected server and requested address so other servers can withdraw offers. A relay can forward exchanges across routed boundaries, so a server need not share the client's broadcast domain.
The acknowledgement confirms a lease and options such as prefix mask, router and resolver addresses. With an eight-hour lease and default timers, renewal begins at four hours (T1, 50%) and rebinding at seven hours (T2, 87.5%) if renewal fails. Renewal usually starts as a unicast Request, not a new four-message discovery. An Offer alone is not a completed allocation, and a negative acknowledgement can require the client to stop using the address and restart acquisition.
A rogue server can offer a malicious router or resolver. Controls include limiting authorized server responses at access boundaries and monitoring unexpected server identifiers. Preserve lease start/end times, client identifier or hardware address, assigned address, relay context and options. Correlate leases with access authentication and clock offsets: a lease ties an address to a client identifier during an interval, not conclusively to a human.
DNS resolution and the limits of a cached trace
A host's stub resolver normally asks a recursive resolver to obtain an answer. On a cold cache, that resolver follows a root referral to the relevant TLD servers, then a TLD referral to authoritative servers, then asks an authoritative server for the name. Referrals identify where to ask next; the root does not usually return the final host address. Warm caches can skip most or all upstream steps. A CNAME alias can require another lookup before an A or AAAA answer is available.
A records carry IPv4 addresses; AAAA records carry IPv6 addresses; CNAME names an alias target; MX names mail exchangers with preference values; NS names authoritative servers; PTR supports reverse lookup; TXT carries text used by many policies; SOA supplies zone administration and timing information. TTL is a cache lifetime in seconds for a record set, not a guarantee that every observer sees a change at once. An answer cached at 09:00:00 with TTL 300 can remain reusable until 09:05:00; at 09:02:00 its remaining TTL is 180. Negative answers can also be cached using SOA-derived negative caching limits.
Resolver logs support detection and investigation, but a query proves neither a subsequent connection nor data transfer. Capture client or forwarding identity, query name and type, response code, returned records, TTL, timestamp, resolver identity and collection scope. Shared forwarders and encrypted DNS outside the monitored resolver affect attribution and coverage. Validate suspicious answers against time-aligned lease, flow and endpoint evidence; restrict access and retention because query names can reveal sensitive activity. An auditor should ask what population bypasses the resolver and how gaps are detected.
A cold lookup follows referrals; a valid cache entry can answer without contacting authority again.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: A handshake that was never required
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
A resolver receives a DNS question over UDP 53 and replies successfully. The incident lead calls it an incomplete TCP session because there is no SYN. A separate capture shows SYN, SYN+ACK, ACK to a web service, followed immediately by a segment whose reset flag is set. The lead labels that reset an orderly close.
Term bank, not all of these are right
UDPTCPRSTFIN
1.1Which transport carried the successful DNS exchange? (one acronym)
1.2Which TCP flag caused the abrupt termination? (one acronym)
Task 2: The lease spreadsheet
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
An analyst labels a server's DHCP Offer as the final lease grant. The trace actually continues with a client Request and then the server's final confirmation. The confirmed lease is eight hours, uses default timer percentages, and renews without loss. A manager insists renewal must wait until expiry.
Term bank, not all of these are right
OfferAcknowledge48
2.1Which DORA message confirms the lease after the Request? (one word)
2.2How many hours after the grant does default T1 renewal begin? (a number)
Task 3: The authoritative screenshot
Scenario sim+55 XP
Read the brief and answer both questions.
Incident brief
At 09:00 a recursive resolver caches an IPv6 address record with TTL 300. At 09:02 a screenshot shows the cached response; the operator calls it proof that the authoritative server was contacted again and that a connection to that address succeeded. Assume elapsed time is exactly 120 seconds and no refresh or override occurs.
Term bank, not all of these are right
AAAAA180300
3.1Which record type contains the IPv6 address? (one record type)
3.2What is the remaining cache lifetime at 09:02, in seconds? (a number)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon Clinics permits small DNS lookups but larger replies fail. Its draft calls DNS UDP-only, describes DHCP as a TCP service, and restarts a cached answer's full lifetime whenever it is read.
Write a service plan from the fixture: identify the DNS destination port and both transports, the initial DHCP client and server ports and ordered exchange, then calculate cache lifetime and state the missing corroboration needed before claiming data transfer.
Approved requirements and observation
DNS: allow both standard transports to the internal resolver only.
DHCP: initial IPv4 allocation, no existing lease.
Cache: original TTL 300 seconds; elapsed 120 seconds; no refresh.
Claim to assess: a DNS query alone proves data transfer.
Evidence requirement: name a flow record or packet capture as corroboration.
The audit packet mixes raw observations with conclusions. Its owner says every familiar port and successful lookup is proof of secure application use.
Judge each claim exactly as written. Accept technically supportable statements; reject unsupported claims using the single most specific reason. Do not infer missing telemetry.
Verdicts are accept or reject. Every rejection needs one reason code from: transport-overclaim | port-overclaim | lease-incomplete | query-overclaim.
Six proposed audit statements
NT-1: A completed TCP three-way handshake proves the application authenticated the user.
NT-2: A client receiving a valid UDP DNS answer need not perform a TCP handshake for that exchange.
NT-3: Destination TCP 443 alone proves this captured payload was encrypted.
NT-4: The resolver reuses a positive answer after 120 seconds of a 300-second TTL, absent refresh or override.
NT-5: A DHCP Offer alone confirms a completed initial address allocation.
NT-6: A DNS query log alone proves the client transferred a file to the returned address.
Reason meanings:
transport-overclaim = transport establishment is mistaken for application success
port-overclaim = a port number is mistaken for verified encryption
lease-incomplete = a proposed lease is mistaken for a confirmed allocation
query-overclaim = resolution activity is mistaken for subsequent data transfer
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Networking Fundamentals
Secure Protocols and PKI
Trace authenticated encryption from TLS negotiation to certificate lifecycle controls and VPN boundaries.
