DNS TTL Killed a Migration — Computer Networks Interview

Every backend engineer, DevOps engineer, and full-stack developer eventually sits across from an interviewer who asks 'What happens when you type a URL into a browser?' That question alone can make or break a senior-level interview. Networking isn't just a theoretical subject — it's the invisible infrastructure that your APIs, databases, and microservices live on. Understanding it deeply separates candidates who just write code from engineers who understand systems.

The OSI Model — Why 7 Layers Actually Matter in Practice

The OSI (Open Systems Interconnection) model is a framework that breaks network communication into 7 distinct layers. Most people memorize the names ('Please Do Not Throw Sausage Pizza Away') and stop there. That's a mistake. Understanding what each layer is responsible for helps you debug real problems.

[Image of the 7 layers of the OSI model]

When your HTTP request fails, is it a DNS issue (Layer 7/5), a TCP connection problem (Layer 4), or a routing issue (Layer 3)? Knowing the layers lets you mentally narrow down where the fault is, just like a doctor using anatomy to diagnose illness.

In practice, you rarely work below Layer 4 (Transport) unless you're writing embedded systems or kernel code. But you absolutely need to understand Layers 3, 4, and 7 — IP addressing, TCP/UDP, and application protocols — because they appear in every production debugging scenario, from a failing API call to a slow database connection.

Here's the critical insight: layers are about separation of concerns. Each layer only talks to the layer directly above and below it. That's why you can swap out Wi-Fi for Ethernet (Layer 1/2 change) without rewriting your HTTP code (Layer 7). The abstraction is intentional and powerful.

package io.thecodeforge.networking;

import java.net.InetAddress;
import java.net.Socket;
import java.io.PrintWriter;
import java.io.BufferedReader;
import java.io.InputStreamReader;

/**
 * Demonstration of OSI Layers 3, 4, and 7 in a production Java context.
 */
public class OsiLayerInspector {
    public static void main(String[] args) {
        String host = "example.com";
        int port = 80; // Layer 4 (Transport) Port

        try {
            // Layer 3 (Network): DNS Resolution
            InetAddress address = InetAddress.getByName(host);
            System.out.println("[L3 - Network] Resolved " + host + " to " + address.getHostAddress());

            // Layer 4 (Transport): TCP Connection established via Socket
            try (Socket socket = new Socket(address, port);
                 PrintWriter out = new PrintWriter(socket.getOutputStream(), true);
                 BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()))) {
                
                System.out.println("[L4 - Transport] TCP connection established (Handshake complete)");

                // Layer 7 (Application): Raw HTTP Protocol communication
                out.println("GET / HTTP/1.1");
                out.println("Host: " + host);
                out.println("Connection: close");
                out.println();

                System.out.println("[L7 - Application] HTTP Request Sent");
                String responseLine = in.readLine();
                System.out.println("[L7 - Application] Server Response: " + responseLine);
            }
        } catch (Exception e) {
            System.err.println("Connection Failed at specific layer: " + e.getMessage());
        }
    }
}

TCP vs UDP — Choosing the Right Delivery Guarantee

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are the two workhorses of the Transport layer, and choosing between them is one of the most consequential decisions in system design.

TCP is like sending a package with signature confirmation. Before any data moves, there's a 3-way handshake (SYN, SYN-ACK, ACK). Every packet is numbered, acknowledged, and retransmitted if lost. Order is guaranteed. This reliability costs time — that handshake adds latency, and the acknowledgment mechanism adds overhead.

UDP is like dropping a flyer through every door in the neighbourhood. You send it and forget it. No handshake, no acknowledgment, no guarantee of delivery or order. But it's blazingly fast, which is exactly what you need for real-time applications.

In modern systems, QUIC (used by HTTP/3) is effectively UDP with reliability built on top of it — proof that the TCP/UDP choice isn't always binary.

package io.thecodeforge.networking;

import java.net.*;
import java.nio.charset.StandardCharsets;

public class ProtocolComparison {

    // TCP: Reliable delivery for sensitive data
    public void tcpTransmission(String message) throws Exception {
        try (Socket socket = new Socket("localhost", 9001)) {
            socket.getOutputStream().write(message.getBytes());
        }
    }

    // UDP: Unreliable but fast for high-frequency updates (gaming/telemetry)
    public void udpTransmission(String message) throws Exception {
        try (DatagramSocket socket = new DatagramSocket()) {
            byte[] buf = message.getBytes(StandardCharsets.UTF_8);
            DatagramPacket packet = new DatagramPacket(
                buf, buf.length, InetAddress.getByName("localhost"), 9002
            );
            socket.send(packet);
        }
    }
}

DNS Deep Dive — What Actually Happens When You Type a URL

DNS (Domain Name System) is the internet's phonebook. You know the name (google.com), and DNS finds the phone number (IP address). But the process behind that lookup is more fascinating than most people realise — and it's a classic interview question.

When your browser needs to resolve 'api.github.com', it doesn't just ask one server. It walks a hierarchy. First, it checks its local cache. If that's empty, it asks your OS's resolver. If that misses, it queries your ISP's recursive resolver. That resolver then walks the DNS tree: it asks a Root Name Server for the authoritative server for '.com', then asks that server for 'github.com', then finally asks GitHub's authoritative DNS server for 'api.github.com'. The answer comes back and gets cached at every step.

# Using 'dig' to trace the iterative resolution process (standard interview tool)
# Trace github.com from the root servers down
dig +trace github.com

# Inspect the TTL (Time To Live) to understand caching behavior
dig github.com | grep "IN A"

HTTP vs HTTPS, Status Codes, and Subnetting — The Interview Essentials

These three topics appear in virtually every networking interview, so let's cover them with precision.

HTTP vs HTTPS: HTTP sends everything in plaintext. HTTPS wraps HTTP inside TLS (Transport Layer Security). The TLS handshake happens after the TCP handshake. After that, all data is encrypted.

HTTP Status Codes: These are a language. 2xx means success. 3xx means redirect. 4xx means the client made an error. 5xx means the server failed.

Subnetting: An IP address like 192.168.1.100/24 means the first 24 bits identify the network and the last 8 bits identify the host. /24 gives you 256 addresses (254 usable).

package io.thecodeforge.networking;

/**
 * Simulating CIDR mask logic for interview discussions.
 */
public class SubnetCalculator {
    public static void main(String[] args) {
        int prefix = 24;
        int totalHosts = (int) Math.pow(2, (32 - prefix));
        int usableHosts = totalHosts - 2; // Subtract Network and Broadcast

        System.out.println("CIDR /" + prefix + " allows for " + usableHosts + " usable hosts.");
    }
}

Production Network Debugging: Tools Every Engineer Should Know

Knowing theory is one thing. Being able to diagnose a real outage under pressure is what separates senior engineers. Here are the tools that matter in production:

dig — The DNS Swiss Army knife. dig +trace shows you the full resolution path. dig -x does reverse lookup.

curl — Every engineer's first tool for HTTP debugging. Verbose mode (-v) shows the entire handshake. -k bypasses certificate validation (for testing only!).

tcpdump — Raw packet capture. Filter by host, port, or protocol. -A prints ASCII payload. Critical for diagnosing retransmissions and dropped packets.

traceroute/mtr — Shows the path packets take and where latency spikes. mtr combines ping and traceroute in real-time.

netstat/ss — Check open ports, connection states, and socket buffers. ss -tuln lists all listening TCP/UDP ports. ss -s shows overall statistics.

In an interview, being able to describe a real debugging session (e.g., 'I used tcpdump to spot TCP retransmissions, then mtr to find a congested router') is worth more than reciting the OSI layers.

# Real scenario: slow API response
# Step 1: Check DNS
curl -s -o /dev/null -w "%{time_namelookup}\n" https://api.example.com
# If >5ms, DNS is slow

# Step 2: Trace the route
mtr --report-wide api.example.com

# Step 3: Capture traffic to see retransmissions
tcpdump -i eth0 -nn 'host api.example.com and tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -c 100

# Step 4: Check connection state
ss -tn state all dst api.example.com