The little known glue that keeps the internet working

Key Takeaways

• DNS is crucial for internet connections, turning domains into numeric IP addresses for data routing.
• Recursive resolvers on networks help locate domain information by consulting root and TLD servers.
• Glue records prevent circular dependencies in DNS queries, aiding scalability and system stability.

The directory known as DNS (Domain Name System) is a complicated system that we’re all using right now, every day, each time we browse the internet. It’s part of the backbone of how the internet functions, but it is old, sometimes convoluted, and has some flaws. You may be familiar with how DNS works, but have you heard of glue records, or how they’ve been essential to sustaining a system since the 1980’s, serving up millions of requests a day? We’ll dig into how DNS works, and why it sometimes it needs a little help to avoid going in circles.

What is DNS?

DNS turns names into addresses

Fundamentally, all connections on the internet are from one IP address (like 8.8.8.8) to another. Whether it’s Netflix, a file download, or endless cat videos, all traffic moves from a source IP to a destination IP and DNS is responsible for that.

DNS stands for Domain Name System, and is a global network of servers responsible for doing one thing. It turns domains, e.g. xda-developers.com, into numeric IP addresses, which can then be routed from your network, to your Internet Service Provider (ISP), across the internet, and to the destination server hosting the content.

DNS is part of the functional backbone of the internet, allowing users to find a website by simply typing in its memorable domain name, instead of needing to memorize a numeric IP. It’s also far easier to maintain a domain in the long term, like Google.com, than it is to hold onto a specific IP address.

How does DNS work?

Your computer first checks its cache

When you request a domain, like xda-developers.com, your computer first checks if it’s seen that domain before. Domains don’t change often, so your computer will cache them for a period of time, saving a copy locally until it expires. If your computer does not find xda-developers.com saved locally, it sends a request to a resolver, asking for the IP where you can reach xda-developers.com.

A resolver is any device that can resolve DNS queries, which simply means to convert a name to an IP address.

A recursive resolver runs on your network

Each network you join has configured default DNS resolvers. This might be 192.16.0.1 (or similar internal range) if you’re using an ISP provided router, or a common public DNS server like 8.8.8.8 or 1.1.1.1 for Google or Cloudflare’s DNS servers. This is an instruction on which server to talk to for resolving DNS queries on that network. This resolver will have its own cache, and if it fails to find your domain there, it will use the wider DNS system to find out the information on behalf of your computer. If a resolver is capable of reaching out to the wider internet on its own to locate a domain, it’s known as a recursive resolver.

On most networks, your DNS resolver runs locally on your ISP-provided router. You’ll never even notice it’s there, but you can see it if you manually make a DNS request using dig.

The DNS hierarchy kicks into action

If your local resolver does not have a name in its cache, it tries to resolve it recursively. This is where DNS more widely kicks in. Your recursive resolver first contacts one of the DNS root servers. These servers are fixed with static addresses and are essential for the function of the whole internet. There are 13 of them in total, and these root servers are heavily guarded and run by a variety of universities and non-profits.

Your resolver contacts these root nameservers with the domain it needs. These nameservers then point your resolver to the TLD nameserver (top-level domain nameserver.) A top level domain is the final part of your URL, e.g. the .com in xda-developers.com. Once the top-level nameserver has been located, it is then queried for the authoritative nameserver. This is the server where your actual domain and its associated DNS records are stored.

You can think of the authoritative server as the source-of-truth – the only server on the internet with all the correct answers, all the time, about where a domain is located.

DNS is a sequence of requests

This process really forms a sequence of hierarchical requests, starting at the root servers, which effectively cover the whole internet, followed by the TLD servers, and then your authoritative nameserver. A nameserver is considered authoritative when it can actually answer a DNS query, not provide cached answers from another server. You can think of the authoritative server as the source-of-truth – the only server on the internet with all the correct answers, all the time, about where a domain is located.

If you’d like to see this whole system in action, try the below command on a Mac or Linux machine.

dig google.com +trace +nodnssec 

This will show the DNS root servers first, followed by the top-level-domain servers for the .com TLD, then finally followed by the locations of the authoritative nameservers for Google.com.

If you’re sharp eyed, you might notice that the authoritative nameservers for Google.com aren’t IP addresses, instead they’re other addresses like ns1.google.com, ns2.google.com. If you’re really sharp eyed, you might spot why this causes us a bit of a problem.

Glue records help DNS scale

Little known, but essential to make the whole system manageable at scale

One of the little known quirks of the DNS is known as a glue record. Glue records allow non-authoritative nameservers to respond with a DNS name, without causing a circular dependency. For example, when a .com TLD server replies to a query about Google.com, it doesn’t need to reply with an IP address. Instead, it can reply with a domain, like ns1.google.com, or ns2.google.com.

You might have spotted the problem here. If I’m asking for a DNS resolution for Google.com, but the nameserver I’ve been told to ask is ns1.google.com, then how do I find that nameserver? Both addresses are likely hosted on the same authoritative server – creating a circular dependency, preventing the original query for Google.com from ever being resolved and could break the whole system.

Glue records are provided at the TLD level (for this example), hinting to your resolver where to find the resolver for the next step in the resolution chain. These need to be manually added when using a subdomain for a nameserver, and are considered a special type of DNS A-Record.

We can see glue records in action by adding a flag to the command we used earlier to manually request DNS records for Google.com by running:

dig google.com +trace +nodnssec +additional

Why use a subdomain?

You may wonder why organizations want to provide a subdomain, like ns1.google.com, instead of an IP address in order to locate their authoritative server? Simply put, it helps scalability and resilience. Using a subdomain leaves the company in greater control of things like load balancing, redundancy, and management. It’s also arguably more professional and helps support their brand, so vanity is a factor.

DNS and glue records hold the internet together

DNS can be complicated, but it’s absolutely essential to how the internet runs. It’s been with us since the 80s, hasn’t changed much since, and will be here far into the future. Even IPv6 relies on DNS – so it’ll outlive even that endless migration. If you’re interested in learning more about how the basics of the internet work, maybe check out what network settings mean, or delve into configuring your own router.