Networking Fundamentals: DNS, HTTP/HTTPS, Load Balancer, and Proxy

Networking is the foundation of system design. This post starts from actual commands to understand DNS lookup, HTTP/HTTPS, TLS, Load Balancer, and Proxy concepts — skills you use in every deployment.

DNS

Domain Lookup from the Command Line

1
2
3

dig google.com
dig +short example.com
dig +short example.com CNAME

dig is a DNS query tool. +short shows only the result, omitting noise.

Output interpretation:

1
2
3
4
5
6

;; QUESTION SECTION:
;google.com.    IN    A          # query A Record (IP address)

;; ANSWER SECTION:
google.com.  300  IN  A  142.250.x.x   # TTL = 300 seconds
google.com.  300  IN  A  142.250.x.x

Google returns multiple IPs, which is Client-side Load Balancing — DNS returns multiple IPs and the client picks one to connect to.

Direct Mapping Versus Name Redirect

A Record: domain → IP (directly gives the address)

1

example.com  →  1.2.3.4

CNAME: domain → another domain (alias, then resolve that domain’s IP)

1
2

blog.example.com  →  user.github.io  # alias
user.github.io    →  140.82.x.x      # actual IP

Cache Duration Controls

TTL (Time To Live) = seconds for DNS cache.

• TTL 300 = computer caches this result for 5 minutes, no re-query within 5 minutes
• After changing a DNS record, you must wait for the TTL to expire before it takes full effect
• Shorter TTL means changes propagate faster, but increases DNS server load

Apex Domain Alias Lookup

An apex domain (e.g., example.com) technically cannot have a CNAME (DNS standard restriction). DNS services like Cloudflare automatically flatten it into an A Record when returning, called CNAME Flattening.

In Proxied mode, Cloudflare doesn’t return the real CNAME or origin IP, only its own proxy IP. So dig example.com CNAME might return empty.

DNS in Kubernetes and Cloud Deployments

• K8s internal services call each other via CoreDNS (kube-dns)
• Pod finds other services: service-name.namespace.svc.cluster.local
• Deploying new services requires pointing a domain to the Load Balancer IP

Request Protocols and Transport Encryption

Detailed Request Tracing for Connection Diagnosis

1

curl -v https://example.com 2>&1 | head -40

-v shows verbose information. 2>&1 merges stderr into stdout so head can truncate both.

Actual output excerpt:

1
2
3
4
5
6
7

* Trying x.x.x.x:443...
* TLSv1.3 (OUT), TLS handshake, Client hello   # client proposes cipher suites
* TLSv1.3 (IN),  TLS handshake, Server hello   # server selects TLSv1.3
* TLSv1.3 (IN),  TLS handshake, Certificate    # server sends certificate
* TLSv1.3 (IN),  TLS handshake, Finished       # encrypted channel established
> GET / HTTP/2                                  # HTTP request (inside encrypted channel)
< HTTP/2 200                                    # response

Handshake Order: TCP Then TLS

1
2
3
4
5
6
7
8

TCP 3-way handshake     (establish connection)
  SYN -> SYN-ACK -> ACK

TLS handshake           (establish encryption, on top of TCP)
  Client Hello -> Server Hello -> Certificate -> Verify -> Finished

HTTP request            (transmitted inside encrypted channel)
  GET / HTTP/2

TCP handshake and TLS handshake are two different things. TCP must complete first before TLS begins.

Server Certificate Details

1
2
3

subject: CN=example.com        # certificate issued for this domain
issuer: Google Trust Services  # certificate authority
expire date: ...               # expiry date (auto-renewed by Cloudflare)

DNS in Kubernetes and Cloud Deployments

• Certificate expiry → service goes down, a common incident
• curl -v is the basic tool for troubleshooting TLS issues
• Ingress Controller does TLS termination, certificates are configured on the Ingress, backend Pods receive plain HTTP

Entry Intermediary Versus Exit Relay

Outbound Traffic Intermediary

1

Client -> Proxy Server -> Target Website

Proxies client outbound requests. The target website sees the Proxy’s IP, not yours.

Common uses: corporate network control, VPN, hiding real IP. Windows Network Manager and browser proxy settings use this.

Incoming Traffic Intermediary

1

Client -> Reverse Proxy -> Your Server

Proxies server to receive requests. Users see the Proxy’s IP, not the server’s real IP.

Common uses: Cloudflare, Nginx, K8s Ingress Controller.

Mnemonic:

• Forward Proxy = helps the client go out
• Reverse Proxy = helps the server receive incoming

The Web Server Pulling Double Duty as Origin and Intermediary

Nginx can simultaneously be:

• Web Server: directly serves HTML/CSS/images
• Reverse Proxy: forwards requests to backend applications

K8s’s Nginx Ingress Controller uses the second role.

Traffic Distribution Across Multiple Backends

Single-Server Throughput Ceiling

When a single server can’t handle large traffic volumes, you need multiple Pods. A Load Balancer sits in front, distributing requests across the Pods behind it.

Transport-Layer Versus Application-Layer Routing

K8s mapping:

• ClusterIP Service ≈ L4 (TCP forwarding, doesn’t inspect HTTP content)
• Ingress ≈ L7 (routes based on URL, implemented by Traefik or Nginx)

Distribution Strategies

Round Robin: Sequential rotation

1
2
3
4

request 1 -> Pod 1
request 2 -> Pod 2
request 3 -> Pod 3
request 4 -> Pod 1  # back to the first

Suitable for: REST APIs where request processing times are similar. LB needs almost no extra computation, highest performance.

Least Connections: Send to the Pod with the fewest current connections

1
2
3

Pod 1: 100 connections
Pod 2:  20 connections  # next request goes here
Pod 3:  80 connections

Suitable for: Services with highly variable request processing times (e.g., video transcoding). The tradeoff is the LB must continuously track each Pod’s connection count, which adds overhead to the LB itself under high traffic.

IP Hash: Same IP always hits the same Pod

Suitable for: Legacy systems needing sticky sessions (sessions stored in a specific server’s memory). Modern systems usually store sessions in Redis, eliminating the need for IP Hash.

HTTP Route Definitions Versus the Daemon Enforcing Them

Ingress has two layers:

Ingress Resource (YAML) = routing specification, does nothing by itself

1
2
3
4
5

rules:
  - path: /api
    backend: go-api-service
  - path: /web
    backend: frontend-service

Ingress Controller = the program that actually executes routing, needs to be installed separately or provided by the cloud

1
2

kubectl get svc -n kube-system  # check installed ingress controller
kubectl get ingress -A          # check routing rules

Long-Lived Connections and Transport-Layer Affinity

Request-Response Versus Bidirectional Stream

HTTP is a request-response model. Each request is independent, the server cannot proactively push data.

WebSocket establishes a connection once and keeps it open. The server can push data to the client at any time.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

HTTP (polling):
Client -> Server: "any new messages?"
Server -> Client: "no"
Client -> Server: "any new messages?"
Server -> Client: "yes, here it is"

WebSocket:
Client <-> Server: (connection established, kept open)
Server -> Client: "new message!"
Server -> Client: "another message!"

Application-Tier Distribution Can Disrupt Long-Lived Connections

L7 LB might send different packets from the same user to different Pods, causing the WebSocket session to break.

L4 LB operates at the TCP layer. Once a connection is established, the entire session stays on the same Pod, and WebSocket works properly.

Real-Time Use Cases

• Real-time customer chat widgets
• Online gaming
• Live stock quotes
• IoT device control (e.g., smart plugs, light bulbs)

Shell Networking Tools

Output Stream Handling

1
2
3

0 = stdin   (input)
1 = stdout  (normal output)
2 = stderr  (error output)

1
2
3
4

command > file.log        # redirect stdout to file
command 2>/dev/null       # discard stderr
command 2>&1              # merge stderr into stdout
command > file.log 2>&1   # redirect both stdout and stderr to file

| head -40 only truncates stdout entering the pipe. stderr doesn’t enter the pipe, so it’s not affected by head. Adding 2>&1 lets head truncate both.

Diagnostic Command Reference

References

• DNS - MDN Web Docs
• How HTTPS works - curl documentation
• TLS Handshake - Cloudflare Learning
• CNAME Flattening - Cloudflare Docs
• WebSocket - MDN Web Docs
• Kubernetes Ingress - Official Docs
• Nginx Ingress Controller
• Traefik on k3s