When you type an address like tech.atrilit.com into your browser, your machine has no idea where it is. The internet doesn’t understand names: it only understands IP addresses, sequences of numbers like 79.116.92.86. The system that translates one into the other is called DNS (Domain Name System), and without it, browsing would mean memorizing strings of digits for every page. Today we’re going to open the box and see what’s inside.
The problem: machines talk in numbers
Every device on the network has an IP address, its numeric “license plate”. But humans are bad at long strings of digits and good at names. Someone had to build a bridge between the two worlds: a planet-scale distributed database that maps each name to its address. That database is the DNS, and its design is one of the most elegant (and oldest) pieces of internet engineering, predating the web itself.
A hierarchy of names, not a flat map
If DNS were a single central server, it would collapse at the first traffic spike and become a single point of failure. That’s why it’s organized as a hierarchical tree that spreads out responsibility. Think of the domain tech.atrilit.com: read it right to left and you’re walking down the tree.
- The root (the final “.”) is managed by 13 groups of root servers spread around the world using anycast (a technique that makes the same IP answer from many geographically distinct servers).
- The next level is the top-level domains (TLDs), such as
.com,.esor.org, managed by registries like Verisign or the Spanish registry. - Then come the second-level domains (
atrilit.com), and inside them the subdomains (tech).
Each level delegates to the next through an NS record (Name Server), which points to the authoritative servers of the child zone. That way, no single server has to know the whole internet: it just needs to know who to ask at the next step.
Resolution: who asks the question?
When you request tech.atrilit.com, your computer doesn’t talk directly to the root servers. First it queries a recursive resolver, usually your ISP’s or a public one like Cloudflare’s (1.1.1.1) or Google’s (8.8.8.8). This resolver does the legwork for you, following these steps:
- It asks a root server for
tech.atrilit.com. The root doesn’t know it, but says: “ask the.comservers”. - The resolver goes to a
.comserver, which doesn’t know the subdomain either, but hands it the NS records foratrilit.com. - Finally it reaches the authoritative server for
atrilit.com, which does know the answer and returns the A record (IPv4) or AAAA (IPv6) with the requested IP.
This process is called iterative resolution: the resolver works its way down level by level, without any single server having to shoulder the whole workload.
Record types: more than just addresses
DNS doesn’t only store addresses. A domain is a set of resource records (RRs), each with a type, a TTL (time to live) and some data. The most common ones:
- A / AAAA: a host’s IPv4 / IPv6 address.
- CNAME: an alias pointing to another canonical name (handy for making
wwwpoint to the root domain). - MX (Mail Exchange): the servers that receive the domain’s email, with a priority number.
- TXT: free text, used for verifications, email authentication (SPF, DKIM) or the
_acme-challengeprotocol of Let’s Encrypt. - NS: the zone’s authoritative servers.
- SOA (Start of Authority): the zone’s header with metadata such as the minimum TTL or the administrator’s email.
The cache: why everything is so fast
Making three server hops for every visit would be slow. That’s why DNS uses caching at every level: the resolver, the operating system and even the browser store answers for as long as the TTL (time to live) indicates, measured in seconds. That’s why changing a domain’s A record takes time to “propagate”: it’s not that the change travels slowly, it’s that intermediate caches keep serving the old value until their TTL expires. If a record has a TTL of 3600 seconds, users may see the previous value for up to an hour.
DNS and security: the Achilles heel
DNS was designed in the 1980s with no encryption or origin verification, and that has consequences. Three important fronts:
- DNSSEC: adds cryptographic signatures to records (using key pairs and a chain of trust rooted at the root) so an attacker can’t poison the cache with fake answers. It verifies integrity, though it doesn’t encrypt the content.
- DoH and DoT (DNS over HTTPS / TLS): encrypt the query so a network observer can’t see which domains you visit, nor can an intermediary tamper with the answer. DoH runs on port 443 and blends in with normal web traffic; DoT uses 853 with TLS.
- Amplification DDoS: because UDP queries are small but responses can be much larger, an attacker can send queries with the victim’s IP as the source (spoofing) and get the DNS server to fire a flood of amplified traffic at them. It’s one of the most used attack vectors on the internet.
What you should remember
DNS is the internet’s “phone book”, but it’s much more than a simple dictionary: it’s a distributed, hierarchical, cached system that had to be engineered to survive the scale of the global network. Understanding how a name becomes an address, what role resolvers and authoritative servers play, or why TTL makes changes take time, helps you diagnose everything from an email that never arrives to a site that’s slow to update. And with DNSSEC, DoH and mitigation techniques, it’s also a field where security is still fought over every day.
