🔄 Topic

Connecting the Farina domain setup to DNS, CNAME, and production reachability.

🎯 Goal

Understand how custom domains and DNS records affect whether users can actually reach the website.

🛠 What I Did

I reviewed the custom domain side of the Farina website. The repository includes a CNAME file for the production domain, and deployment checks make sure that file exists in the final build output. This connects directly to previous networking study: a website is not only code. Users need DNS resolution, correct domain configuration, HTTPS, hosting, and valid routing before the page loads.

Main areas covered:

  • custom domain
  • CNAME file
  • GitHub Pages configuration
  • DNS records
  • production domain reachability
  • deployment validation

🔗 Key Cybersecurity Connections

DNS matters because many ‘website down’ problems are not code problems. They can be DNS, certificate, routing, hosting, or deployment configuration problems.

🔍 Investigation Questions

  • Does the domain resolve?
  • Does www point to the expected host?
  • Is the CNAME included in the deployed output?
  • Does HTTPS work?
  • Is the issue DNS, hosting, or application-level?

🚨 Detection Opportunities

Potential monitoring ideas:

  • DNS resolution failures
  • unexpected DNS record change
  • certificate errors
  • CNAME missing from deployment
  • traffic drop after domain configuration change

Example:

project=farina-farm-website
change_type=public_website_update
risk_area=repository_deployment_or_public_input
triage=review_change_intent_and_validate_build

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1498 — Network Denial of Service
  • T1499 — Endpoint Denial of Service
  • T1565 — Data Manipulation

🗺 Visual Investigation Diagram

User browser
    ↓ DNS lookup
    ↓ GitHub Pages host
    ↓ HTTPS
    ↓ Static site response

⚠ Challenges

The challenge was remembering that deployment success does not always mean reachability. The build can pass while DNS or domain configuration breaks access.

📚 What I Learned

I learned that custom domains are operational dependencies. They need simple checks and documentation.

➡ Next Steps

  • Document DNS settings
  • Check domain after deployment
  • Keep CNAME committed
  • Separate DNS issues from app issues

🧠 Reflection

This was useful because it turned a real project into security-aware learning without pretending that every task was a pure cybersecurity lab.

🧩 Lessons Learned

What worked

Connecting DNS theory to a real domain.

What broke

Assuming website availability is only about code.

Why it broke

Users depend on DNS before they ever touch the app.

Fix / takeaway

When a website is unreachable, test DNS first, not last.

📈 Skill Progression Context

This supports cybersecurity progression because DNS appears constantly in SOC investigations, outages, phishing, and attacker infrastructure.

😄 TL;DR

No DNS, no website.