10 min read Web Infrastructure & Security Part 3 (9 / 16)
Part 3 — CI/CD & IaC

Lesson 12.09 — How Domain, DNS, HTTPS & Reverse Proxy Work

From raw public IPs to modern, hardened web delivery: DNS hierarchy, TLS encryption, Let's Encrypt automation, and Nginx reverse proxy architecture.

What We Will Master in This Lesson

In the previous lesson, we launched a Docker container on a Cloud VM and accessed our website directly via its public IP address (such as http://203.0.113.10). In the real world, however, users do not memorize IP addresses—they navigate using domain names and expect an encrypted, green padlock connection. In this lesson, we will master:

  • Domain name anatomy (TLD, SLD, Subdomain) & relationship to IP addresses
  • Domain Registrar vs. DNS Provider (Cloudflare, AWS Route 53)
  • How DNS recursive resolution operates (Root, TLD, Authoritative nameservers)
  • Essential DNS record types: A, AAAA, CNAME, MX, TXT & TTL caching mechanics
  • HTTP vs. HTTPS: Plaintext security vulnerabilities & TLS 1.3 handshake mechanics
  • Digital certificates, CAs, and automated SSL issuance with Let's Encrypt Certbot
  • Forward Proxy vs. Reverse Proxy & multi-application routing with Nginx
  • A complete, 6-step real-world deployment architecture and end-to-end request lifecycle
Domain Foundations

What is a Domain Name? The Human Identity of the Internet

Imagine you have built a powerful web application and deployed it to a cloud server. The server has a public IP address, such as 203.0.113.10. You can access the site from anywhere on the internet by typing that IP into your browser. But if your users had to memorize 203.0.113.10 or an IPv6 address like 2001:db8::1 every time they wanted to read an article or buy a product, the web would be unusable.

In simple terms, a Domain Name is a human-friendly alphanumeric identifier used to reference websites and servers across the internet (e.g., byteion.com or example.com).

Fundamental Reality: A domain name does not store any files, databases, or application code on its own. A domain is simply a pointer. To serve an application to users, you must always have an underlying physical or virtual server.

The Anatomy of a Domain Name

A Fully Qualified Domain Name (FQDN) is structured hierarchically from right to left:

www . example . com (. root)
Subdomain (www, api, app)

Identifies a specific section or microservice under the main domain, such as api.example.com.

Second-Level Domain (SLD)

The unique brand or organizational name you register (such as example or byteion).

Top-Level Domain (TLD)

The ending registry extension (such as .com, .org, .edu, .io, or ccTLD .bd).

Relationships & Roles

Domain Name vs. IP Address & Registrar vs. DNS Provider

Internet routing is fundamentally governed by IP addresses. Routers do not recognize domain strings; they route packets strictly according to IP destinations.

Domain Name (For Humans)

A memorable, logical label. It provides an abstraction layer over mutable server IPs. When you migrate servers or change cloud providers, your domain remains identical to users.

IP Address (For Machines)

The precise numerical locator of a network interface. IPv4 uses 32-bit dotted-decimal addresses (e.g., 203.0.113.10), and IPv6 uses 128-bit hexadecimal addresses (e.g., 2001:db8::1).

Are Domain Registrars and DNS Providers the Same?

These two roles are frequently confused by newcomers:

  • Domain Registrar (The Seller): An accredited organization (e.g., Namecheap, GoDaddy, Porkbun) where you purchase and reserve legal domain ownership for an annual renewal fee.
  • DNS Provider (The Address Book Host): A global edge network (e.g., Cloudflare, AWS Route 53) that hosts your authoritative DNS zone records and answers queries from worldwide resolvers in single-digit milliseconds.

You can buy a domain from Namecheap, but point its Nameserver (NS) records to Cloudflare or Route 53. This separates billing ownership from high-performance global DNS resolution and DDoS protection.

The Global Phonebook

What is DNS and How Does Recursive Resolution Work?

The Domain Name System (DNS) is a globally distributed, hierarchical database that translates human-friendly domain names into machine-routable IP addresses.

When you open a browser and type www.example.com, an orchestrated query chain executes behind the scenes in tens of milliseconds:

1

Browser & OS DNS Cache Lookup

The browser first checks its internal cache and the operating system resolver cache (e.g., systemd-resolved on Linux or DNS Client Cache on Windows). If a valid record exists within its Time-to-Live (TTL), it connects directly without internet queries.

2

Query Sent to Recursive DNS Resolver

If uncached, your operating system asks a Recursive DNS Resolver—provided either by your ISP or a public resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8). The resolver takes responsibility for finding the answer across the hierarchy.

3

Querying the Root DNS Servers (.)

The resolver queries one of the 13 global root server clusters (a.root-servers.net through m.root-servers.net). The root server does not know the final IP, but directs the resolver to the responsible Top-Level Domain (TLD) server for .com.

4

Querying the TLD Nameserver (.com)

The resolver queries the .com registry nameserver (managed by Verisign). The TLD server responds with the Authoritative Nameservers assigned to example.com (e.g., ns1.cloudflare.com).

5

Querying the Authoritative Nameserver

The resolver queries ns1.cloudflare.com, which holds the official zone file for the domain. It answers definitively: "The A record for example.com is 203.0.113.10 with a TTL of 300 seconds."

6

Resolver Caches IP and Delivers to Browser

The resolver caches the IP address locally to serve future users instantly and returns the IP to your browser. The browser initiates a direct TCP connection to 203.0.113.10.

Zone Configuration

Essential DNS Record Types Explained

A DNS zone file contains specific instructions called DNS Records. Each record type fulfills a distinct operational objective:

Record Type Name / Host Value / Target Purpose & Real-World Use
A @ (Root Apex) 203.0.113.10 Maps a hostname to an IPv4 address.
AAAA @ 2001:db8::1 Maps a hostname to an IPv6 address.
CNAME www example.com. Canonical name alias. Points a subdomain to another domain name.
MX @ 10 mail.example.com. Mail exchange. Directs incoming emails to mail servers with priority weights.
TXT @ "v=spf1 include:_spf.google.com ~all" Plaintext metadata used for ownership verification & anti-spoofing (SPF, DKIM, DMARC).
Apex CNAME Restriction and CNAME Flattening:

According to classic DNS RFC 1034 rules, a CNAME record cannot exist at the root zone apex (example.com) alongside SOA and NS records. However, modern providers like Cloudflare and Route 53 offer CNAME Flattening (or Alias records). They dynamically resolve the alias in the background and return synthesized A records directly to clients, bypassing this historical limitation.

Caching & Propagation

What is TTL and Why Does DNS Propagation Take Time?

When you update an A record with a new server IP, some users will still be directed to your old server for a period of time. This phenomenon is commonly called DNS Propagation Delay.

In reality, DNS records are not pushed across all global servers simultaneously. Propagation delay is governed by TTL (Time to Live).

Time to Live (TTL): A numerical duration in seconds specifying how long resolvers may cache a DNS record. For example, if a record has a TTL of 86400 (24 hours), recursive resolvers around the world will not re-query your nameserver for 24 hours. They will continue serving the old IP until that timer expires.
Golden Rule for Zero-Downtime Server Migrations:

At least 48 hours prior to a major server migration, lower your DNS TTL to 300 seconds (5 minutes) or 60 seconds. When you cut over to the new cloud IP on migration day, resolvers will flush their caches within minutes, ensuring seamless global traffic switching. Once stability is verified, restore the TTL to 86400 to minimize DNS query load.

Verify your DNS propagation and live records directly from your command line using dig:

# Inspect short IPv4 resolution
dig example.com A +short

# Query a specific public resolver directly (e.g., Cloudflare 1.1.1.1)
dig @1.1.1.1 example.com A

# Verify www subdomain alias
dig www.example.com CNAME +short
Protocol Security

HTTP vs. HTTPS: The Critical Dangers of Plaintext

HTTP (Hypertext Transfer Protocol) defines how clients and servers exchange messages. A browser sends a plaintext request (e.g., GET /products HTTP/1.1), and the server returns a plaintext response with headers and HTML (e.g., HTTP/1.1 200 OK).

The fatal vulnerability of standard HTTP is that it is completely unencrypted. Anyone situated between the client and server—such as a rogue Wi-Fi access point, an eavesdropping ISP, or an attacker on public networks—can intercept passwords, session cookies, and credit cards in clear text (Man-in-the-Middle Attack).

1. Encryption (Privacy)

All data traveling between client and server is encrypted into cryptographically secure ciphertext. Eavesdroppers intercept only undecipherable random bytes.

2. Integrity (Anti-Tamper)

Data cannot be modified or injected in transit (such as rogue ads or malware). Cryptographic checksums ensure packets are rejected if altered by a single bit.

3. Authentication (Identity)

Digital certificates issued by trusted CAs prove to the browser that it is truly communicating with example.com, eliminating spoofing and phishing clones.

Modern Cryptography

How TLS Works: The Modern 1-RTT TLS 1.3 Handshake

HTTPS is powered by TLS (Transport Layer Security). While historically referred to as SSL, SSL has been obsolete since 1999. Today, TLS 1.3 represents the gold standard for performance and security.

Before application data is transmitted, the client and server execute a rapid cryptographic negotiation known as the TLS Handshake:

Client (Browser) 1-RTT TLS 1.3 Handshake Server (Nginx)
[Client Hello + Key Share] ───────────────────────► Cipher Suites, Elliptic Curve Key Share
◄─────────────────────── [Server Hello + Cert + Key] Server Key Share, Digital Certificate
Both parties independently derive the shared Symmetric Session Key (AES-256-GCM)
[Encrypted HTTP GET /products] ══════════════════════► Full application data encrypted
◄══════════════════════ [Encrypted HTTP 200 OK + HTML] Green padlock browsing live
Symmetric vs. Asymmetric Cryptography:

Asymmetric cryptography (Public/Private key pairs) is computationally intensive and is used only during the initial handshake to authenticate identity and establish a shared secret. Once established, all high-throughput HTTP payload data is encrypted using high-speed Symmetric Cryptography (AES-GCM or ChaCha20-Poly1305), utilizing dedicated CPU hardware instructions with virtually zero server latency.

Automated Certificates

Let’s Encrypt & Certbot: Free, Automated SSL for Everyone

In the early web, obtaining an SSL certificate required hundreds of dollars annually and painstaking manual CSR generation. Let's Encrypt transformed the entire internet landscape.

Let's Encrypt is a free, automated, and open Certificate Authority (CA) operated by the Internet Security Research Group (ISRG). Using the ACME protocol, it issues Domain-Validated (DV) certificates automatically. Certbot is the official command-line utility used to manage these certificates.

Provisioning HTTPS on Ubuntu with Certbot

1. Install Certbot and the Nginx plugin:
sudo apt update
sudo apt install certbot python3-certbot-nginx -y
2. Issue certificate & auto-configure Nginx:
sudo certbot --nginx -d example.com -d www.example.com

Certbot initiates an ACME HTTP-01 challenge over port 80 to verify domain control, downloads the certificates to /etc/letsencrypt/live/example.com/, and configures SSL directives directly in Nginx.

3. Test automated certificate renewal (Dry-Run):
sudo certbot renew --dry-run

Let's Encrypt certificates are valid for 90 days. Certbot configures a background systemd timer that automatically renews the certificate 30 days prior to expiration without requiring manual intervention.

Comparative Breakdown

Comprehensive HTTP vs. HTTPS Comparison

Feature HTTP (Insecure) HTTPS (Secure)
Full Name Hypertext Transfer Protocol Hypertext Transfer Protocol Secure
Encryption Level Plaintext (None) TLS 1.3 End-to-End Encrypted
Default Port Port 80 Port 443
Data Integrity Subject to tampering & rogue ad injection Cryptographically verified via HMAC / AEAD
Server Authentication None (Susceptible to phishing clones) Verified by trusted Root Certificate Authorities
Browser Indicators & SEO Chrome displays "Not Secure" warning Secure lock icon, prioritized Google search ranking
Proxy Architecture

Forward Proxy vs. Reverse Proxy: Core Distinctions

In networking, a "Proxy" acts on behalf of another entity. Whether a proxy is Forward or Reverse depends entirely on which side of the connection it represents:

Forward Proxy (Represents the Client)

Sits in front of client devices to handle outbound requests to the internet. Examples include corporate egress filters enforcing security policies, or personal VPNs masking real client IP addresses.

Clients → [ Forward Proxy ] → Public Internet
Reverse Proxy (Represents the Server)

Sits at the edge of your cloud infrastructure to intercept inbound requests from the internet and route them to private backend servers or Docker containers. The public never sees backend ports or internal IPs.

Public Internet → [ Reverse Proxy (Nginx) ] → Private Containers
Dimension Forward Proxy Reverse Proxy
Who does it act for? On behalf of clients (users) On behalf of web servers / backends
Architectural Position Between client devices and the internet Between the internet and backend application clusters
What does it conceal? Hides the client's actual IP address Hides the backend servers' internal topology & ports
Primary Functions Content filtering, anonymization, egress caching SSL termination, host-based routing, load balancing
Standard Technologies Squid Proxy, Zscaler, Tor Gateway Nginx, Traefik, HAProxy, Envoy, Cloudflare Edge
Infrastructure Pillar

Why Every Production Environment Demands a Reverse Proxy

In professional cloud environments, application runtimes (such as Node.js Express, Python Gunicorn, or Laravel Octane) are never directly exposed to the public internet. Here are the five reasons why a reverse proxy is indispensable:

1. Hosting Multiple Applications on a Single IP (Virtual Hosting)

Your cloud VM possesses only one public IP address and one set of ports (80/443). Yet you may run three distinct services: a web frontend (port 8080), an API service (port 3000), and an admin portal (port 4000). The reverse proxy examines incoming Host headers and routes each request to its corresponding container.

2. SSL/TLS Termination

The reverse proxy handles all heavy cryptographic handshakes and decryption at the perimeter. Backend application containers communicate over lightweight, unencrypted local connections, freeing application CPUs to focus purely on business logic.

3. Backend Shielding & Port Isolation

Your Docker containers bind only to 127.0.0.1:8080 or an isolated Docker bridge network. External port scanners and attackers cannot touch application runtimes or databases directly.

4. Load Balancing & Failover Resilience

If you run multiple container replicas of the same application, the reverse proxy distributes incoming requests across healthy backends and automatically diverts traffic if one container crashes.

5. Centralized Security Headers & Compression

You can inject critical security headers (HSTS, CSP, X-Frame-Options), configure client IP forwarding (X-Forwarded-For), and enable Gzip/Brotli compression from a single unified configuration file.

Configuration Anatomy

Configuring Nginx as a Production Reverse Proxy

On Ubuntu, Nginx server blocks are defined in /etc/nginx/sites-available/. Below is a production-grade reverse proxy configuration with line-by-line annotations:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    # Forward all traffic to the local Docker container
    location / {
        proxy_pass http://127.0.0.1:8080;

        # Preserve the original Host requested by the client
        proxy_set_header Host $host;

        # Pass the real client IP to the backend application
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Notify backend whether the client used HTTP or HTTPS
        proxy_set_header X-Forwarded-Proto $scheme;

        # Enable WebSocket upgrades if required
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
proxy_pass Defines the target address and internal port where the reverse proxy forwards the request (e.g., http://127.0.0.1:8080).
proxy_set_header X-Real-IP Because Nginx initiates the connection to the container, the container would otherwise see 127.0.0.1. This header preserves the real visitor IP for logging and security.
Hands-on Implementation

Real-World Implementation: 6 Steps from Domain to HTTPS

Let's integrate our Dockerized application from Lesson 08 into a complete, hardened production architecture across 6 clear steps:

Step 1 DNS Dashboard

Configure Domain DNS Records

In your DNS control panel (Cloudflare or Namecheap), configure an A record pointing your root domain to your Cloud VM's public IP (203.0.113.10), and add a CNAME record for www:

Type: A      | Name: @   | Value: 203.0.113.10 | TTL: 300
Type: CNAME  | Name: www | Value: example.com  | TTL: 300
Step 2 Docker Run

Bind Container to Loopback Interface (Private Port)

Unlike Lesson 08 where we published directly to 0.0.0.0:80, we now bind strictly to 127.0.0.1:8080:80, isolating the container from the public internet:

sudo docker run -d   --name my-website   --restart unless-stopped   -p 127.0.0.1:8080:80   byteion/my-website:1.0
Step 3 Host Ubuntu VM

Install and Enable Nginx on the Host

sudo apt update && sudo apt install nginx -y
sudo systemctl enable --now nginx
Step 4 Nginx VirtualHost

Configure and Enable Nginx Reverse Proxy

# 1. Create server configuration
sudo nano /etc/nginx/sites-available/example.com

# 2. Enable site via symbolic link
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# 3. Test configuration syntax and reload service
sudo nginx -t && sudo systemctl reload nginx
Step 5 SSL Automation

Provision Free Let's Encrypt HTTPS via Certbot

sudo certbot --nginx -d example.com -d www.example.com
Step 6 301 Redirect

Enforce Permanent HTTP to HTTPS Redirection

Certbot automatically inserts a return 301 https://$host$request_uri; directive in the port 80 block. Any incoming plaintext HTTP connection is immediately redirected to secure port 443.

The Unified Journey

The Complete End-to-End Request Lifecycle

When a user visits https://example.com/products, every component coordinates seamlessly in milliseconds to serve the page:

1. DNS Browser queries DNS hierarchy and resolves example.com to IP 203.0.113.10.
↓
2. TLS 1.3 Handshake completes on port 443, certificate validates, and an encrypted tunnel is established.
↓
3. Nginx Reverse Proxy Nginx decrypts TLS, inspects the Host header, and proxies to http://127.0.0.1:8080/products.
↓
4. Docker Container Application processes request, queries database, and generates HTML/JSON payload.
↓
5. Encrypted Delivery Nginx re-encrypts the response and sends it back to the client. Green padlock rendered in browser!
Clarifying Terminology

Is a Reverse Proxy an Alternative to a Load Balancer?

Short answer: They are not rivals; they are complementary partners!

A reverse proxy stands at the ingress of a server to provide routing, SSL termination, and caching. However, modern reverse proxies like Nginx and HAProxy also provide Layer 7 (HTTP) load balancing.

The Two-Tier Enterprise Topology:

In large enterprise systems, an external cloud Load Balancer (such as an AWS ALB or Cloudflare Load Balancer) receives incoming global traffic and distributes it across dozens of Cloud VMs. Inside each VM, a local Nginx reverse proxy routes traffic to localized Docker container instances.

Interactive Simulator

Cloud Gateway & Web Infrastructure Lab

Test recursive DNS lookups, TLS 1.3 cryptographic handshakes, Nginx multi-app routing, and Certbot automation interactively:

Recursive DNS Lookup & TTL Cache Tracker

Select a domain and trace the step-by-step resolution journey:

Resolution Progress Step 1/6 (0%)
Active Cache TTL Countdown:
300s (5m 00s)

Queries during this window will be served directly from resolver cache.

Resolved Canonical IP:
Searching...

IPv4 target host: 203.0.113.10

Key Takeaways & What's Next

What We Mastered in This Lesson

  • Domain & IP Synergy: Domains provide mutable human-friendly names that map to cloud IP addresses via DNS.
  • Recursive DNS Hierarchy: Resolution moves through Browser Cache → Resolver → Root (.) → TLD (.com) → Authoritative Nameserver.
  • DNS Record Types: A (IPv4), AAAA (IPv6), CNAME (Canonical Alias), MX (Mail Exchange), and TXT (Verification/SPF).
  • TTL Migration Strategy: Dropping TTL to 300s prior to cloud cutover eliminates downtime and resolves propagation lag.
  • HTTPS & TLS 1.3: 1-RTT cryptographic negotiation, symmetric AES-GCM data encryption, and trusted CA verification.
  • Certbot Automation: Automated Let's Encrypt certificate generation and background systemd timers for hands-free renewals.
  • Nginx Reverse Proxy: Virtual hosting on a single public IP, SSL termination, and private container port isolation.
  • HTTP 301 Permanent Redirect: Automatically upgrading legacy port 80 traffic to hardened HTTPS port 443 connections.
Preparing for the Next Challenge

Lesson 12.10 — CI/CD & Automated Deployment

We now have a complete, production-ready web infrastructure combining Linux VMs, Docker containers, domain routing, SSL certificates, and an Nginx reverse proxy. But should engineers manually SSH into servers to run docker pull every time code changes? Absolutely not! In the next lesson, we explore Git, Continuous Integration (CI), Continuous Delivery (CD), and automated deployment pipelines that test, build, and deploy our application the moment code is pushed to production!

References & Supplemental Resources:
  • ICANN Official: The Domain Name System (DNS) Architecture
  • AWS Documentation: Amazon Route 53 DNS Record Types & Routing Policies
  • Mozilla Developer Network (MDN): Transport Layer Security (TLS)
  • Let's Encrypt: How Automated Certificate Management (ACME) Works
  • NGINX Official Docs: Reverse Proxy Guide & HTTP Load Balancing
  • Electronic Frontier Foundation (EFF): Certbot Command Reference