What is DNS? The Domain Name System Explained

The Domain Name System (DNS) is a fundamental part of how the internet works, but it's often overlooked by everyday users. DNS acts as the internet's address book, translating human-friendly domain names like dnscale.eu into the numerical IP addresses that computers use to identify each other on the network.

Why Do We Need DNS?

Every device connected to the internet has a unique IP address. While computers communicate using these addresses, remembering a string of numbers for every website would be impossible for most people. DNS solves this problem by allowing us to use easy-to-remember domain names instead of IP addresses.

How Does DNS Work?

When you enter a website address into your browser, DNS gets to work behind the scenes:

1. DNS Query Initiation: Your device asks a DNS resolver for the IP address associated with the domain name.
2. Recursive Lookup: If the resolver doesn't already know the answer, it queries a series of DNS servers, starting with the root server, then the top-level domain (TLD) server (like .com), and finally the authoritative name server for the domain.
3. Response: The resolver returns the correct IP address to your device, which then connects to the website.

For warm caches this often happens in milliseconds; cold lookups take more network round trips but are still fast enough that users rarely notice DNS as a separate step.

The full resolution walkthrough

A cold lookup — one where no cache holds the answer — makes multiple round trips:

1. Client → Stub resolver. The browser hands the name to the operating system's stub resolver (part of the standard C library on Unix, or the DNS Client service on Windows).
2. Stub → Recursive resolver. The stub sends a UDP packet to the configured recursive resolver (e.g., 8.8.8.8 for Google Public DNS, or the ISP's resolver).
3. Recursive → Root. The recursive resolver asks a root nameserver: "Who handles .com?" There are 13 root server identities (A through M), each an anycast cluster distributed worldwide.
4. Root → Recursive. The root returns a referral: the NS records and glue A/AAAA records for the .com TLD nameservers.
5. Recursive → TLD. The resolver now asks a .com TLD nameserver: "Who handles example.com?"
6. TLD → Recursive. The TLD returns the authoritative nameservers for example.com.
7. Recursive → Authoritative. The resolver queries one of the authoritative nameservers for the specific record (e.g., the A record for www.example.com).
8. Authoritative → Recursive → Stub → Client. The IP address travels back up the chain.

Every hop adds latency, but caching short-circuits most of them for subsequent queries. A warm-cache lookup returns in single-digit milliseconds because only hop 2 is needed.

Types of DNS Servers

Recursive resolvers

These servers receive DNS queries from client machines and are responsible for tracking down the correct IP address. They walk the hierarchy on the client's behalf and cache results. Most users get their recursive resolver from their ISP; alternatives include public resolvers like Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad9 (9.9.9.9).

Root nameservers

The first step in resolving a name. There are 13 logical root server identities (A through M), each operated by a different organisation (Verisign, ICANN, USC-ISI, RIPE NCC, etc.) and each deployed as a globally-distributed anycast cluster. They don't store zone data for individual domains — they only serve the root zone, pointing to TLD nameservers.

TLD nameservers

Responsible for storing information about domains with specific extensions, like .com, .net, .eu, .org. When the root returns a referral, the resolver queries the appropriate TLD nameserver to find which authoritative nameservers handle a specific second-level domain.

Authoritative nameservers

These servers contain the actual DNS records for a zone — A, AAAA, MX, CNAME, TXT, and everything else. They are the source of truth. When you update a DNS record, the change is made at the authoritative nameserver; recursive resolvers learn about it on their next lookup after the cached TTL expires.

The DNS Hierarchy

DNS is a tree. Understanding its structure helps explain why resolution works the way it does.

. (root)
├── .com
│   ├── example.com
│   │   ├── www.example.com
│   │   └── mail.example.com
│   └── another.com
├── .eu
│   ├── dnscale.eu
│   └── europa.eu
├── .org
└── .net

How delegation works

Each level of the tree delegates authority to the level below it:

• The root zone delegates .com to the .com TLD nameservers (operated by Verisign).
• The .com TLD delegates example.com to the authoritative nameservers specified in the domain's NS records.
• The example.com zone can further delegate subdomain.example.com to a different set of nameservers (or keep it in the same zone).

This delegation chain is verified during every DNSSEC validation, which is why the hierarchy matters beyond just resolution — it's also the trust model.

Delegation records

When a parent zone delegates a child zone, it stores two types of records:

• NS records — list the hostnames of the child's nameservers (e.g., ns1.dnscale.eu, ns2.dnscale.eu).
• Glue records — A/AAAA records for those nameserver hostnames. These are necessary when the nameserver hostname is inside the child zone itself (e.g., ns1.example.com for the example.com zone). Without glue, a resolver would hit a circular dependency: need to resolve ns1.example.com to ask the nameserver that serves example.com.

For further reading on how zones are structured, see what is a DNS zone.

DNS Caching and TTL

Caching is what makes DNS fast and scalable. Without it, every single web request would require a multi-hop lookup across the internet — the system would collapse under the load.

For a dedicated beginner walkthrough of browser, OS, resolver, and negative cache layers, see DNS Cache Explained.

Where caching happens

When you change a DNS record, the old value lives in every one of these caches until the TTL expires. This is what people mean by "DNS propagation" — it's not a push, it's a cache-expiry-driven pull.

How TTL works

The Time To Live (TTL) on a DNS record tells every cache: "you can keep this answer for up to X seconds before you must ask the authoritative server again."

• Low TTL (30–300s): Records change often, or you expect a change. Lower TTL means faster propagation (the stale-data window is smaller) but more query load on the authoritative server.
• High TTL (3600–86400s): Records are stable. Lower query load, higher cache hit rates, but changes take up to the TTL value to propagate.

TTLs for NS records (delegation) are set at the registrar and are typically 86400s (24h). This is why nameserver changes can take a day to propagate — you can't lower the NS TTL from your DNS provider's dashboard; you do it at the registrar.

Negative caching

When a resolver queries for a name that doesn't exist (NXDOMAIN), it also caches the absence of that name. The duration is governed by the SOA record's MINIMUM field — typically 300–3600 seconds. This prevents attackers from flooding resolvers with requests for non-existent names, but it also means a newly-created subdomain may be temporarily invisible.

DNS and Website Performance

A fast and reliable DNS service is crucial for website performance. Slow DNS lookups can delay page loads, while DNS outages can make websites inaccessible. DNScale is designed to provide secure, high-performance authoritative DNS so resolvers can reach your services consistently.

Why Choose DNScale for DNS?

• Speed: Optimized infrastructure for lightning-fast DNS resolution.
• Reliability: Redundant systems and global coverage to keep your domains online.
• Security: Advanced protection against DNS-based threats.
• Scalability: Easily manage DNS for a single domain or thousands, all from one platform.

Conclusion

DNS is the backbone of the internet, making it possible for users to access websites and services with simple, memorable names. With DNScale, you get a DNS solution that's fast, secure, and built for the demands of modern web applications.