← Back to all topics
$ dig +short banoqabil.pk

DNS, CDN & HTTPS
Instructor Guide

From "I bought a domain" to "https://yourname.com is fast everywhere" — the network plumbing every DevOps engineer must understand.

01
How DNS Works — From "Click" to "200 OK" in 80 Milliseconds
Resolver → root → TLD → authoritative — the journey every URL takes before a single byte of HTML moves
▾

How to explain to students

When you type https://banoqabil.pk in a browser, your computer doesn't know where that is. DNS (Domain Name System) is the phone book that translates a name into an IP address. The lookup hops through 4 levels — your resolver, the root, the TLD (.pk), and finally an authoritative server — but is heavily cached so most queries return in milliseconds.

DevOps engineers don't usually run their own DNS — they configure records at a managed provider (Route 53, Cloudflare, Google Cloud DNS). The skill is reading dig output and knowing which record type does what.

dig +trace — see the journey
# Trace the lookup, hop by hop
$ dig +trace banoqabil.pk
. 86400 IN NS a.root-servers.net. ← root nameservers
. 86400 IN NS b.root-servers.net.
pk. 172800 IN NS ns1.pk.  ← root tells us where .pk lives
banoqabil.pk. 3600 IN NS ns1.banoqabil.pk.  ← TLD points to the domain's NS
banoqabil.pk. 300 IN A 192.0.2.42  ← authoritative answer

# Quick lookup (cached, sub-second)
$ dig +short banoqabil.pk
192.0.2.42

# Reverse — IP to name (PTR record)
$ dig -x 8.8.8.8 +short
dns.google.

# Use a specific resolver (skips your local cache)
$ dig @1.1.1.1 banoqabil.pk
🌐
4-level hierarchy
Resolver → root → TLD → authoritative. Each step is cached.
⚡
Massively cached
95% of lookups never leave your ISP. TTL controls cache lifetime.
🔧
dig is your friend
dig name, dig -x IP, dig +trace, dig @resolver.
🌍
UDP port 53
Most queries are UDP for speed. Falls back to TCP for large responses + DNSSEC.

🎯 Practice Questions

Q1.
In one sentence per role, explain: resolver, root server, TLD server, authoritative server. Which one returns the actual IP?
Show Answer
Resolver — the recursive lookup service your machine talks to (e.g. 1.1.1.1, 8.8.8.8, your ISP). It does the full hop chain on your behalf and caches results.
Root server — knows which nameservers handle each TLD (.pk, .com, .io). 13 logical root servers globally.
TLD server — for a TLD like .pk, knows which nameservers run each domain under it.
Authoritative server — the actual owner of banoqabil.pk's records. This one returns the IP. It's the source of truth; everyone else is caching.
Q2.
A site you just changed the IP for is still showing the old IP for some users. What is "TTL" and how does it explain this?
💡 TTL = how long resolvers may cache a record.
Q3.
Use dig to find: (a) the NS records for github.com, (b) the IPv6 (AAAA) record for cloudflare.com, (c) the MX record for gmail.com. Write the three commands.
02
Choosing & Managing a Domain in Route 53
Where your DNS lives matters — registrar, hosted zone, and the difference between them
▾

How to explain to students

Two separate things often confused: domain registrar (where you buy the domain — Namecheap, Google Domains, Route 53) and DNS hosting (where the records actually live — Route 53, Cloudflare, the registrar). You can buy a domain at Namecheap and host the DNS at Route 53 — common pattern.

In Route 53, a hosted zone is a container for all records for one domain. AWS gives you 4 nameservers — you tell your registrar to use those, and Route 53 becomes authoritative. After that, you can connect any AWS service (S3, CloudFront, Beanstalk, ALB) to a custom domain.

route53 — hosted zone setup
# 1. Create a hosted zone for your domain
$ aws route53 create-hosted-zone \
  --name muzammilbilwani.com \
  --caller-reference $(date +%s)
"Id": "/hostedzone/Z1A2B3C4",
"DelegationSet": { "NameServers": [
"ns-123.awsdns-12.com",
"ns-456.awsdns-34.net",
"ns-789.awsdns-56.org",
"ns-012.awsdns-78.co.uk"
]}

# 2. At your REGISTRAR (Namecheap, GoDaddy, etc.):
# Set the nameservers to those 4 AWS NS values.
# Propagation: 2–48 hours, usually under 1 hour.

# 3. Verify the delegation worked
$ dig NS muzammilbilwani.com +short
ns-123.awsdns-12.com.
ns-456.awsdns-34.net.
ns-789.awsdns-56.org.
ns-012.awsdns-78.co.uk.  # ✓ Route 53 is authoritative

# 4. List records in the zone
$ aws route53 list-resource-record-sets --hosted-zone-id Z1A2B3C4
hosted zone delegation registrar NS records SOA

🎯 Practice Questions

Q1.
Explain in one sentence each: domain registrar, DNS hosting, hosted zone. Where do all three meet?
Q2.
You bought example.com at Namecheap and want DNS in Route 53. What exactly do you change at Namecheap, and why is the change required?
Show Answer
At Namecheap → set the nameservers to the 4 NS records Route 53 gave you when you created the hosted zone (e.g. ns-123.awsdns-12.com, etc.).

Why: the global DNS hierarchy needs to know who is authoritative for your domain. Until you change the NS at the registrar, the .com TLD points to Namecheap's nameservers, so any record you create in Route 53 is invisible to the world. After the change (which propagates in 1–48 hours), the .com TLD points queries to Route 53.
Q3.
A teammate says "Route 53 is expensive — let's use the free DNS at our registrar." What's a real reason you might still pay $0.50/month for Route 53?
💡 Alias records, health checks, geolocation routing.
03
DNS Record Types — A, AAAA, CNAME, MX, TXT, NS
The seven record types that solve 95% of real DNS problems
▾

How to explain to students

Each record type answers one question. Memorise the cheat sheet, and 95% of "why isn't email working" / "why does my site not load" is solvable in 5 minutes.

record-types.txt
A → name → IPv4 address
example.com A 192.0.2.42

AAAA → name → IPv6 address
example.com AAAA 2606:4700:4700::1111

CNAME → name → another name (alias)
www.example.com CNAME example.com
⚠️ Cannot exist on the apex (example.com itself)

MX → mail server for the domain
example.com MX 10 aspmx.l.google.com

TXT → arbitrary text — verification, SPF, DMARC, DKIM
example.com TXT "v=spf1 include:_spf.google.com ~all"

NS → which nameservers are authoritative
example.com NS ns-123.awsdns-12.com

SOA → zone metadata (auto-generated, rarely touched)

ALIAS → AWS-only "fake CNAME" that works on apex (Route 53 magic)
example.com A (alias) → d1234.cloudfront.net

# A real workflow — verify Google Workspace email
$ dig MX example.com +short
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.

$ dig TXT example.com +short
"v=spf1 include:_spf.google.com ~all"
"google-site-verification=abcd1234..."
🅰️
A vs CNAME
A = direct IP. CNAME = points to another name. CNAME never on apex.
📧
MX with priority
Lower number = higher priority. Multiple MX = email failover.
📜
TXT for verification
Google, AWS, Slack all use TXT to prove you own the domain.
🪄
Route 53 ALIAS
Apex pointing at CloudFront / ALB / S3 — only works in Route 53.

🎯 Practice Questions

Q1.
Pick the right record for: (a) blog.example.com → example.com, (b) Gmail incoming mail, (c) Google Site verification, (d) example.com → CloudFront URL.
Show Answer
(a) CNAME — alias one name to another, perfect for subdomains.
(b) MX — points to aspmx.l.google.com with priority 1, plus alternates.
(c) TXT — Google's verification string lives in a TXT record on the apex.
(d) ALIAS A — apex (example.com) cannot use CNAME. Route 53's ALIAS A record solves this — DNS resolvers see an A record, but it's resolved dynamically against CloudFront. Outside Route 53, the alternative is "ANAME" or flattened-CNAME from Cloudflare.
Q2.
A teammate sets example.com CNAME www.example.com. Why is this invalid?
Q3.
Set up SPF, DKIM, and DMARC for a domain sending email via Google Workspace. Which record type for each, and what's the goal of each?
💡 SPF and DMARC are TXT. DKIM is also TXT but on a selector subdomain.
Q4.
A subdomain returns NXDOMAIN in dig. List three places to check before assuming the record is missing.
04
Connecting Custom Domains to AWS Services
S3, CloudFront, Beanstalk, ALB, API Gateway — each has a slightly different "alias" story
▾

How to explain to students

Every AWS service that serves traffic gets a default ugly URL (d1234.cloudfront.net, app-prod.eu-west-1.elasticbeanstalk.com). Pointing a custom domain at it is two steps: (1) get a TLS cert that covers your domain, (2) create an ALIAS A record in Route 53 pointing at the AWS service's hosted-zone target.

custom-domain — alias targets
# CloudFront → muzammilbilwani.com
muzammilbilwani.com A (alias) d1234.cloudfront.net.
hosted zone: Z2FDTNDATAQYW2 (CloudFront)

# S3 static-website endpoint (no CloudFront — rare)
www.example.com A (alias) s3-website-eu-west-1.amazonaws.com.

# Elastic Beanstalk → api.example.com
api.example.com A (alias) myapp-prod.eu-west-1.elasticbeanstalk.com.

# ALB / NLB
app.example.com A (alias) my-alb-123.eu-west-1.elb.amazonaws.com.

# API Gateway custom domain
api.example.com A (alias) d-abc123.execute-api.eu-west-1.amazonaws.com.

# Create the alias record via CLI
$ aws route53 change-resource-record-sets \
  --hosted-zone-id Z1A2B3C4 \
  --change-batch '{ "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "muzammilbilwani.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z2FDTNDATAQYW2",
        "DNSName": "d1234.cloudfront.net",
        "EvaluateTargetHealth": false
      }}}]}'

🎯 Practice Questions

Q1.
Why is "ALIAS A" preferred over a regular A record (with hard-coded IP) for AWS service endpoints?
Show Answer
AWS service endpoints (CloudFront, ALB, Beanstalk) sit behind changing IP addresses — AWS rotates them, scales them up/down, and takes individual IPs out of rotation for health reasons. Hard-coding an IP into an A record means your domain breaks every time AWS rotates.

ALIAS A is Route 53's solution: looks like an A record to the world, but Route 53 dynamically resolves it to AWS's current IPs. Bonus: ALIAS records are free to query (unlike CNAME) and work on the apex.
Q2.
You point api.example.com at an ALB. dig resolves correctly but curl returns "SSL: certificate verification failed". What's the most likely cause?
💡 The ALB has its own cert — does it cover this hostname?
Q3.
Compare: pointing at CloudFront via ALIAS A vs CNAME. Which is faster for resolvers, and why?
05
CDNs — CloudFront, Cloudflare, and Why They Make Sites 10× Faster
Edge caching turns "100ms from the origin" into "10ms from a server 50km away"
▾

How to explain to students

A CDN (Content Delivery Network) caches your content at hundreds of edge locations around the world. When a user in Karachi requests style.css, the closest edge serves it from cache — never touching your origin S3 bucket in Frankfurt. Result: 10–50× faster page loads, lower bandwidth bills, DDoS protection.

CloudFront and Cloudflare are the two giants. CloudFront integrates tightly with AWS (S3, ALB, Lambda@Edge). Cloudflare is registrar-agnostic, free tier is generous, and it adds DDoS + WAF in front of any backend. For BanoQabil-region students, both have edges in Karachi, Lahore, and Mumbai.

cdn — concept + headers
# Without CDN: every request hits the origin in eu-west-1
Karachi user → 250ms RTT → Frankfurt origin → render
First byte: ~280ms · 2.4 MB total: ~3.5s

# With CDN: 99% hits the local edge
Karachi user → 8ms RTT → Mumbai edge (cached) → response
First byte: ~12ms · 2.4 MB total: ~700ms  5× faster

# Inspect cache status via response headers
$ curl -sI https://muzammilbilwani.com/styles.css | grep -i cache
cache-control: public, max-age=31536000, immutable
x-cache: Hit from cloudfront
age: 86412  # in cache for ~1 day

# vs a miss
x-cache: Miss from cloudfront

# Force-bypass cache (test origin)
$ curl -sI -H "Cache-Control: no-cache" https://muzammilbilwani.com
⚡
Edge caching
99% of static assets served from a server < 50km away.
🛡️
DDoS shield
Edge absorbs floods. Origin never sees the abuse traffic.
💰
Cheaper egress
CDN bandwidth is much cheaper than origin egress (S3 → internet).
🔄
Cache invalidation
After deploy, invalidate /index.html only — not /*.

🎯 Practice Questions

Q1.
Your portfolio loads in 3.2s without CDN, 0.7s with CloudFront. Sketch where the extra 2.5s went.
Q2.
Which response header tells you whether a CDN served the request from cache or fetched from origin?
Q3.
A user reports "I changed a typo in index.html and pushed but the site still shows the old version 5 minutes later." Three places where stale content might live.
Show Answer
1. CloudFront edge cache. The CDN is doing its job — caching the old index.html for whatever Cache-Control: max-age said. Fix: aws cloudfront create-invalidation --paths /index.html.
2. Browser cache. Even after CDN purge, the user's browser may have cached index.html locally. Test in incognito or hard-refresh (Cmd+Shift+R).
3. S3 itself hasn't propagated, or you forgot to aws s3 sync. Always verify aws s3 ls + check the actual object's LastModified.

Pro tip: set short cache (60s) on index.html and long cache (1y, immutable) on hashed assets like main.abc123.js. Best of both worlds.
Q4.
Compare CloudFront and Cloudflare in 3 axes: cost, ease of setup, integration with AWS. Which would you pick for a static portfolio?
06
SSL/TLS — HTTPS, Certificates, ACM, Let's Encrypt
The padlock icon, but really. How TLS handshakes work and why your cert can be free.
▾

How to explain to students

HTTPS is just HTTP wrapped in TLS. When a browser connects to https://example.com, the server sends a certificate proving "I am example.com" — signed by a Certificate Authority the browser trusts. They negotiate a session key and encrypt all traffic.

In 2026, certificates are free and automated. AWS users get ACM (free, auto-renews, integrates with CloudFront/ALB/API Gateway). Everyone else uses Let's Encrypt via Certbot — free, 90-day certs, auto-renewal. There is essentially no reason to pay for a regular DV certificate today.

tls — issue + verify
# OPTION A: AWS — ACM (free, auto-renew)
$ aws acm request-certificate \
  --domain-name muzammilbilwani.com \
  --subject-alternative-names www.muzammilbilwani.com \
  --validation-method DNS \
  --region us-east-1  # MUST be us-east-1 for CloudFront
# Add the validation CNAME to Route 53 → cert is issued in ~1 minute

# OPTION B: Anywhere else — Let's Encrypt via Certbot
$ sudo apt install certbot python3-certbot-nginx
$ sudo certbot --nginx -d muzammilbilwani.com -d www.muzammilbilwani.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/muzammilbilwani.com/fullchain.pem
Cron set up to renew at 00:30 daily

# Verify a cert and see who issued it
$ echo | openssl s_client -connect muzammilbilwani.com:443 -servername muzammilbilwani.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates
subject= CN=muzammilbilwani.com
issuer= C=US, O=Let's Encrypt, CN=R3
notBefore=Apr 1 12:00:00 2026 GMT
notAfter=Jun 30 12:00:00 2026 GMT

# Quick health check (curl shows TLS info)
$ curl -vI https://muzammilbilwani.com 2>&1 | grep -E 'TLS|SSL|HTTP/'
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
HTTP/2 200
ACM Let's Encrypt Certbot DNS validation TLS 1.3 90-day cert

🎯 Practice Questions

Q1.
Why does ACM require certificates for CloudFront to live in us-east-1, even when the rest of your stack is in eu-west-1?
Show Answer
CloudFront is a global service with no concept of region for itself, but the certificate-validation backend lives historically in us-east-1. CloudFront only reads ACM certificates from us-east-1. Your S3 bucket / ALB / origin can live anywhere — the cert is the only resource pinned to us-east-1.

For ALBs in eu-west-1, you request a separate ACM cert in eu-west-1 — those work fine for ALB usage. The us-east-1 rule is CloudFront-specific.
Q2.
Let's Encrypt certs expire after 90 days. Why so short, and how does Certbot prevent your site from going down?
Q3.
A user gets "NET::ERR_CERT_COMMON_NAME_INVALID" hitting https://api.example.com. Where do you start debugging?
💡 Use openssl s_client to inspect the actual cert — does its CN/SAN list include api.example.com?
Q4.
Should you still buy "EV (Extended Validation)" certificates from a paid CA? Why or why not for most modern sites?
07
Performance & CDN Tuning — Cache Headers, Compression, HTTP/2
A 90% cache-hit ratio is achievable. Here's the headers that get you there.
▾

How to explain to students

Performance comes down to two ratios: cache-hit ratio (% of requests served from edge, not origin) and compression ratio (gzip/brotli). The first is governed by Cache-Control headers; the second by enabling compression at the CDN.

The "long-cache for hashed assets, short-cache for index" pattern is the canonical setup. Your bundler (Vite, Webpack) outputs main.abc123.js with a content hash in the filename — set Cache-Control: public, max-age=31536000, immutable and never invalidate. The single index.html gets max-age=60 + invalidate after every deploy.

cache-headers — the canonical pattern
# When syncing to S3
$ aws s3 sync ./dist s3://muzammil-portfolio \
  --exclude "index.html" \
  --cache-control "public,max-age=31536000,immutable"

$ aws s3 cp ./dist/index.html s3://muzammil-portfolio/index.html \
  --cache-control "public,max-age=60"

# Verify in production
$ curl -sI https://muzammilbilwani.com/main.abc123.js | grep -i cache
cache-control: public, max-age=31536000, immutable
x-cache: Hit from cloudfront

$ curl -sI https://muzammilbilwani.com/index.html | grep -i cache
cache-control: public, max-age=60

# Check compression
$ curl -sI -H 'Accept-Encoding: br, gzip' https://muzammilbilwani.com/main.abc123.js \
  | grep -i -E 'content-encoding|content-length'
content-encoding: br
content-length: 24310  # vs uncompressed 142 KB → 6× smaller

# HTTP/2 multiplexing — single connection, parallel requests
$ curl -sI https://muzammilbilwani.com | head -1
HTTP/2 200  # CloudFront speaks HTTP/2 by default

🎯 Practice Questions

Q1.
Why is Cache-Control: public, max-age=31536000, immutable safe for main.abc123.js but disastrous for index.html?
Q2.
Brotli compresses 15–20% better than gzip on JS/CSS. Why hasn't gzip been retired? When is each used?
💡 Browser support + CPU cost.
Q3.
A teammate asks "why are we still using HTTP/2 when HTTP/3 (QUIC) exists?" Give a 2-sentence answer covering the upgrade path and what HTTP/3 fixes.
Q4.
Your CDN reports a 60% cache-hit ratio. Suggest three changes that could push it past 90%.
Show Answer
1. Set proper Cache-Control headers at the origin. Many CDN misses are because the origin returns no cache directive — CDN defaults to short or no caching.
2. Hash your asset filenames (Webpack/Vite/Astro do this automatically). With content-hash in the name, you can confidently set max-age=31536000, immutable.
3. Reduce cache fragmentation. Each unique URL is its own cache entry. Watch out for cache-busting query strings like ?v=12345 that change on every deploy and bypass the cache. Use hashed filenames instead. Also strip irrelevant query params at the CDN.

Bonus: enable stale-while-revalidate so users get cached responses instantly while CDN refreshes in the background.
08
Using AI to Debug DNS, TLS, and CDN Issues
dig, curl -v, and openssl s_client output is dense — AI translates it perfectly
▾

How to explain to students

Networking errors come with terse, jargon-rich output: "NXDOMAIN", "SSL_ERROR_BAD_CERT_DOMAIN", "SERVFAIL". AI is excellent at translating these into "what's broken and where". Always paste the full error + the command that produced it — no PII, but the protocol-level data is fine.

Trap: AI will sometimes hallucinate AWS-specific defaults (e.g. claim ACM certs work outside us-east-1 for CloudFront). Verify against the actual AWS docs for any region/cross-service claim.

AI prompts for networking
# ✅ Strong DNS prompt
"Here is the dig output for api.example.com:
;; ANSWER SECTION:
api.example.com. 300 IN CNAME d-abc123.execute-api.eu-west-1.amazonaws.com.
d-abc123.execute-api.eu-west-1.amazonaws.com. 60 IN A 52.95.16.42
When I curl https://api.example.com I get
'curl: (60) SSL: no alternative certificate subject name matches'.
DNS works (resolves to API Gateway), but TLS fails. What's the most likely cause
and how do I confirm it with openssl s_client?"

# ✅ Strong CDN prompt
"My CloudFront distribution shows x-cache: Miss for 80% of requests.
My origin is S3, files are static, no query strings.
List the top 5 reasons cache hit ratio is this low,
in order of likelihood, with how to check each."

# Quick verify the AI's claim
$ echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A1 "Subject Alternative Name"
X509v3 Subject Alternative Name:
DNS:*.execute-api.eu-west-1.amazonaws.com
↑ doesn't include api.example.com → AI was right, need an API GW custom domain

🎯 Practice Questions

Q1.
Take "DNS isn't working" and turn it into a 5-line prompt that gives AI enough info to actually help.
Q2.
An AI claims "you can request an ACM cert in any region for CloudFront." How would you fact-check before believing it?
💡 The AWS docs for CloudFront / ACM region requirements.
Q3.
Why is pasting a real dig output to AI generally safe, but pasting a real kubectl get secrets output dangerous?
09
Project: Static Résumé on Custom Domain via Route 53 + CloudFront
By the end of this module, every student has https://<name>.com serving their CV, $1/month total
▾

How to explain to students

This is the "first deploy that recruiters actually see." Walk through it on screen. The artefact: a real domain like https://muzammilbilwani.com serving a static CV / portfolio, $1–2/month, A+ on SSL Labs, sub-second load anywhere.

resume-deploy.sh — full pipeline
# 1. Buy domain (any registrar) and point NS at Route 53
aws route53 create-hosted-zone --name muzammilbilwani.com --caller-reference $(date +%s)
# Copy the 4 NS records → set them at your registrar

# 2. Request a free wildcard cert in us-east-1 for CloudFront
aws acm request-certificate \
  --domain-name muzammilbilwani.com \
  --subject-alternative-names www.muzammilbilwani.com \
  --validation-method DNS --region us-east-1
# Add the validation CNAME to Route 53 → cert issued in ~1 minute

# 3. Create S3 bucket (private, OAC will give CloudFront read access)
aws s3 mb s3://muzammil-portfolio --region eu-west-1
aws s3api put-public-access-block --bucket muzammil-portfolio \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 4. Upload the site with the right cache headers
aws s3 sync ./dist s3://muzammil-portfolio --delete \
  --exclude "index.html" \
  --cache-control "public,max-age=31536000,immutable"
aws s3 cp ./dist/index.html s3://muzammil-portfolio/index.html \
  --cache-control "public,max-age=60"

# 5. Create CloudFront distribution (point at S3 with OAC, attach the ACM cert)
aws cloudfront create-distribution --distribution-config file://cf-config.json

# 6. Point the apex + www at CloudFront via Route 53 ALIAS A
aws route53 change-resource-record-sets --hosted-zone-id Z1A2B3C4 \
  --change-batch file://route53-alias.json

# 7. Verify
$ curl -sI https://muzammilbilwani.com | head -3
HTTP/2 200
x-cache: Hit from cloudfront
cache-control: public, max-age=60

# 8. Re-run the SSL Labs test → target an A+ score
open "https://www.ssllabs.com/ssltest/analyze.html?d=muzammilbilwani.com"
💸
~$1/month
Domain ($10/yr) + Route 53 ($0.50/mo) + CloudFront free tier + S3 cents.
🌍
Global < 1s
Cached at 400+ edge POPs. Users in Karachi, Toronto, Tokyo all see < 1s.
🔐
A+ on SSL Labs
Free ACM cert + CloudFront defaults = A+ score with no tuning.
📝
Recruiter-ready
"Hosted my CV at https://my-name.com" sells.
10
Quiz: DNS Records, CDN Concepts, SSL/TLS
5 MCQs + 2 fill-in-the-command questions
▾

Sample quiz questions (interactive)

Q1. Which record points a name to an IPv4 address?
A
A
B
AAAA
C
CNAME
D
MX
Q2. Why can't a CNAME live on the apex (example.com)?
A
CNAMEs are deprecated
B
The apex needs other records (NS, SOA) and CNAMEs can't co-exist with them
C
They take too long to resolve
D
They're insecure
Q3. ACM certificates for CloudFront must be requested in which region?
A
us-east-1
B
Same region as the S3 origin
C
Any region
D
me-central-1
Q4. The header that tells you whether CloudFront served from cache:
A
cache-control
B
server-timing
C
x-cache
D
via
Q5. Let's Encrypt certificates are valid for:
A
30 days
B
90 days
C
1 year
D
5 years

Fill-in-the-command

Fill 1: dig command for the MX records of banoqabil.pk, short form.
Fill 2: Certbot command to issue a cert for example.com auto-configuring nginx.
11
Assignment: Configure Cloudflare for a Live Site
Caching, HTTPS, redirects, page rules — and verify with command-line tooling
▾

How to explain to students

Frame as a real client task: "Move my site to Cloudflare. I want HTTPS everywhere, cache static assets aggressively, redirect www → apex, and block traffic from one country. By Friday." This forces students through Cloudflare's full DNS / SSL / Page Rules workflow with a verifiable end state.

📋 Assignment Requirements

  • Pick any domain you control (or buy one for $1 at Namecheap/Cloudflare)
  • Add the domain to a free Cloudflare account; switch the registrar's nameservers to Cloudflare's
  • Verify dig NS yourdomain.com +short shows two *.ns.cloudflare.com nameservers
  • Set up an A or CNAME record pointing at any origin (an S3 static site, a Vercel deploy, a free EC2)
  • Force "Always Use HTTPS" — verify curl -sI http://yourdomain.com returns a 301 to https://
  • Set the SSL/TLS mode to Full (Strict) — your origin must have a valid cert
  • Add a redirect rule: www.yourdomain.com → yourdomain.com (or vice versa)
  • Configure caching: HTML max-age=60, static assets max-age=1y, verify with curl -sI + cf-cache-status header
  • Add a Page Rule that bypasses cache for /admin/*
  • Run an SSL Labs test — must score A or higher. Screenshot it.
  • Bonus: Enable Brotli + HTTP/3 → verify with curl --http3 -sI
  • Bonus: Add a firewall rule blocking traffic from one country and demonstrate it
  • Submit a 1-page README documenting each setting + screenshots of the verification commands
expected acceptance test
$ curl -sI http://yourdomain.com | head -2
HTTP/1.1 301 Moved Permanently
location: https://yourdomain.com/

$ curl -sI https://yourdomain.com/styles.css | grep -iE 'cache|cf-'
cache-control: public, max-age=31536000, immutable
cf-cache-status: HIT
cf-ray: 8f1a2b3c4d-MRS

$ curl -sI https://www.yourdomain.com | head -2
HTTP/2 301
location: https://yourdomain.com/

$ dig NS yourdomain.com +short
arnold.ns.cloudflare.com.
cori.ns.cloudflare.com.
📊
Grading rubric
NS delegated: 15. HTTPS forced: 15. Cache HIT verified: 20. Redirect works: 15. SSL Labs A+: 15. Page rule + bonuses: 20.
🎯
Common mistakes
SSL/TLS mode = "Flexible" (insecure!), forgot to wait for NS propagation, page rule order wrong, no validation screenshots.
💡
Stretch
Add a Cloudflare Worker that injects a custom header on every response.