Introduction to DNS | Learn System Design

System Design

Learn System Design

Introduction to System Design

How to Learn System Design?

Key Characteristics of Distributed Systems

Scalability

Availability

Latency and Performance

Concurrency and Coordination

Monitoring and Observability

Resilience and Error Handling

Fault Tolerance vs. High Availability

Flashcards Review

Chapter Assessment

Network Essentials

HTTP vs. HTTPS

TCP vs. UDP

HTTP: 1.0 vs. 1.1 vs 2.0 vs. 3.0

URL vs. URI vs. URN

What Happens When You Type a URL into the Browser

Flashcards Review

Chapter Assessment

Long-Polling vs. WebSockets vs. Server-Sent Events

Introduction to Real-Time Communication

What is Long-Polling?

What is WebSocket?

What are Server-Sent Events?

Difference Between Long-Polling, WebSockets, and Server-Sent Events

Flashcards Review

Chapter Assessment

Domain Name System (DNS)

Introduction to DNS

DNS Resolution Process

DNS Load Balancing and High Availability

Flashcards Review

Chapter Assessment

Proxies

What is a Proxy Server?

Uses of Proxies

VPN vs. Proxy Server

Flashcards Review

Chapter Assessment

Load Balancing

Introduction to Load Balancing

Load Balancing Algorithms

Uses of Load Balancing

Load Balancer Types

Stateless vs. Stateful Load Balancing

High Availability and Fault Tolerance

Scalability and Performance

Challenges of Load Balancers

Flashcards Review

Chapter Assessment

API Gateway

Introduction to API Gateway

Usage of API gateway

Advantages and disadvantages of using API gateway

Flashcards Review

Chapter Assessment

API Design

What Is an API?

What Are REST APIs?

Resources, Not Actions

HTTP Methods and Their Semantics

URL Design

Request and Response Shapes

Status Codes and Error Design

Pagination from the Consumer's View

Idempotency Keys

Versioning and Backward Compatibility

Concurrency and Conditional Requests

REST vs gRPC vs GraphQL

Flashcards Review

Chapter Assessment

Rate Limiting and Throttling

What Is Rate Limiting

Rate Limiting Algorithms

Distributed Rate Limiting

Rate Limiting in Practice

Flashcards Review

Chapter Assessment

Caching

Introduction to Caching

Why is Caching Important?

Types of Caching

Cache Replacement Policies

Cache Invalidation

Cache Read Strategies

Cache Coherence and Consistency Models

Caching Challenges

Cache Performance Metrics

Flashcards Review

Chapter Assessment

CDN

What is CDN?

Origin Server vs. Edge Server

CDN Architecture

Push CDN vs. Pull CDN

Flashcards Review

Chapter Assessment

Data Partitioning

Introduction to Data Partitioning

Partitioning Methods

Data Sharding Techniques

Benefits of Data Partitioning

Common Problems Associated with Data Partitioning

Flashcards Review

Chapter Assessment

Redundancy and Replication

What is Redundancy?

What is Replication?

Replication Methods

Data Backup vs. Disaster Recovery

Flashcards Review

Chapter Assessment

CAP & PACELC Theorems

Introduction to CAP Theorem

Components of CAP Theorem

Trade-offs in CAP Theorem

Examples of CAP Theorem in Practice

Beyond CAP Theorem

System Design Trade-offs in Interviews

Flashcards Review

Chapter Assessment

Databases (SQL vs. NoSQL)

Introduction to Databases

SQL Databases

NoSQL Databases

SQL vs. NoSQL

ACID vs BASE Properties

Real-World Examples and Case Studies

SQL Normalization and Denormalization

In-Memory Database vs. On-Disk Database

Data Replication vs. Data Mirroring

Database Federation

Flashcards Review

Chapter Assessment

Indexes

What are Indexes?

How a B-Tree Index Works

Types of Indexes

B-Tree vs. LSM Tree

Indexes in Distributed Systems

Flashcards Review

Chapter Assessment

Bloom Filters

Introduction to Bloom Filters

Benefits & Limitations of Bloom Filters

Variants and Extensions of Bloom Filters

Applications of Bloom Filters

Flashcards Review

Chapter Assessment

Quorum

Why Quorum?

What is Quorum?

Flashcards Review

Chapter Assessment

Leader and Follower

What is Leader and Follower Pattern?

Flashcards Review

Chapter Assessment

Heartbeat

What is Heartbeat?

Flashcards Review

Chapter Assessment

Checksum

What is Checksum?

Uses of Checksum

Flashcards Review

Chapter Assessment

Distributed Messaging System

Introduction to Messaging System

Introduction to Kafka

Messaging patterns

Popular Messaging Queue Systems

RabbitMQ vs. Kafka vs. ActiveMQ

Scalability and Performance

Flashcards Review

Chapter Assessment

Distributed File Systems

What is a Distributed File System?

Architecture of a Distributed File System

Key Components of a DFS

Flashcards Review

Chapter Assessment

Security

What is Security and Privacy?

What is Authentication?

What is Authorization?

Authentication vs. Authorization

OAuth vs. JWT for Authentication

What is Encryption?

What are DDoS Attacks?

Flashcards Review

Chapter Assessment

Misc Concepts

Batch Processing vs. Stream Processing

XML vs. JSON

Synchronous vs. Asynchronous Communication

Push vs. Pull Notification Systems

Microservices vs. Serverless Architecture

Message Queues vs. Service Bus

Stateful vs. Stateless Architecture

Event-Driven vs. Polling Architecture

Flashcards Review

Chapter Assessment

Quiz - System Design Fundamentals

Quiz

System Design Trade-offs

Importance of Discussing Trade-offs

Strong vs Eventual Consistency

Latency vs Throughput

ACID vs BASE Properties in Databases

Read-Through vs Write-Through Cache

Batch Processing vs Stream Processing

Load Balancer vs. API Gateway

API Gateway vs Direct Service Exposure

Proxy vs. Reverse Proxy

API Gateway vs. Reverse Proxy

SQL vs. NoSQL

Primary-Replica vs Peer-to-Peer Replication

Data Compression vs Data Deduplication

Server-Side Caching vs Client-Side Caching

REST vs RPC

Polling vs. Long-Polling vs. WebSockets vs. Webhooks

CDN Usage vs Direct Server Serving

Serverless Architecture vs Traditional Server-based

Stateful vs Stateless Architecture

Hybrid Cloud Storage vs All-Cloud Storage

Token Bucket vs Leaky Bucket

Read Heavy vs Write Heavy System

Quiz

How to Approach a System Design Interview

System Design Interviews - A step by step guide

Functional vs. Non-functional Requirements

What are Back-of-the-Envelope Estimations?

Things to Avoid During System Design Interview

System Design Master Template

Quiz

Designing a URL Shortening Service like TinyURL

Quiz - Designing URL Shortner

Designing Pastebin

Quiz - Designing Pastebin

Designing Instagram

Quiz - Designing Instagram

Designing Dropbox

Quiz - Designing Dropbox

Designing Facebook Messenger

Quiz - Designing Facebook Messenger

Designing Twitter

Quiz - Designing Twitter

Designing Youtube or Netflix

Quiz - Designing Youtube

Designing Typeahead Suggestion

Quiz - Designing Typeahead Suggestion

Designing an API Rate Limiter

Quiz - Designing an API Rate Limiter

Designing Twitter Search

Quiz - Designing Twitter Search

Designing a Web Crawler

Quiz - Designing a Web Crawler

Designing Facebook’s Newsfeed

Quiz - Designing Facebook’s Newsfeed

Designing Yelp or Nearby Friends

Quiz - Designing Yelp or Nearby Friends

Designing Uber backend

Quiz - Designing Uber backend

Designing Ticketmaster

Quiz - Designing Ticketmaster

Dynamo: How to design a key value store?

Dynamo: Introduction

High-Level Architecture

Data Partitioning

Replication

Vector Clocks and Conflicting Data

The Life of Dynamo’s put() & get() Operations

Anti-entropy Through Merkle Trees

Gossip Protocol

Dynamo Characteristics and Criticism

Summary: Dynamo

Quiz: Dynamo

Mock Interview: Dynamo

Designing YouTube Likes Counter (medium)

YouTube Likes Counter

Quiz

Cassandra: How to Design a Wide-column NoSQL Database?

Cassandra: Introduction

High-level Architecture

Replication

Cassandra Consistency Levels

Gossiper

Anatomy of Cassandra's Write Operation

Anatomy of Cassandra's Read Operation

Compaction

Tombstones

Summary: Cassandra

Quiz: Cassandra

Mock Interview: Cassandra

Kafka: How to Design a Distributed Messaging System?

Messaging Systems: Introduction

Kafka: Introduction

High-level Architecture

Kafka: Deep Dive

Consumer Groups

Kafka Workflow

Role of ZooKeeper

Controller Broker

Kafka Delivery Semantics

Kafka Characteristics

Summary: Kafka

Quiz: Kafka

Mock Interview: Kafka

Chubby: How to Design a Distributed Locking Service?

Chubby: Introduction

High-level Architecture

Design Rationale

How Chubby Works

File, Directories, and Handles

Locks, Sequencers, and Lock-delays

Sessions and Events

Master Election and Chubby Events

Caching

Database

Scaling Chubby

Summary: Chubby

Quiz: Chubby

Mock Interview: Chubby

HDFS: How to Design File Storage System?

Hadoop Distributed File System: Introduction

High-level Architecture

Deep Dive

Anatomy of a Read Operation

Anatomy of a Write Operation

Data Integrity & Caching

Fault Tolerance

HDFS High Availability (HA)

HDFS Characteristics

Summary: HDFS

Quiz: HDFS

Mock Interview: HDFS

GFS: How to Design a Distributed File System Storage?

Google File System: Introduction

High-level Architecture

Single Master and Large Chunk Size

Metadata

Master Operations

Anatomy of a Read Operation

Anatomy of a Write Operation

Anatomy of an Append Operation

GFS Consistency Model and Snapshotting

Fault Tolerance, High Availability, and Data Integrity

Garbage Collection

Criticism on GFS

Summary: GFS

Quiz: GFS

Mock Interview: GFS

BigTable: How to Design a Wide Column Storage System?

BigTable: Introduction

BigTable Data Model

System APIs

Partitioning and High-level Architecture

SSTable

GFS and Chubby

Bigtable Components

Working with Tablets

The Life of BigTable's Read & Write Operations

Fault Tolerance and Compaction

BigTable Refinements

BigTable Characteristics

Summary: BigTable

Quiz: BigTable

Mock Interview: BigTable

Designing Reddit (medium)

Design Reddit

Quiz

Designing Notification Service (medium)

Designing a Notification System

Quiz

Design Google Calendar (medium)

Design Google calendar (Medium)

Quiz

Design a Recommendation System (medium)

Design a Recommendation System for Netflix

Quiz

Designing Gmail (medium)

Design Gmail

Quiz

Designing Google News (medium)

Design Google News, a Global News Aggregator System (Medium)

Quiz

Designing Unique ID Generator (medium)

Design Unique ID Generator (Easy)

Quiz

Designing Code Judging System (medium)

Design Code Judging System like LeetCode (Medium)

Quiz

Designing Payment System (hard)

Design Payment System

Quiz

Designing Flash Sale System (hard)

Design a Flash Sale for an E-commerce Site (Hard)

Quiz

Designing Reminder Alert System (hard)

Design a Reminder Alert System

Quiz

System Design Patterns

Introduction: System Design Patterns

1. Bloom Filters

2. Consistent Hashing

3. Quorum

4. Leader and Follower

5. Write-ahead Log

6. Segmented Log

7. High-Water Mark

8. Lease

9. Heartbeat

10. Gossip Protocol

11. Phi Accrual Failure Detection

12. Split Brain

13. Fencing

14. Checksum

15. Vector Clocks

16. CAP Theorem

17. PACELC Theorem

18. Hinted Handoff

19. Read Repair

20. Merkle Trees

Quiz

Introduction to DNS

dns

distributed systems

availability

load balancing

hard

14 min

·Updated Sep 2026·Credit: System Design Fundamentals

When you call a friend, you tap their name in your contacts. You do not type their phone number from memory. The phone looks up the number for you.

The internet works the same way. You type www.example.com, but computers cannot connect to a name. They connect to an IP address, a number like 203.0.113.10.

So something must turn the name into the number, quickly, for billions of names. This lesson explains what that system is, how it is organized, and who does the work of each lookup.

What DNS Is

The Domain Name System (DNS) translates human-readable domain names, like www.designgurus.io, into the IP addresses that computers use to communicate.

DNS works like a phonebook for the internet. You look up a name, and you get back the number you actually need to make the call. People remember names, and computers use the numbers.

An IP address identifies a machine on a network. There are two versions in use.

IPv4 addresses have four numbers separated by dots, like 203.0.113.10.
IPv6 addresses are longer and are written in hexadecimal with colons, like 3fff::10.

DNS answers are small, so most DNS queries use UDP on port 53. DNS switches to TCP when a response is too large for UDP. The TCP vs. UDP lesson explains the two protocols.

A domain name goes into DNS, which looks it up and returns the IP address that the computer needs

Why DNS Matters

Without DNS, people would have to memorize numbers to use the internet. DNS gives four main benefits.

User-friendliness. Domain names are easier to remember and type than IP addresses, which are long strings of digits.
Scalability. DNS is a distributed and hierarchical system, not one giant server. The work and the data are spread across many servers, so DNS can handle the huge and growing number of names on the internet.
Flexibility. A website can change its IP address without affecting users. The DNS records are updated, and people keep reaching the site through the same domain name.
Load balancing. DNS can spread user requests across several servers, which improves the performance and reliability of a website. The DNS load balancing lesson covers how.

Reading a Domain Name

A domain name is a human-readable address made of labels separated by dots, like blog.example.com. Read it from right to left because the most general part comes last.

The root. Every full domain name really ends with a dot, like blog.example.com., although we usually leave the dot out. That final dot stands for the root of DNS.
Top-level domain (TLD). The TLD is the rightmost visible part, like .com in www.example.com.
Second-level domain. The part just left of the TLD, like example. Together, example.com is the domain that an organization registers.
Subdomain. A subdivision of a domain, used to create a separate section of a site. It appears to the left of the main domain. In blog.example.com, blog is a subdomain of example.com.

TLDs come in two main kinds.

Generic TLDs (gTLDs) name a general category, like .com, .org, and .net.
Country-code TLDs (ccTLDs) represent a country or territory, like .us for the United States or .uk for the United Kingdom.

A name that includes every part, down to the root, is called a fully qualified domain name (FQDN), like blog.example.com.

Read from right to left, blog.example.com. has the root, the top-level domain, the second-level domain, and a subdomain

The DNS Hierarchy

DNS can handle so many names because it is split into levels. No single server knows every name. Instead, three kinds of servers each know one level, and each points to the next.

Root servers are at the highest level. They direct queries to the right TLD servers. For example, a root server does not know example.com, but it knows which servers handle .com.

There are 13 root server clusters worldwide, named with the letters A to M, and run by 12 different organizations. Each cluster is made of many physical servers in many countries, for redundancy and reliability.

TLD servers store information about the domain names inside their own TLD. For example, the .com TLD servers do not store the IP address of example.com. They store which name servers are responsible for it, and they point the query there.

Authoritative name servers hold the actual DNS records for a domain, including its IP address. They give the final answer to a DNS query.

Root servers point to TLD servers, TLD servers point to the authoritative servers for a domain, and the authoritative servers hold its records

Only the authoritative server knows the answer. The root and TLD servers only point the resolver to the next level, one step at a time.

Who Runs Each Level

A registry runs the servers for a TLD. For example, one company runs the .com TLD servers.
A registrar is a company where you buy a domain name. When you register example.com, the registrar tells the .com registry which name servers are authoritative for your domain.
The authoritative name servers are often run by a DNS hosting provider, a cloud provider, or the registrar itself.

The set of DNS records that one organization manages, like example.com and its subdomains, is called a zone.

DNS Records

An authoritative server stores its data as DNS records. Each record has a name, a type, a value, and a TTL (time to live). The TTL says for how many seconds other servers may cache the record.

Here are a few records for example.com, in the text format that DNS servers use.

example.com.       3600  IN  A      203.0.113.10
example.com.       3600  IN  AAAA   3fff::10
www.example.com.   3600  IN  CNAME  example.com.
example.com.       3600  IN  MX     10 mail.example.com.
example.com.       86400 IN  NS     ns1.dnshost.net.

The number 3600 is the TTL, which here is one hour. IN means internet. The most common record types are below.

Type	What it stores	Example use
A	An IPv4 address	`example.com` is at `203.0.113.10`
AAAA	An IPv6 address	`example.com` is at `3fff::10`
CNAME	Another name, as an alias	`www.example.com` is the same as `example.com`
MX	The mail server for the domain	Email for `example.com` goes to `mail.example.com`
NS	The authoritative name servers	`example.com` is managed by `ns1.dnshost.net`
TXT	Any text	Proof that you own the domain, or email security settings

When a browser needs the IP address of www.example.com, it asks for an A or AAAA record. If it finds a CNAME instead, the lookup continues with the name that the CNAME points to.

DNS Resolvers

A DNS resolver is any software or server that turns a domain name into an IP address. There are several kinds, and they differ in how much of the work they do.

Stub resolver. This is the small DNS client on your device. It knows one or more DNS servers to ask. It sends the query to one of them, waits for the response, and returns the result to the application, like a web browser. It does not query the root, TLD, and authoritative servers itself.

Your router usually gives your device the DNS server to use. You can also set one by hand, like 8.8.8.8 for Google Public DNS or 1.1.1.1 for Cloudflare.

Recursive resolver. This DNS server does the full lookup for the client. It checks its own cache first. If the answer is not there, it queries the root servers, then the TLD servers, then the authoritative servers, until it finds the answer. Then it caches the result and returns it. Internet providers run recursive resolvers, and Google Public DNS, Cloudflare, and OpenDNS are public examples.

Caching-only resolver. Its main job is to cache the results of DNS queries and reuse them to speed up later lookups. It hosts no DNS zones of its own, so it is not authoritative for any domain. Many home routers work this way. After one device in a home looks up a site, the next device gets the answer from the router almost at once.

Forwarder. This DNS server passes queries it cannot answer to another DNS server upstream, instead of doing the full lookup itself. It may still keep a local cache. Corporate networks often use forwarders, so they can manage, log, or filter DNS in one central place.

Iterative (non-recursive) resolver. It does not look for the answer elsewhere. It returns what it already knows, or a referral, which is the name of another server to ask next. Authoritative servers usually work this way. When asked about a subdomain they do not handle, they reply with a referral to the name server that does.

The stub resolver only asks, the recursive resolver does the whole lookup, the caching-only resolver reuses answers, the forwarder passes queries upstream, and the iterative resolver returns a referral

One Lookup, End to End

Here is how the pieces work together when you visit www.example.com for the first time.

You type the name into your browser.
Your device's stub resolver sends one query to its configured DNS server, like your internet provider's resolver or a public one.
That recursive resolver checks its cache. If the answer is there, it replies at once, and the lookup ends here.
If not, the resolver asks a root server, which points it to the .com TLD servers.
The resolver asks a .com TLD server, which points it to the authoritative servers for example.com.
The resolver asks an authoritative server, which returns the IP address.
The resolver caches the answer for its TTL and returns it to your device.
Your browser connects to that IP address, and the page starts to load.

A lookup goes from the browser to the stub resolver and the recursive resolver, which uses its cache or asks the root, TLD, and authoritative servers before returning the address

Step 3 matters most in practice. Popular names are almost always in the resolver's cache, so most lookups end there, in a few milliseconds. The next lesson explains why.

Key Takeaways

DNS translates human-readable domain names into IP addresses, like a phonebook for the internet.
DNS is user-friendly, scalable because it is distributed and hierarchical, flexible because a site can change its IP address, and it can balance load.
Read a domain name from right to left: root, TLD, second-level domain, then subdomains. TLDs are generic, like .com, or country codes, like .uk.
Root servers point to TLD servers, TLD servers point to authoritative servers, and authoritative servers hold the records. There are 13 root server clusters, each with many servers.
DNS records have types, like A, AAAA, CNAME, MX, NS, and TXT, and each record has a TTL.
A stub resolver only asks. A recursive resolver does the whole lookup. A caching-only resolver reuses answers, a forwarder passes queries upstream, and an iterative resolver returns referrals.

DNS turns a name that people can remember into an address that computers can use, and no single server has to know every name. The next lesson, DNS Resolution Process, looks closely at how queries travel and how caching keeps most lookups fast.

Practice Questions

Try each question first, then open the answer.

1. In the name docs.api.example.org, which part is the TLD, which part is the registered domain, and which parts are subdomains?