DNS Configuration and TLS with Let's Encrypt

What DNS Does and Why It Matters

Every website you visit has a numeric IP address—for example, `203.0.113.45`. Humans remember names, not numbers, so the Domain Name System (DNS) acts as a phone book that translates a hostname like `example.com` into the IP address your browser needs. When you own a domain name, you control that translation by editing records stored at a DNS registrar or a separate DNS hosting provider.

For your VPS-hosted site to be reachable by name, you must create an A record that maps your hostname to your server's public IPv4 address. Until that record exists and propagates across the internet, your domain points nowhere useful.

Types of DNS Records You Will Use

• A record — Maps a hostname to an IPv4 address. Example: `www` → `203.0.113.45`. This is the record you create in this lab.
• AAAA record — Same idea, but for IPv6 addresses.
• CNAME record — Maps one hostname to another hostname (an alias). Not used here, but common for subdomains.
• TTL (Time to Live) — The number of seconds resolvers should cache the record. Lower values (300–600 seconds) let changes propagate faster during setup.

Creating an A Record

Log in to your registrar's DNS management panel. Locate the option to add a DNS record, then fill in:

| Field | Value |

|-------|-------|

| Type | A |

| Host / Name | `@` (for the root domain) or `www` |

| Value / Points to | Your VPS public IP address |

| TTL | 300 (five minutes, for testing) |

Save the record. DNS changes do not take effect instantly; propagation across the public internet can take a few minutes up to 48 hours, though 5–15 minutes is typical with a low TTL.

Verifying Propagation

Use the `dig` command-line tool to query DNS from your terminal:

```

dig A www.yourdomain.com +short

```

When the output shows your VPS IP address, propagation has reached the DNS resolver your machine is using. You can also use `nslookup`:

```

nslookup www.yourdomain.com

```

Do not proceed to the TLS step until DNS resolves correctly. Certbot contacts Let's Encrypt servers, which then reach back to your domain over HTTP to verify ownership. If DNS is not propagated, the verification will fail.

Why TLS and HTTPS Are Required

HTTP transmits data in plain text. Anyone on the same network can read or modify it. TLS (Transport Layer Security) encrypts the connection between browser and server. HTTPS is HTTP carried over a TLS connection. Modern browsers mark non-HTTPS sites as "Not Secure" and many features (geolocation, service workers, certain APIs) require a secure context. Employers expect all production sites to use HTTPS.

A TLS certificate proves that the entity presenting it legitimately controls the domain. Certificates are issued by a Certificate Authority (CA) that browsers trust. Let's Encrypt is a free, automated, open CA operated by the non-profit Internet Security Research Group. It issues 90-day certificates at no cost.

Installing Certbot and Obtaining a Certificate

Certbot is the official Let's Encrypt client tool, maintained by the Electronic Frontier Foundation. On Ubuntu/Debian with Nginx already installed:

```bash

sudo apt update

sudo apt install certbot python3-certbot-nginx -y

```

Then run the Nginx plugin to obtain and install the certificate automatically:

```bash

sudo certbot --nginx -d www.yourdomain.com

```

Certbot will:

1. Verify you control the domain using the HTTP-01 challenge (places a temporary file in your web root and asks Let's Encrypt to fetch it).

2. Download the certificate and private key.

3. Rewrite your Nginx server block to listen on port 443 with TLS and add a redirect from HTTP (port 80) to HTTPS.

Follow the prompts: enter your email address (used for renewal notices) and agree to the terms of service.

Confirming the Certificate in a Browser

Navigate to `https://www.yourdomain.com`. Click the padlock icon in the address bar and inspect the certificate. You should see:

• Issuer: Let's Encrypt (specifically one of their intermediate CAs, such as R10 or R11)
• Validity period: 90 days from issuance
• Subject: your domain name

The browser should show no mixed-content warnings. Mixed content means an HTTPS page is loading resources (images, scripts, stylesheets) over plain HTTP; this breaks security and is flagged by browsers.

Automatic Renewal

Let's Encrypt certificates expire after 90 days. Certbot installs a systemd timer or cron job that attempts renewal automatically when fewer than 30 days remain. Verify the timer is active:

```bash

systemctl status certbot.timer

```

You can do a dry run to confirm renewal would succeed:

```bash

sudo certbot renew --dry-run

```

Safety and Professional Practices

• Protect your private key. The private key file (stored under `/etc/letsencrypt/`) must not be shared or committed to version control. Treat it like a password.
• Keep firewall rules correct. Port 443 (HTTPS) and port 80 (HTTP, needed for renewal challenges) must be open in your VPS firewall (e.g., `ufw allow 'Nginx Full'`).
• Use a low TTL during setup. Raise it back to 3600 or higher after DNS is confirmed stable to reduce lookup load.
• Do not store credentials in your lab log. Record hostnames, certificate details, and commands—not passwords or private keys.