How the Internet Actually Works - Networking, DNS, Architecture & My DMI DevOps Journey

Week 0: How the Internet Actually Works - Networking, DNS, Architecture & My DevOps Journey Begins

I recently joined the DevOps Micro Internship (DMI) – Cohort 3, a free, project-based program by Pravin Mishra at CloudAdvisory. Before we dive into the exciting parts - containers, CI/CD pipelines, Kubernetes, cloud platforms - the program correctly insists on mastering the foundational concepts first.

This post documents everything I worked through in Week 0, covering five core tasks and my honest reflections. If you are starting your DevOps journey, this post is for you too. Consider this a beginner-friendly technical reference, not just a journal entry.

Why Foundations Matter in DevOps

It is tempting to jump straight into Docker or AWS. I get it - the tools look cool, the job postings mention them everywhere, and YouTube tutorials make them seem approachable. But here is the uncomfortable truth: tools break, documentation changes, and architectures evolve. What does not change nearly as fast is the underlying fundamentals.

A DevOps engineer who understands how data actually travels across a network, why DNS exists, and how application layers are separated will debug production incidents faster, design more resilient systems, and adapt to new tools with far less friction. That is the mindset behind Week 0.

Let's get into it.

Task 1 - Exploring Concepts with AI: Networking Protocols

The first task involved using ChatGPT to explore networking protocols from first principles. The goal was not just to get an answer, but to learn how to ask precise questions and synthesise the response into a genuine understanding.

What Are Networking Protocols?

A networking protocol is a standardised set of rules that governs how data is transmitted between devices on a network. Without protocols, two devices attempting to communicate would be like two people trying to have a conversation, one speaking English and the other French, with no shared framework.

Protocols define:

• Format: What does a valid message look like?
• Sequencing: Who speaks first? Who speaks next?
• Error handling: What happens when something goes wrong?
• Termination: How does the conversation end cleanly?

Think of it like road traffic laws. The laws do not build the roads, but they ensure that everyone using the roads does so in a predictable, safe, and efficient manner. Without them, even a perfectly built road would result in chaos.

Key Insight from This Task

What struck me most was how protocols operate in layers. No single protocol handles everything. Instead, a stack of protocols each handles a specific concern, and together they make the internet function. This layered thinking - breaking a complex problem into isolated, composable responsibilities - is also a core principle in software architecture and DevOps. I would encounter it again and again as the week progressed.

Task 2 - Internet & Networking Fundamentals

This task required me to explain four foundational concepts in my own words. Here is my in-depth take on each.

Packet Switching

When you send a message, a file, or a video stream across the internet, that data is not sent as one giant, continuous stream. Instead, it is broken into small chunks called packets. Each packet contains a piece of the actual data (the payload), plus metadata - the source address, destination address, sequence number, and error-checking information.

These packets do not all travel the same route. Routers across the internet evaluate network conditions in real time and forward each packet along the most efficient path available at that moment. At the destination, the packets are reassembled in the correct order.

Why does this matter? Packet switching is what makes the internet resilient. If one network link fails, packets are simply rerouted. No single point of failure can take down the entire communication. This is a fundamentally different (and superior) model to the old circuit-switched telephone network, where a dedicated line had to remain open for the entire duration of a call.

The DevOps connection: When you are debugging network latency or packet loss in a distributed system, understanding packet switching tells you why packets arrive out of order, why retransmission happens, and where to look when something is slow.

IP Address

An IP (Internet Protocol) address is a numerical label assigned to every device on a network. It serves two core purposes: host identification (which device is this?) and location addressing (where is this device on the network?).

There are two versions currently in use:

The world ran out of IPv4 addresses years ago. Techniques like NAT (Network Address Translation) have extended IPv4's lifespan by allowing multiple devices on a private network to share a single public IP, but IPv6 adoption is the long-term solution.

The DevOps connection: You will work with IP addresses constantly - assigning them to servers, configuring security group rules, setting up load balancers, and troubleshooting connectivity. Understanding the difference between public and private IPs, and how subnetting works, is essential for cloud networking on AWS, GCP, or Azure.

TCP/IP

TCP/IP is not one protocol but a suite of protocols. The two most important are:

IP (Internet Protocol) - handles addressing and routing. It is responsible for getting packets from a source to a destination, but it is connectionless and does not guarantee delivery or order.

TCP (Transmission Control Protocol) - adds reliability on top of IP. Before any data is sent, TCP performs a three-way handshake:

1. SYN: The client sends a synchronise packet to the server.
2. SYN-ACK: The server acknowledges and sends its own synchronise.
3. ACK: The client acknowledges the server's response.

A connection is now established. TCP then ensures every packet is received, requests retransmission of any lost packets, and delivers data to the application layer in the correct order.

UDP (User Datagram Protocol) is the alternative - connectionless, no handshake, no guaranteed delivery. It is faster, which makes it ideal for video streaming, gaming, and DNS lookups where a dropped packet is less catastrophic than a delay.

The DevOps connection: When you configure a load balancer, you choose between TCP and HTTP (which runs on top of TCP). When you write a Dockerfile exposing a port, you specify TCP or UDP. Understanding this layer is the difference between configuring things by guessing and configuring them with confidence.

HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the application-layer protocol used to transfer web pages, APIs, and other resources over the internet. It operates on a simple request-response model:

1. A client (browser, API consumer, CLI tool) sends an HTTP request with a method (GET, POST, PUT, DELETE), headers, and optionally a body.
2. A server returns an HTTP response with a status code, headers, and optionally a body.

HTTPS (HTTP Secure) wraps HTTP inside TLS (Transport Layer Security), which provides:

• Encryption: Data in transit cannot be read by third parties (man-in-the-middle attacks are thwarted).
• Authentication: The server's identity is verified via a certificate signed by a trusted Certificate Authority (CA).
• Integrity: Data cannot be tampered with in transit without detection.

The analogy I find most intuitive: HTTP is like sending a postcard - anyone handling it can read what it says. HTTPS is like sending a letter in a tamper-proof, locked box. Only the intended recipient has the key.

The DevOps connection: You will configure TLS certificates using tools like Let's Encrypt and Cert-Manager. You will set up HTTPS on Nginx or a cloud load balancer. You will debug SSL handshake failures and certificate expiry alerts. Knowing what HTTPS actually does - not just that it "adds a padlock" - makes all of this manageable.

Task 3 - Application Architecture: Two-Tier vs. Three-Tier

Modern applications are not monolithic blobs of code. They are organised into architectural tiers - logical layers that separate concerns, enable independent scaling, and support team-based development. Understanding these tiers is critical for anyone working in DevOps, because you need to know what you are deploying, where each component lives, and how the layers communicate.

Two-Tier Architecture

In a two-tier (client-server) architecture, the application is split into exactly two layers:

┌─────────────────────┐
│    CLIENT TIER      │  ← Presentation + Business Logic
│ (Browser / Desktop) │
└──────────┬──────────┘
           │ Direct DB queries
           ▼
┌─────────────────────┐
│   DATABASE TIER     │  ← Data Storage
│ (MySQL / PostgreSQL)│
└─────────────────────┘

When it works well: Small internal tools, desktop applications with a limited number of users, and rapid prototyping. The simplicity means less infrastructure to manage.

Where it breaks down: The client handles both the UI and business logic. This means every client must be updated when business rules change. It also means clients often have direct database access, which is a serious security concern at scale.

Technologies typically involved:

Three-Tier Architecture

Three-tier architecture introduces a dedicated middle layer - the application server (or backend) - between the client and the database.

┌─────────────────────┐
│   PRESENTATION TIER │  ← UI only
│  (Browser / Mobile) │
└──────────┬──────────┘
           │ HTTP/HTTPS requests
           ▼
┌─────────────────────┐
│   APPLICATION TIER  │  ← Business Logic & APIs
│ (Node.js / Django)  │
└──────────┬──────────┘
           │ Parameterised queries
           ▼
┌─────────────────────┐
│     DATA TIER       │  ← Persistent Storage
│ (PostgreSQL/MongoDB)│
└─────────────────────┘

Why this matters:

• Security: No client ever touches the database directly. The backend validates and sanitises all input before any query is executed.
• Scalability: Each tier can be scaled independently. If your API is the bottleneck, you spin up more backend instances without touching the frontend or the database.
• Maintainability: Business logic lives in one place. Change a rule in the backend, and all clients - web, mobile, CLI - immediately reflect that change.
• Team autonomy: Frontend engineers, backend engineers, and DBAs can work in parallel without constantly stepping on each other.

Technologies typically involved:

The DevOps connection: When you write a Kubernetes deployment, you are typically deploying each tier as a separate service with its own pods, resource limits, health checks, and scaling policies. When you design a CI/CD pipeline, you often have separate pipelines for the frontend and backend. When you configure a database, you write network policies that allow only the backend service to connect. Three-tier thinking is baked into modern infrastructure.

Task 4 - Domain Name System (DNS) Deep Dive

DNS is one of those technologies that most people take for granted - until it breaks. When DNS goes down, the internet, from a user's perspective, ceases to work. Understanding how it works is not optional for a DevOps engineer.

What is DNS?

DNS stands for Domain Name System. Its primary job is to translate human-readable domain names (like epicreads.com) into machine-readable IP addresses (like 52.172.142.222).

Without DNS, you would need to memorise the IP address of every website you want to visit. DNS is the phonebook of the internet.

How DNS Resolution Works (Step by Step)

When you type epicreads.com into your browser and hit Enter, here is what actually happens:

Browser → OS Cache → Recursive Resolver → Root Nameserver
       → TLD Nameserver (.com) → Authoritative Nameserver
       → Returns IP → Browser connects to 52.172.142.222

1. Browser cache: The browser checks its own cache. Did it look up this domain recently?
2. OS cache: If not, the operating system checks its own DNS cache (/etc/hosts on Linux, the Windows DNS Client service).
3. Recursive resolver: If still not found, the query goes to your ISP's (or a public) recursive resolver, such as 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). This resolver does the heavy lifting on your behalf.
4. Root nameservers: The resolver asks a root nameserver. There are 13 sets of root nameservers globally. They do not know the IP of epicreads.com, but they know who is authoritative for .com domains.
5. TLD nameservers: The .com nameserver knows which nameserver is authoritative for epicreads.com.
6. Authoritative nameserver: This is the nameserver managed by the domain's owner (e.g., via AWS Route 53 or Cloudflare). It returns the definitive answer: the IP address associated with epicreads.com.
7. Response travels back: The IP is cached at multiple levels (with a TTL - Time to Live - that controls how long it stays cached) and returned to the browser.

DNS Record Types

Connecting epicreads.com to 52.172.142.222

To map the domain epicreads.com to the IP address 52.172.142.222, you create an A Record in the domain's DNS zone:

epicreads.com.   300   IN   A   52.172.142.222

• epicreads.com. - the hostname (the trailing dot indicates the DNS root)
• 300 - the TTL in seconds (5 minutes); after this time, cached records expire
• IN - Internet class
• A - record type (IPv4 address mapping)
• 52.172.142.222 - the destination IP address

Why not a CNAME? A CNAME maps a name to another name, not to an IP address. CNAMEs also cannot be used at the zone apex (the root domain, e.g., epicreads.com itself) - they can only be used on subdomains. So www.epicreads.com could be a CNAME pointing to epicreads.com, but epicreads.com itself must use an A record.

The DevOps connection: You will configure DNS records constantly - pointing domains to load balancers, configuring subdomains for different services, setting up MX records for transactional email, and adding TXT records to verify domain ownership for SSL certificates. Understanding TTL is critical too: if you set a TTL of 86400 (24 hours) and need to change an IP urgently, you will be waiting a very long time for the change to propagate globally.

Task 5 - Development Environment Setup: Visual Studio Code

A professional development environment is not a luxury - it is the foundation on which all your work is built. I set up Visual Studio Code (VS Code) as my primary editor for this internship.

Why VS Code for DevOps?

VS Code has become the de facto standard for DevOps engineers for several reasons:

• Language support: From Python and Go to Bash and YAML, VS Code handles everything through its extension marketplace.
• Integrated terminal: You can run commands without switching windows, which becomes enormously productive over time.
• Git integration: Built-in source control panel with diff views, staging, committing, and branching.
• Extension ecosystem: Thousands of extensions for Docker, Kubernetes, Terraform, AWS, Azure, and more.
• Remote development: The Remote - SSH and Dev Containers extensions allow you to develop directly on remote servers or inside containers, which is invaluable for DevOps workflows.

Key Extensions I Installed

The Broader Toolchain

VS Code is just the editor. A complete DevOps development environment also includes:

• Git - version control (non-negotiable for every project)
• A terminal - WSL2 on Windows, or the built-in terminal on macOS/Linux
• Node.js / Python - scripting and automation
• Docker Desktop - container runtime for local development
• A cloud CLI - AWS CLI, Azure CLI, or gcloud, depending on your target platform

Getting comfortable with these tools before working on live infrastructure is essential. Mistakes in a local environment are free. Mistakes in production are expensive.

Reflection: Week 0 in Honest Review

What I Found Easy

The networking and DNS sections came naturally to me. These concepts map closely to everyday experiences - browsing websites, using email, navigating apps - so the mental models were already partially in place. I found that once you have the right analogy (packets as parcels, DNS as a phonebook, HTTPS as a locked envelope), the technical details click into place quickly.

What Was Difficult

Application architecture - specifically the distinction between two-tier and three-tier designs - required more effort than I anticipated. The concepts sound simple in isolation, but understanding the implications of each architectural decision takes deeper thinking. Why does moving business logic from the client to a dedicated application server change everything about scalability, security, and maintainability? The answer requires holding multiple concerns in mind simultaneously.

I also found that the most challenging part was not understanding what the layers are, but understanding why the separation exists and what goes wrong when it is violated. Reading about real-world examples - monolithic applications that became impossible to scale, data breaches caused by direct client-to-database access - made the architectural principles feel concrete rather than academic.

What I Will Improve Next Week

Hands-on practice with real tools. Reading and writing about networking is valuable, but there is a qualitative difference between understanding how DNS works conceptually and actually configuring a DNS zone, watching propagation happen, and debugging a misconfigured record. My goal for Week 1 is to close the gap between theoretical knowledge and practical muscle memory.

Specifically, I plan to:

• Practice Linux command-line navigation and file management
• Work through basic shell scripting exercises
• Explore cloud console interfaces (starting with AWS)
• Revisit application architecture by building a minimal three-tier app locally

Key Takeaways

If you have read this far, here is a summary of the most important concepts from Week 0:

1. Networking protocols are layered. No single protocol handles everything. Understanding the layers prevents tunnel vision when debugging.
2. Packet switching is what makes the internet resilient. Data takes multiple paths; failures are routed around automatically.
3. HTTPS is not just about the padlock. It provides encryption, authentication, and integrity - three distinct security guarantees.
4. Three-tier architecture is the baseline for modern applications. Separation of concerns enables independent scaling, improved security, and team autonomy.
5. DNS is the phonebook of the internet, and A records map domain names to IPv4 addresses. TTL controls how long these mappings are cached globally.
6. Your development environment is infrastructure. Set it up thoughtfully, version-control your configurations, and keep it consistent.

If you are following along or if you are on a similar DevOps learning path, feel free to connect in the comments. I would love to hear what foundational concepts you found most challenging - or which ones surprised you the most.

This post is part of my public learning journey through the DevOps Micro Internship (DMI) – Cohort 3 by Pravin Mishra at CloudAdvisory. All tasks completed in this programme are documented openly on this blog.

About DevOps Micro Internship (DMI) & CloudAdvisory
DevOps Micro Internship (DMI) is a free, project-based DevOps learning program by Pravin Mishra (CloudAdvisory). It helps students, job-seekers, and working professionals gain real-world DevOps skills through weekly assignments, projects, and community support.

🌐 DMI Official Website: https://pravinmishra.com/dmi

🎓 DevOps for Beginners: Docker, K8s, Cloud, CI/CD & 4 Projects (Udemy): https://www.udemy.com/course/devops-for-beginners-docker-k8s-cloud-cicd-4-projects/?referralCode=C5BA8236CCE9FE004F98

▶️ DevOps for Beginners – YouTube Playlist: https://www.youtube.com/playlist?list=PLVOdqXbCs7bX88JeUZmK4fKTq2hJ5VS89

🔗 Follow Pravin Mishra on LinkedIn: https://www.linkedin.com/in/pravin-mishra-aws-trainer/