Three Acceptance Tests.
Before the Edinburgh branch goes live, three protocols have to work. DHCP assigns addresses, DNS resolves names, TCP completes the connection. Each one runs on its own rules. Each one fails in its own way.
Fiona MacLeod dials into the teleconference at 07:45. The on-site contractor, Ross, is already in the Edinburgh office — eighty workstations, two comms rooms, stack of Cisco switches she specified herself. Branch live is Wednesday. Today is Wednesday. She has a checklist open in one window and Wireshark running in another, capturing from the office's management VLAN via a remote port mirror she set up the previous afternoon. She tells Ross to boot the first test laptop.
Test one: DHCP. The laptop comes up with no IP address — correct, the machine is clean, no static config. It immediately broadcasts a DHCPDISCOVER onto the local segment. Fiona can see it in Wireshark: source address 0.0.0.0, destination 255.255.255.255, UDP from port 68 to port 67. The client has no address yet, so it has to shout. This is the first step of DORA: Discover.
The branch's DHCP server — ISC DHCP on a Linux VM in the comms room — responds with a DHCPOFFER. It selects an address from the configured scope: 192.168.40.0/24, pool range .10 to .200, lease time 8 hours. The offer also carries the DHCP options: option 3 (default gateway, 192.168.40.1), option 6 (DNS servers, 10.0.0.53 and 10.0.0.54), option 42 (NTP server, 10.0.0.123), option 15 (domain name, company.local). This is everything a host needs to function on the network, delivered in a single message.
The client replies with a DHCPREQUEST — broadcasting its acceptance of the offered address back to the whole network. It broadcasts rather than unicasting because there may be multiple DHCP servers on the segment, and the broadcast lets other servers know their offers were declined. The server confirms with a DHCPACK. Four messages. The lease is established.
Ross runs ipconfig /all on the test laptop. IPv4 address: 192.168.40.12. Subnet mask: 255.255.255.0. Default gateway: 192.168.40.1. DNS servers: 10.0.0.53, 10.0.0.54. DHCP server: 192.168.40.5. Lease obtained: 07:51:03. Lease expires: 15:51:03. Everything Fiona sent in the offer is now on the client. She marks the first test.
Then Ross says there is a second laptop that was used by the on-site installer during the cabling stage. It already has an IP: 192.168.40.1 — hardcoded in the installer's router config, the same address the branch has assigned as its default gateway. Classic stale configuration conflict. The DHCP server can hand out addresses, but it cannot know that the gateway's address is already in use by a device outside its scope. Fiona asks Ross to open the DHCP server logs.
The logs show a DHCPNAK — a negative acknowledgement — sent to the installer's laptop, which requested a lease renewal and was told the address it held was no longer valid in this scope. The server had seen the conflict via a ping-before-offer check. It scoped the conflicting MAC address to the exclusion list. Fiona notes the MAC of the installer's laptop for the post-live cleanup and asks Ross to run ipconfig /release followed by ipconfig /renew. DORA runs again. New address: 192.168.40.47. Conflict resolved.
Before moving to test two she explains the security angle to Ross. A DHCP exhaustion attack floods the server with DISCOVER messages from spoofed MAC addresses, filling the lease pool until no addresses remain for legitimate clients — a denial of service at Layer 7. The defence is DHCP snooping: a feature on managed switches that builds a trusted binding table (port, MAC, IP, VLAN, lease time) and drops DHCP messages that arrive on untrusted ports or that attempt to impersonate a server. All the Edinburgh switches are configured for DHCP snooping. Only the uplink to the comms room is trusted.
Test two: DNS. Ross opens a browser and types intranet.company.local. The laptop's stub resolver — the OS DNS client — has no cached answer. It forwards the query to the first DNS server it received from DHCP: 10.0.0.53, the corporate recursive resolver. This is how almost all real DNS works: the client does not contact root servers directly. It asks a resolver to do the work.
The corporate resolver checks its own cache. Nothing there. It begins recursive resolution. First, it contacts a root nameserver — one of thirteen root server clusters that know where to find every top-level domain's nameservers. The root replies: for .local internal zones, I don't know — but here are the authoritative nameservers for company.local. The resolver queries the authoritative server for company.local, which returns an A record: intranet.company.local maps to 10.1.4.22, TTL 3600 seconds. The resolver caches the answer for one hour and returns it to the laptop. Round-trip: 48ms.
Ross then types outlook.office365.com into the browser. Same stub resolver, same corporate resolver — but this time the resolver cannot answer from the internal zone. Per Fiona's config, external queries are forwarded to Quad9 (9.9.9.9), a security-focused public resolver. Quad9 checks the domain against its threat intelligence blocklist, finds nothing of concern, and performs recursive resolution to Microsoft's authoritative nameservers. It returns a CNAME pointing to a Microsoft CDN, which resolves to an A record. The laptop gets the answer. The forwarding chain is: stub resolver → corporate resolver → Quad9 → root → TLD → authoritative. Each hop is visible in the Wireshark DNS decode.
Different DNS record types serve different purposes. A records map a hostname to an IPv4 address. AAAA records map to an IPv6 address (128-bit — four times longer than IPv4, hence four As). CNAME records are aliases: one name pointing to another canonical name, useful for CDN routing. MX records identify mail servers for a domain, ordered by priority. TXT records carry arbitrary text, used in practice for SPF (which servers may send email for this domain) and DKIM (cryptographic email signing keys). PTR records reverse the lookup: from an IP address back to a hostname, used in email validation and logging. NS records identify which nameservers are authoritative for a zone.
Each record carries a TTL — time to live — in seconds. Resolvers cache answers for the TTL duration. A TTL of 300 means the record expires in five minutes; the next query goes back to the authoritative server. A TTL of 86400 means it is cached for a day. Short TTLs reduce cache poisoning exposure; long TTLs reduce resolver load.
Fiona pulls up the DNS security configuration. The corporate resolver is running BIND 9 with DNSSEC validation enabled. DNSSEC adds cryptographic signatures to DNS records: each zone signs its records with a private key, and resolvers verify the chain of signatures from the root trust anchor down to the answer. If an attacker attempts DNS poisoning — injecting a forged response into the resolver cache by winning a timing race against the authoritative server — DNSSEC will reject the unsigned record because the signature will be absent or invalid.
DNS queries between the corporate resolver and Quad9 are encrypted. Fiona has configured the corporate resolver to connect to Quad9 using DoT (DNS over TLS) on port 853. The query and response are wrapped in a TLS session, which prevents the ISP or any on-path observer from reading or tampering with the lookup. She could have used DoH (DNS over HTTPS) on port 443 instead — it achieves the same encryption but blends into HTTPS traffic, making it harder to block or filter. DoT uses a dedicated port, which makes it easier to monitor and policy-control at the corporate firewall. Fiona chose DoT deliberately.
Finally, the corporate resolver is peered with the central SIEM team's DNS sinkhole. When a client resolves a domain that appears on the threat intelligence feed — a known malware C2, a phishing domain, a malicious redirect — the sinkhole returns a controlled IP that points to an internal warning page, rather than letting the connection complete. Splunk ingests the resolver logs; every sinkholed query generates an alert. Fiona spent two years building that pipeline. She is not sentimental about it, but she checks it first whenever a new branch goes live.
Test three: TCP. The final acceptance test is a VPN connection from the test laptop to the company's central hub site. The VPN client initiates a TLS-wrapped IPsec session, which means the first thing Fiona sees in Wireshark is a TCP handshake on port 443.
The laptop sends a SYN — synchronise — segment to the VPN concentrator. The SYN carries an initial sequence number, a randomly chosen 32-bit integer that will anchor all subsequent numbering for this connection. The concentrator replies with a SYN-ACK: its own initial sequence number plus an acknowledgement of the client's sequence number plus one. The client completes the handshake with an ACK. Three packets. The connection is established. TLS negotiation begins immediately over the open TCP session.
The three-way handshake exists because TCP is connection-oriented. Before a single byte of application data flows, both ends must agree that they can hear each other, exchange their sequence numbers, and confirm receipt. Every subsequent segment carries a sequence number; every received segment is acknowledged. If a segment is lost — no ACK received within the retransmission timeout (RTO) — TCP resends it. The receiving end reassembles segments in order regardless of arrival sequence. Fiona calls this "delivery with receipts." You cannot get a reliable file transfer, a correct HTTP response, or a stable VPN connection without it.
TCP's throughput is governed by the sliding window. Rather than sending one segment and waiting for an ACK before sending the next — which would be ruinously slow over high-latency links — TCP maintains a window: a quantity of unacknowledged data it is allowed to have in flight at once. As ACKs return, the window slides forward. The window size is advertised by the receiver and can shrink if the receiver's buffer is filling. This is flow control. Separate from congestion control, which adjusts the send rate in response to network conditions rather than receiver capacity.
The VPN connects cleanly. Fiona verifies routing — the Edinburgh subnet is being advertised correctly over the tunnel. She then runs the VoIP acceptance test: a call to the helpdesk number using the branch's new IP phone. The call uses RTP (Real-time Transport Protocol) over UDP. No SYN. No handshake. The phone starts sending 20ms audio packets immediately, and the helpdesk receives them, and if one is lost in transit neither end asks for a retransmission — the call continues, with perhaps a slight click in the audio, and the next packet arrives 20 milliseconds later. Real-time audio does not benefit from TCP's ordered, reliable delivery. By the time the retransmitted packet arrived, the moment it was meant to fill would already be past.
UDP is connectionless. It has no handshake, no sequence numbers, no retransmission, no guarantee of delivery or ordering. It is not a lesser protocol. It is the correct protocol for workloads where latency matters more than completeness: VoIP (RTP), video conferencing, DNS queries, DHCP, NTP, SNMP. The choice between TCP and UDP is always the same question: does the application need the network to guarantee every byte arrives in order, or does it need packets to arrive as quickly as possible?
At the OSI model level, TCP and UDP both sit at Layer 4 — Transport. DHCP and DNS are both Layer 7 — Application layer protocols, regardless of the transport they run over. DNS runs over UDP/53 for standard queries and TCP/53 for zone transfers and responses that exceed 512 bytes. DHCP runs over UDP/67 (server) and UDP/68 (client). Port numbers below 1024 are well-known ports, assigned by IANA and requiring root privileges to bind on UNIX systems.
DHCP assigns the address. DNS resolves the name. TCP completes the connection. Three separate protocols, three separate failure modes. The acceptance test is not done until all three are verified. — Story 04 · TCP, DNS, DHCP
At 10:22, Fiona marks all three tests passed in the acceptance sheet. She files the DHCP snooping configuration, the DNS resolver policy, and the Splunk sinkhole peer confirmation in the branch runbook. Ross asks if they need to do anything about the TCP RST (reset) packets he saw in Wireshark during the VPN test. She checks the capture. A firewalled port on the concentrator sent back a RST when the client probed it incorrectly during handshake. Expected behaviour. The graceful connection close — both sides exchanging FIN segments and acknowledging them — only happens on sessions that completed normally. A RST means one side terminated abruptly. In this case: a port probe was refused. Not a fault.
The Edinburgh branch goes live at 10:30. Fiona closes the Wireshark capture and archives it with the other acceptance test artefacts. Eighty staff. Three protocols. One stale router config. Everything else was clean on the first attempt.