networking-dns▌
TCP/UDP/IP fundamentals, DNS resolution, and HTTP/TLS — the toolkit Session 3's troubleshooting scenarios lean on directly.
Why this layer next
This is the toolkit Session 3 leans on directly — Scenario-1 in written_questions.md is a networking problem wearing a Docker costume, and "why can't service A reach service B" is one of the most common angles in both the written round and the verbal one.
What's in this session
| page | covers |
|---|---|
| tcp/udp/ip | handshakes, ports & sockets, TCP vs UDP tradeoffs |
| dns | full resolution chain, record types, TTL |
| http/tls | request/response, status codes, TLS handshake |
tcp, udp, ip — the transport and network layer protocols underneath everything you'll troubleshoot. All three are genuinely real: man 7 tcp, man 7 udp, man 7 ip.
How a packet actually moves
IP handles addressing and routing — every packet carries a source and destination IP, and routers along the path forward it hop by hop based on the destination, with no guarantee any two packets take the same route. IP itself doesn't care whether the packet arrives, arrives in order, or arrives at all — that's the transport layer's job.
TCP — reliable, ordered, connection-based
TCP opens an explicit connection before any data flows: the three-way handshake — SYN → SYN-ACK → ACK — then a FIN exchange to close it cleanly. Every byte is acknowledged, retransmitted if lost, and reassembled in order at the receiver even if packets arrive out of sequence. That reliability costs overhead: the handshake itself, acknowledgment traffic, and head-of-line blocking if a packet is lost. TCP is what HTTP/HTTPS, SSH, and database connections ride on — anywhere correctness matters more than raw speed.
UDP — fast, no guarantees
No handshake, no acknowledgment, no ordering guarantee, no retransmission. A UDP packet is sent and forgotten — if it's lost, the application layer has to notice and handle it, not UDP. That low overhead is exactly why DNS queries, video/voice streaming, and real-time telemetry use it: a dropped voice packet is a barely-noticeable glitch; waiting for a TCP retransmit would be a worse experience than just moving on.
Reliability isn't the only difference people cite — ordering matters too. UDP packets can arrive out of order or duplicated; TCP guarantees the byte stream arrives in order even if it means buffering out-of-order segments at the receiver until the gap is filled.
Ports & sockets
A port is just a 16-bit number identifying which application on a host a packet is for. A socket is the full tuple that actually identifies a connection: source IP, source port, destination IP, destination port, and protocol — which is why a server can hold thousands of simultaneous TCP connections on port 443 and keep them all straight.
"Both the synchronous fraud-scoring call and the async Kafka/Kinesis enrichment pipeline ride on TCP underneath — sync because the caller needs the ordered, reliable response before approving a transaction; async because even though Kafka handles its own ordering at the application level, you still want TCP's reliability for the underlying byte stream."
resolver(5) documents /etc/resolv.conf specifically — real further reading — but this page covers the full resolution process DNS actually runs, end to end.
The resolution chain, step by step
A DNS lookup checks a stack of caches before ever leaving your machine: the application's own cache, then the OS resolver cache, then whatever's configured in /etc/resolv.conf as the recursive resolver — your ISP's, or a public one like 8.8.8.8 / 1.1.1.1. If none of those have an answer, the recursive resolver does the actual walk: the root server points it to whichever server handles the TLD (.com, .org...), that TLD server points it to whichever server is authoritative for the specific domain, and the authoritative server finally returns the real record. The answer gets cached at every level along the way, for as long as the record's TTL says it's valid.
Record types
| type | purpose |
|---|---|
| A | hostname → IPv4 address |
| AAAA | hostname → IPv6 address |
| CNAME | alias — one hostname points to another hostname |
| MX | mail server(s) for the domain, with priority |
| TXT | arbitrary text — SPF/DKIM verification, domain ownership |
| NS | delegates a zone to specific nameservers |
| SOA | zone's authority record — primary NS, admin contact, refresh/retry defaults |
| PTR | reverse lookup — IP → hostname |
TTL — why "it's just slow to update" is really a caching problem
A record's TTL, in seconds, is how long any resolver is allowed to cache it. Low TTL means faster propagation of changes but more lookup traffic; high TTL means the opposite — and it's exactly why a DNS cutover (new load balancer IP, migrating providers) can take anywhere from minutes to the old TTL's full duration to be visible everywhere, even after the record itself is already updated at the authoritative server.
DNS queries mostly use UDP — fast, one round trip — but fall back to TCP when a response won't fit in a single UDP packet (large record sets, DNSSEC), and zone transfers between nameservers always use TCP. "DNS is UDP" is only mostly true.
Cloud DNS, briefly
Inside AWS specifically, Route 53 plays both roles — public DNS for a domain, and private hosted zones for name resolution inside a VPC that never touches the public internet. More on this in the AWS session; for now, the resolution mechanics above are exactly what's happening either way.
"Inside our EKS cluster, service-to-service calls — the fraud-scoring API reaching the feature store, say — resolve through Kubernetes' own internal DNS, CoreDNS, not public DNS. If a pod can't reach another service, running dig from inside that pod against the cluster DNS is one of my first checks, before I start suspecting a network policy or security group."
the application-layer protocol almost everything in this stack ultimately speaks, and the encryption wrapped around it.
Request/response, briefly
Every HTTP request is a method (GET, POST, PUT, DELETE...), a path, headers, and optionally a body; every response is a status code, headers, and optionally a body. That's the whole shape — the complexity is all in what goes in those headers and bodies.
Status codes worth having cold
| code | meaning | when you'll see it |
|---|---|---|
| 200 | OK | successful request |
| 201 | Created | POST that created a resource |
| 400 | Bad Request | malformed request — client's fault |
| 401 | Unauthorized | missing or invalid credentials |
| 403 | Forbidden | authenticated, but not allowed |
| 404 | Not Found | — |
| 429 | Too Many Requests | rate limited |
| 500 | Internal Server Error | your app crashed handling the request |
| 502 | Bad Gateway | proxy/LB got an invalid response from the backend |
| 503 | Service Unavailable | backend overloaded or down |
| 504 | Gateway Timeout | backend didn't respond in time |
A 502 means the load balancer/proxy got an invalid response from the backend, or none at all — that's usually a backend/app problem wearing a proxy error code, not the proxy's own fault. 504 specifically means the backend didn't respond in time. Mixing these up is an easy interview tell.
TLS handshake, conceptually
Client sends a "client hello" — supported cipher suites, a random number. Server replies with its certificate and the chosen cipher. The client validates that certificate against a trusted CA, then client and server derive a shared symmetric session key through a key exchange (ECDHE, typically, for forward secrecy). From there, traffic is encrypted with the fast symmetric cipher — the certificate's whole job was proving identity and letting both sides agree on that secret without ever sending it in the clear.
Where TLS actually ends
Terminating TLS at the load balancer (ALB/NLB) and running plaintext internally is common and fine for most traffic. For regulated fintech traffic specifically, PCI-DSS scope considerations often push toward re-encrypting from the load balancer to the backend too, so transaction data is never in the clear anywhere on the internal network — not just at the edge.
"For transaction data, I'd want to confirm — not just assume from a console setting — that the cert chain actually being served is what compliance expects. openssl s_client against the real endpoint tells you the truth; the console can be stale."
seven hands-on tasks — do these on any machine with a terminal and internet access. Progress saves automatically.
loading progress…