When You Type a Domain Name, Your Computer Asks Four Servers Before Loading the Page
When you type a domain name into a browser and press Enter, the browser does not know where the server is. No part of your computer knows where the server is until a chain of queries has been answered. This chain is the Domain Name System, and it translates a human-readable name into a machine-readable IP address every time you navigate to a new website.
The Domain Name System was designed in 1983 by Paul Mockapetris, then a researcher at USC/Information Sciences Institute. His specifications, RFC 882 and RFC 883, published in November 1983, described a distributed, hierarchical database that could map names to addresses at global scale without any single directory holding all the information. Before DNS, a single text file called HOSTS. TXT was manually maintained by Elizabeth Feinler and her team at the Network Information Center at the Stanford Research Institute and distributed to every computer on the ARPANET. By 1983, the ARPANET had grown to hundreds of connected hosts, and the manual update and distribution process for HOSTS. TXT had become untenable. Mockapetris's distributed design was adopted and remains the foundation of the internet's naming infrastructure, essentially unchanged in its core architecture, more than four decades later.
Before DNS: The HOSTS. TXT Era
The HOSTS. TXT file was more than an administrative artifact. It represented a fundamentally different model of internet naming: centralized, authoritative, and updated by request. Organizations that needed a new hostname submitted a request to the NIC, Feinler's team would update the master file, and all computers on the network would download the new version. The file contained hundreds of entries by the early 1980s and was updated several times per week.
The limitations were architectural, not administrative. Any centralized file that had to be distributed to all nodes on a growing network would eventually hit physical limits: distribution latency, update frequency, and file size. The solution Mockapetris designed was delegation: break the namespace into zones, make each zone's operator responsible for maintaining their own data, and connect the zones through a hierarchical referral system. No single organization would ever need to know all hostnames. Each would know only their own domain.
RFC 882 and 883 were later revised into RFC 1034 and RFC 1035, published in November 1987, which remain the core DNS standards in use today, amended and extended but not replaced.
How the Resolution Chain Works
When your browser needs to resolve a domain, it first checks local caches: the browser's own cache, then the operating system's DNS resolver cache. If the record has been looked up recently and has not expired, the cached IP address is used immediately without any external query.
If there is no cached record, the OS sends a query to a recursive resolver, typically operated by your Internet Service Provider or a public resolver like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. The recursive resolver works through the hierarchy to find the answer.
The resolver starts at a root nameserver. There are 13 root nameserver addresses in the DNS system, identified by the letters A through M. The number 13 is a technical limit from DNS's design: a UDP packet carrying a DNS response could not exceed 512 bytes in the original specification, and 13 addresses was the maximum that fit. Each of the 13 addresses is served by an anycast cluster rather than a single machine. The A root server, operated by Verisign, is served by more than 200 physical machines worldwide. The root server does not know the IP address, but it knows which server is authoritative for.com domains.
The resolver then queries the.com TLD nameserver, also operated by Verisign. The TLD nameserver knows which nameserver the domain owner has designated as authoritative. Finally, the resolver queries the authoritative nameserver, which returns the actual IP address. This entire process typically takes between 20 and 100 milliseconds when cache misses occur.
What DNS Records Actually Are
DNS is not just a name-to-IP mapping. The system supports multiple record types that serve different purposes. A records map a domain to an IPv4 address. AAAA records map to an IPv6 address. MX records specify the mail servers that handle email for a domain. CNAME records are aliases that point one name to another. TXT records store text data, commonly used for SPF records that define which servers are authorized to send email for a domain, DKIM cryptographic keys for email signing, and domain ownership verification strings for services like Google Search Console. NS records identify which nameservers are authoritative for a domain. SOA records specify the start-of-authority parameters including the primary nameserver and zone serial number.
When a domain's email stops working, the issue is usually in an MX record. When a newly registered domain does not resolve, the NS records at the registrar may not have propagated to the root. When a website migrates to a new hosting provider, the A record needs updating. Each of these problems requires a DNS lookup to diagnose and verify.
DNS Security: The Kaminsky Attack and DNSSEC
DNS was designed before internet security was a significant concern, and its original design has significant vulnerabilities. The most consequential was demonstrated publicly by security researcher Dan Kaminsky in August 2008. Kaminsky showed that an attacker could exploit a flaw in DNS cache poisoning by sending forged responses to recursive resolvers at high speed, guessing the 16-bit transaction ID used to match responses to queries. A successful attack could redirect a domain's traffic to an attacker-controlled server, a process called cache poisoning. The attack required only a few thousand guesses on average and could be executed in seconds.
The disclosure was coordinated with major DNS software vendors and ISPs before publication, allowing patches to randomize source ports in addition to transaction IDs, dramatically increasing the search space an attacker had to cover. The episode demonstrated that DNS security could not be assumed and accelerated deployment of DNSSEC, the DNS Security Extensions.
DNSSEC, formalized in RFC 4033 through 4035 in March 2005, adds cryptographic signatures to DNS records, allowing resolvers to verify that records have not been tampered with in transit. A DNSSEC-enabled zone chain provides mathematical proof from the root nameservers down to the authoritative records that the responses are authentic. Adoption has been gradual; as of 2024, approximately 30 percent of domain registrations are signed with DNSSEC, and a larger but still minority share of resolvers validate signatures.
DNS over HTTPS and Modern Privacy
Traditional DNS queries are sent in plaintext over UDP, meaning any network observer including your ISP can see every domain you resolve. DNS over HTTPS (DoH), standardized in RFC 8484 in October 2018, encrypts DNS queries within HTTPS connections, making them indistinguishable to network observers from ordinary web traffic. Firefox enabled DoH by default in the United States in 2020. Chrome followed with a similar implementation it calls Secure DNS.
Conclusion
DoH moves the DNS query visibility from ISPs to the recursive resolver operator. A user who switches from their ISP's resolver to Cloudflare's 1.1.1.1 or Google's 8.8.8.8 over DoH is trading ISP visibility for resolver operator visibility.
ToolHQ's DNS lookup tool queries any domain's DNS records in real time, bypassing local caches to show what the authoritative nameservers are currently returning. Enter a domain and select the record type to see the live state of a domain's DNS configuration, which is the diagnostic step for any DNS-related issue from email delivery failures to propagation delays after a record change.
Frequently Asked Questions
What does a DNS lookup show?
A DNS lookup returns the current DNS records for a domain, including A records (IP address), MX records (mail servers), TXT records (SPF, DKIM), NS records (nameservers), and CNAME records (aliases).
Why is my DNS change not propagating?
DNS records have a TTL (Time to Live) that controls how long they are cached. If you recently changed a record, it may take minutes to hours for the old cached record to expire worldwide, depending on the TTL set.
What is the difference between A and AAAA records?
An A record maps a domain to an IPv4 address (e.g., 93.184.216.34). An AAAA record maps it to an IPv6 address (e.g., 2606:2800:220:1:248:1893:25c8:1946). Modern infrastructure often has both.
How long does DNS propagation take?
DNS propagation typically completes within a few minutes to 48 hours, depending on the TTL of the old record and your ISP's caching behavior. Lowering the TTL before a change can significantly speed up propagation.