Mapping Domain Names to IP Addresses Through Hierarchical DNS Resolvers and Caching

Most internet users assume typing a URL creates a direct, physical-like connection to a website's server. The reality is much more fragile: every web request begins with a blind query to a massive, distributed phonebook called the Domain Name System (DNS). If you understand how this phonebook works, you can speed up your daily browsing by choosing better resolvers, bypass local network restrictions, and protect yourself from sophisticated traffic hijacking.

The core function of DNS is translation. Computers route traffic using numerical IP addresses, but humans use readable domain names. When you type a web address, your device must first ask a DNS resolver to find the corresponding IP address before any actual website data can load.

This lookup process is not a single database query. It is a strict, hierarchical delegation system. The resolver first queries one of the internet's logical root servers, which do not know the final IP address, but know which servers handle the Top-Level Domain (TLD), such as ".com" or ".org".

The TLD server then points the resolver to the authoritative nameserver for the specific domain. This final server holds the actual IP address record. This multi-step journey happens in milliseconds, but repeating it for every single image, script, and page load would cripple global internet infrastructure.

To solve this latency problem, the internet relies heavily on DNS caching. Caching temporarily stores the results of a DNS lookup closer to the user—often on the user's own operating system, their home router, or their Internet Service Provider's (ISP) local servers.[4]

When a resolver receives a query, it first checks its local cache. If the IP address is already stored and hasn't expired, the resolver returns it immediately without traversing the global hierarchy. This is why visiting a website for the second time is noticeably faster than the first.[4]

The duration a record stays in the cache is dictated by its Time to Live (TTL) value, set by the domain owner. A short TTL ensures that if a website moves to a new server, global traffic routes update quickly. A long TTL reduces lookup latency but means changes take longer to propagate globally.[4]

However, this caching mechanism introduces a severe security vulnerability. Historically, DNS was designed for a high-trust environment. When a resolver asked for an IP address, it blindly accepted the first response it received. Malicious actors exploited this by flooding resolvers with fake IP addresses—a technique known as cache poisoning or DNS spoofing.[1][4]

If an attacker successfully poisons an ISP's cache, every user on that network trying to reach a legitimate banking or email site is silently redirected to a fraudulent server. Because the URL in the browser remains correct, the user has almost no visual indication that they have been hijacked.[4]

To close this vulnerability, the Internet Engineering Task Force (IETF) developed DNSSEC (Domain Name System Security Extensions). DNSSEC does not encrypt the DNS queries, but it adds cryptographic signatures to the DNS records themselves.[1]

When DNSSEC is enabled, the authoritative nameserver signs its IP address records using a private cryptographic key. It publishes the corresponding public key in a special DNSKEY record, alongside the signature in an RRSIG record.[2]

When a validating resolver receives the IP address, it uses the public key to verify the signature. If the signature matches, the resolver knows the IP address is authentic and has not been tampered with in transit. If the signature fails or is missing when one is expected, the resolver blocks the connection, protecting the user from the poisoned cache.[1][2]

This verification relies on a "chain of trust." The public key of the domain is signed by the TLD server, and the TLD server's key is signed by the root server. This unbroken cryptographic chain ensures that a domain's security parameters can be verified all the way up to the internet's root zone.[1]

Implementing DNSSEC requires careful algorithm selection to balance security and performance. Modern deployments are shifting away from older cryptographic standards toward more robust algorithms like ECDSA and EdDSA, which offer strong security with smaller signature sizes, reducing the bandwidth required for DNS responses.[3]

Despite its power, DNSSEC is not a complete solution. Our analysis of the protocol's architecture reveals a persistent "last mile" vulnerability. While DNSSEC secures the chain from the root server down to the validating resolver, the final connection between that resolver and the user's personal device is often unauthenticated.[5]

If an attacker compromises the local network—such as a public Wi-Fi hotspot—they can still intercept and alter the final, post-validation DNS response sent to the user's laptop or phone. To fully secure the pipeline, DNSSEC must be paired with protocols like DNS over HTTPS (DoH) or DNS over TLS (DoT), which encrypt the last-mile connection.[5]