The Barid & DNS story

While surfing the internet, we rarely think about what happens behind the scenes when we type a website name like example.com. How does your computer find the right server among billions of devices connected worldwide? The answer is within a system called the Domain Name System (DNS)—the internet’s phonebook, translating human-friendly names into machine-readable IP addresses.

But did you know that a similar challenge was solved over 1,300 years ago in the early Islamic Caliphate? The solution then was a vast, efficient postal and communication network called the Barid.

Imagine you want to send a letter to a friend in a huge empire without street addresses or GPS. Simply knowing their name is not enough. You must know exactly where they live to get the letter delivered and that's exactly what DNS solves in the digital realm.

During Caliph Omar ibn Al-Khattab’s rule (634–644 CE), the Caliphate stretched across a vast territory, requiring efficient communication between governors, military commanders, and the central government.

To tackle this, the Caliphate created the Barid—a state-run postal and intelligence relay network that:

• Used relay stations positioned along major routes to transfer messages.

• Ensured messages were addressed with clear routing information, including administrative districts.

• Allowed couriers to hand off messages from one station to the next, ensuring fast and reliable delivery.

• Enabled the Caliphate to maintain control and respond rapidly to events across distant lands.

The Barid’s relay stations are a great analogy for DNS servers, which form a distributed system that translates domain names into IP addresses:

---

User story

1. User requests a website: Typing example.com is like writing a letter with a name but no exact address.

2. Local DNS resolver queries root servers: The local resolver acts like the first relay station, asking where to go next.

3. Root directs to Top-Level Domain (TLD) server: Like directing the message to a province or district.

4. TLD server directs to authoritative DNS server: The authoritative server knows the exact IP address.

5. IP address returned and website loaded: The computer now knows the exact ‘location’ to reach.

In more technical details:

• When requesting website , the process does start by checking the local DNS cache on your device (browser, operating system, or application). This cache stores recently resolved domain-to-IP mappings to speed up subsequent requests.

• Then if not found, It goes to Recursive Resolver (e.g., 8.8.8.8, if configured) to use Google’s public DNS resolver as its recursive resolver & checks its own cache to see if it has recently resolved the domain.

  • If the answer is cached, the resolver returns the IP address to the client, and the process ends.

• Then if not found, the resolver begins the process of querying the DNS hierarchy, the resolver sends the query to one of the 13 global root name-servers, which are the top of the DNS hierarchy.

• Root servers don’t know the IP address for "www.example.com," but they know the addresses of TLD name-servers (e.g., for .com, .org).

• The root server responds with a referral to the appropriate Top-Level Domain (TLD) name-server for the domain’s TLD (e.g., .com).

• The recursive resolver contacts the TLD nameserver (e.g., the .com nameserver).

• The TLD nameserver doesn’t have the final IP address but knows the authoritative nameserver responsible for the specific domain (e.g., example.com).

• It responds with the address of the authoritative nameserver for "example.com."

• The recursive resolver queries the authoritative nameserver, which holds the DNS records for the domain.

• This server returns the specific DNS record requested, such as an A record (IPv4 address) or AAAA record (IPv6 address) for "www.example.com."

  • For example, it might return 93.184.216.34 as the IP address.

• The recursive resolver sends the IP address back to the client (your device).

• The resolver caches the result for future queries, based on the TTL (Time to Live) value in the DNS record, to reduce future lookup times.

  • The operating system or browser may also cache the result locally.

• With the IP address in hand, the browser or application initiates a connection to the target server (e.g., the web server at 93.184.216.34) to load the website or perform the requested action.

It is worthy to note that caching occurs at the browser, operating system, and recursive resolver levels to optimize performance. The TTL in DNS records determines how long these caches remain valid.

But there's an important question. Can't the top 13 root name-servers crash? I mean there are billions of requests by hour. Maybe someone can make a DDOS attack so it could crash right?

Well, That's a valid concern.

• The "13 root name-servers" refer to 13 logical entities, identified by letters A through M (e.g., a.root-servers.net). However, these are not single machines but rather clusters of servers distributed globally using anycast routing.

• Each root server is operated by organizations like Verisign, ICANN, or universities, and they maintain multiple physical servers (hundreds in total) across the world. Anycast allows a single IP address (e.g., 198.41.0.4 for a.root-servers.net) to route traffic to the nearest server in the cluster, distributing the load geographically.

• Also, Most DNS queries never reach the root servers because of caching at multiple levels.

• Their responses are small (often under 512 bytes), enabling high throughput even under heavy load.

But However, There have been attempts to target root nameservers with DDoS attacks, but none have fully disrupted the DNS system:

• 2002 Attack: A significant DDoS attack targeted all 13 root servers, sending massive traffic. Nine servers remained operational, and the internet experienced minimal disruption due to caching and redundancy ICANN: 2002 DDoS Attack Report.

• 2007 Attack: Another attack hit several root servers, but the system’s distributed nature and quick mitigation prevented widespread impact.

• 2015 Attack: A large-scale attack targeted root servers with spoofed queries, but operators mitigated it by filtering malicious traffic Cloudflare: DNS Security.

From the vast desert roads of the early Islamic Caliphate to the digital highways of today’s internet, the challenge of efficient communication and precise routing has always been essential. The ancient Barid system showcased early ingenuity in solving the problem of “where to send the message,” much like the Domain Name System solves the problem of “where to send your data” in the modern world.

Understanding DNS not only helps us appreciate the complexity behind a simple web search but also highlights the timeless nature of communication challenges—and the clever solutions humans devise to overcome them.