What is DNS?

DNS stands for Domain Name System. Think of it like your phone’s contacts app.

• You search for a name

• Your phone finds the number

• You tap the name instead of memorising the number

So, DNS basically translates names to numbers. But what names? What numbers?

Humans like names:

• google.com

• netflix.com

Computers prefer numbers (IP addresses):

• 142.250.182.14

DNS is a global system responsible for mapping human-readable hostnames to their corresponding Internet Protocol (IP) addresses. For example, if you want to access a website using a domain name like example.com, that domain name must point to a valid IP address.

The human-readable hostname is a string of words that are easy to remember. IP addresses, on the other hand, contain numbers separated by dots and are harder to remember. For example, example.com is the human-readable domain name, while 93.184.216.34 is the current IP address for example.com. Also, note that the IP address associated with a domain name may change depending on the server hosting the website.

Why DNS Records Are Required

A domain name is of no use unless the internet knows:

• which server hosts the website

• which server handles email

• who controls/owns the domain

• extra configuration and security info

DNS records basically have instruction for the internet for what to do with the domain name.

Types of DNS records

The following are the five major DNS record types:

• A record

• AAAA record

• CNAME record

• Nameserver (NS) record

• Mail exchange (MX) record

There are other types too like TXT, SOA, DNAME, etc. We will only briefly touch upon the TXT record.

1. A record: The A record is the most important DNS record type. The "A" in A record stands for "address." The main use of A record is for IP address lookup. Using an A record, a web browser is able to load a website using the domain name. As a result, we can access websites on the internet without knowing their IP addresses. Note that the A record only supports IPV4 addresses, which look something like 142.250.182.14.

2. AAAA record: AAAA record, just like A record, point to the IP address for a domain. However, this DNS record type is different in the sense that it points to IPV6 addresses. IPV6 is an upgrade over IPV4 as it offers more IP addresses, as the internet keeps growing and we're running out of unique IPV4 addresses. An IPV6 address looks something like 3001:0db7:3c5d:0024:0000:0000:1a2f:3c1b

3. CNAME record: CNAME - or, in full, "canonical name" - s a DNS record that points a domain name (an alias) to another domain. In a CNAME record, the alias doesn't point to an IP address. And the domain name that the alias points to is the canonical name. For example, the subdomain ng.example.com can point to example.com using CNAME. Here example.com points to the actual IP address using an A record. A practical example for the use of CNAME records is running multiple subdomains for different purposes on the same server. For example, we can use ftp.example.com for file transfer protocol (FTP) and serve webpages via www.example.com. We can then use a CNAME record to point both subdomains to example.com. The main domain example.com then points to the server's IP address using an A record.

4. NS record: A nameserver (NS) record specifies the authoritative DNS server for a domain. In other words, the NS record helps point to where internet applications like a web browser can find the IP address for a domain name. Usually, multiple nameservers are specified for a domain. For example, these could look like ns1.examplehostingprovider.com and ns2.examplehostingprovider.com.

5. MX record: A mail exchange (MX) record shows where emails for a domain should be routed to. In other words, an MX record makes it possible to direct emails to a mail server. With an MX record, it's possible to hand off emails to a dedicated email server. For example, you can decide to leave all the trouble of setting up webmail on a server you own to a specialized email provider. This comes with many benefits, including custom email clients for reading and sending emails, and improved security and spam filters.

6. TXT record: TXT stands for "text," and this record type lets the owner of a domain store text values in the DNS. Several services use this record to verify ownership of a domain, email security among other purposes.

How All DNS Records Work Together for One Website

Let’s say we own a domain example.com. The way it all works together is:

1. NS records tell which DNS servers control example.com.

2. A / AAAA records tell browsers where the website server is.

3. CNAME records create aliases like www.example.com.

4. MX records tell email systems where to send mail.

5. TXT records verify ownership and secure email.

So when you visit a website:

• Browser asks DNS: “Where is example.com?”

• DNS follows NS → A/AAAA → IP

• Browser connects to the server

When you send an email:

• Mail server asks DNS: “Where is example.com’s mail server?”

• DNS returns MX → mail server address

Git, created by Linus Torvalds in 2005, is something we call a version control system or VCS. Now what is a VCS, you may ask? A VCS is a software tool that helps manage changes to source code (or any data) over time.

Git is a system that tracks changes to source code over time.

In basic terms, Git helps us store what changed, who changed it, and when it changed. It even allows us to revert to a specific “version” of the code or file if needed (often done if any change ends up breaking the code!). It also allows collaboration with multiple developers, and gracefully manages simultaneous changes to the same code. If you want to understand why we even need systems like Git, read my other article here. It is an industry standard as almost every software organisation uses a platform that uses Git, most famously Github, and a few others like BitBucket, GitLab, etc.

Basic terms

• Repository (Repo): This is the folder that git tracks. It contains your project files, and also Git’s metadata and history. Any folder in your system can be made into a Git repo by running the command git init inside it.

• Branch: It is like a separate workspace where changes can be made without affecting the original codebase. Branches can be a new version of a repository, experimental changes, or personal forks (refer below) of a repo for users to make and test changes. The default or top level branch is usually the main (or master) branch. Other branches (usually called feature branches) can be created from main.

• Commit: If you’ve ever played video games, you can think of it as a save game. It saves your progress at a point in time. If you are WASTED (if you get the reference, we’re friends) at any point in the game, latest save game is loaded. Similarly, a commit is a snapshot of your project at a specific point in time, with a message describing what changed, and who changed it. You can always go back to a previous commit if you need to (in case anything “breaks”).

• HEAD: It is a reference to your current position in Git history. By default, it points to the latest commit of the current branch. So, if you make a new commit to the same branch, the HEAD will point to that commit. You can even switch to a different branch, then the HEAD will point to the latest commit of that branch.

• Fork: A copy of any repository, usually done to make your own customised version or build on top of that codebase.

• Checkout: Refers to switching between branches in a repo. Syntax is: git checkout <branch-name>. So if you hear someone say checkout to main or checkout to feature-a, they’re telling you to switch to that branch.

• Push: Updates a remote with the commits made to the current branch using the git push command. You are literally "pushing" your changes to the remote.

• Pull: Simply means retrieving updates from remote into your local environment. Usually done with git pull command, which is technically git fetch + git merge. In short, git fetch downloads new changes, git merge applies those changes to your local.

• Remote: A copy of the original repo. It simply points to another “version” of the repo, which usually resides on a server like GitHub. So if you create a repo on your machine, that is your local repo. You then push it to GitHub, then that repo becomes the remote. This repo will be used by you and other collaborators to push and pull changes.

• Origin: The default name for the primary version of a repository. Git also uses origin as a system alias for pushing and fetching data to and from the primary branch. For example, git push origin main, when run on a remote, will push the changes to the main branch of the primary repository.

Git workflow

The above figure roughly represents how git organises your workflow. There are three main areas:

1. Working directory - where your files reside and you make changes

2. Staging area - where you prepare changes for committing

3. Repository - where Git permanently stores commits

Essential commands

• git init: Initialises git in your project folder. This creates a .git folder within your project folder that git uses to track your content. If you want to know more about the .git folder, read a part of my other article here.

• git add: Adds files you want to track in the “staging area”, which means that you intend to commit these files. Syntax is git add <file-name> but usually use git add . to add all files in the workspace to the staging area.

• git commit: Creates a snapshot of the staged changes. Once you commit, the changes/files are ready to be pushed to remote. Syntax: git commit -m “commit-message”. The commit message is a short and meaningful description of the changes.

• git push: Pushes your changes to the remote.

• git branch: Lists all branches

• git status: Shows the current state of the repo like which files were modified, which ones are new, what changes are staged, etc.

• git log: It shows the commit history of the repo, which includes commit hash (unique ID), author, date, commit message. Below is a rough representation of how commits work and how commit history may be shown.

Basic Git workflow

This is a follow along so that you can make your first git commit! All commands will be from terminal (cmd or powershell for Windows).

1. Create a new project: You can create a new folder anywhere on your system and go into that folder.

mkdir new-project

cd new-project

2. Initialise git: git init

3. Create a file: touch index.html

4. Check status: git status

5. Add file to staging area: git add index.html

6. Commit changes: git commit -m “add index.html”

Congratulations! You’ve just made your first git commit.

The age of "Final_v2_REALLY_FINAL"

In the early days, or when you're just starting out, the project is usually just folders. You’ve probably been there: you have a folder named project, then project_backup, then project_final, and eventually project_final_v2_use_this_one.

Even with a single developer, this is a disaster waiting to happen. Which one actually works? Which one has the bug you fixed yesterday? It’s unreliable, but it’s a cakewalk compared to what happens when you add more developers to the mix.

The Pendrive Analogy

In the real world, software development is a team game. Imagine the logistics of a team working without a Version Control System (VCS).

Developer A finishes a feature. To share it, he zips the folder, puts it on a pendrive, and hands it to Developer B. Now, Developer B has the "latest" code. But what if Developer C was working on a different part of the app at the exact same time?

Do you see the problem?

• The Overwrite Trap: If Developer C gives his pendrive to Developer B, does Developer B just copy-paste over everything? If he does, Developer A’s work might just... vanish.

• The Sync Struggle: There is no "master copy." The code exists in three different states on three different desks.

• No Paper Trail: If the app suddenly starts crashing, no one knows why. Who changed line 42? Was it on the first pendrive or the third? There’s no history, just a bunch of zip files and hopes.

Moving from Chaos to Version Control

This is exactly why Version Control Systems (like Git) became mandatory. Think of a VCS as a "Living Map" of your project rather than a series of snapshots.

Instead of passing a physical drive or emailing a .zip file, every developer works on a shared history.

When you use a VCS, the system handles the heavy lifting:

• Merging: Identifies if two people edited the same file and helps combine them without losing data.

• The Time Machine: If you break everything at 2:00 AM, you can "roll back" to the version from 1:59 AM.

• Accountability: Records exactly who changed what, helping to understand the "why" behind a change six months later.

A Version Control System works by tracking 'deltas'—which are the specific changes between lines of code—instead of just saving hundreds of copies of the whole folder. By using a Directed Acyclic Graph (DAG) (above diagram roughly represents it) to map out commits, the software can use merging algorithms to combine work automatically. It can see that Developer A changed line 10 and Developer B changed line 50, and it merges them without any issues. This move from managing badly named folders to 'line-based tracking' is what allows a team to have a single source of truth.

At the end of the day, Version Control exists because humans are messy and collaboration is hard. It turns the pendrive problem into a structured, searchable, and safe environment where you can actually focus on writing code instead of managing folders.