On the afternoon of October 21, 2016, the east coast of the United States lost access to most of the internet.
Twitter went down. Spotify went down. Reddit, the New York Times, Airbnb, Amazon, Netflix, PayPal, and dozens of other major platforms became unreachable. The outage started on the east coast and spread. By midday it was affecting users in Europe. Three waves of disruption rolled through the day, each one returning services to normal and then knocking them out again.
The attack did not target any of these companies. It targeted none of their servers, none of their code, none of their databases. It targeted a company most of their users had never heard of: a DNS provider called Dyn, which had offices in Manchester, New Hampshire. The attackers flooded Dyn's infrastructure with traffic from a botnet built from compromised home routers, security cameras, and digital video recorders running default passwords. When Dyn could not respond to queries, the entire eastern seaboard of the internet stopped working.
DNS is the system that translates names into numbers. When you type twitter.com into a browser, before a single byte of Twitter's actual content is requested, your device has to ask a distributed network of servers where twitter.com lives. That network is DNS. Without it, the numerical addresses that identify every server on the internet are inaccessible to the humans who need to reach them.
DNS is also, in the architecture of the internet, one of the most interesting systems ever built. It predates the web. It was designed in the early 1980s by a handful of engineers solving a specific scaling problem. It has been extended and patched and argued over for forty years. It runs on every device connected to the internet. And most of the people who use it every day, including most of the engineers who build software that depends on it, have only the vaguest notion of how it works.
Before DNS existed
To understand why DNS was invented, you have to understand what came before it.
In the early days of ARPANET, the predecessor to the internet, the problem of translating names to addresses was solved with a single file. A computer at the Stanford Research Institute maintained a text file called HOSTS.TXT. Every computer on the network that wanted to communicate by name rather than by number had to periodically download a copy of this file. The file listed every host on the network, its name, and its address.
In 1971 this was manageable. ARPANET had a few dozen nodes. The hosts file was a few kilobytes. Networks were updated infrequently. The system worked.
By the late 1970s it was becoming a problem. The network was growing. New hosts were being added regularly. The Stanford Research Institute was updating the file multiple times a week, and operators at other institutions had to coordinate changes with it to avoid conflicts. Two organizations could not independently choose the same hostname. The traffic to download the file was growing. The file itself was growing. The single point of coordination that made the system function was becoming a bottleneck.
In 1983, a computer scientist named Paul Mockapetris, working at USC's Information Sciences Institute, was asked to design a replacement. The result was published as RFC 882 and RFC 883 in November of that year, later superseded by RFC 1034 and RFC 1035, which remain the foundational specifications of DNS to this day.
The key insight Mockapetris brought to the problem was delegation. Instead of a single authoritative file maintained by a single institution, the namespace would be distributed. Responsibility for different parts of the namespace would be delegated to different organizations, each responsible for maintaining the records in their portion. No central authority would need to know about every name. The system would scale by distributing both the data and the responsibility for that data.
This is the design that runs the internet in 2026. The details have been extended enormously, but the core architecture of a hierarchical, delegated namespace has not changed in forty years.
The hierarchy
DNS is organized as an inverted tree. At the root is a single entity: the root zone. Below the root are the top-level domains: .com, .org, .net, .io, .ke, .uk, and hundreds of others. Below each top-level domain are second-level domains: google.com, bbc.co.uk, safaricom.co.ke. Below those can be any number of further subdomains.
Every name in DNS is a path through this tree, read from right to left. The name www.google.com is really www.google.com. (note the trailing dot), where the trailing dot represents the root, .com is a top-level domain, google is a second-level domain registered within .com, and www is a subdomain within google's domain.
The reason this matters is that the hierarchy maps directly to delegation of authority. ICANN, the organization that manages the root zone, does not know anything about what records exist under google.com. It only knows which nameservers are authoritative for .com. The .com registry, operated by Verisign, does not know anything about google.com's internal structure. It only knows which nameservers Google has designated as authoritative for google.com. Google's nameservers know everything about google.com and its subdomains.
When you ask for the IP address of www.google.com, the system has to walk this hierarchy to find the answer.
What actually happens when you type a name
Most descriptions of DNS stop at "your computer asks a DNS server and gets an IP address back." That is true but it leaves out the mechanism that makes it work at scale. The full process involves more steps and more servers than most people realize.
Your device is configured with the address of a recursive resolver, usually provided by your ISP or by a public service like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). When you type www.google.com, your device asks this recursive resolver for the answer.
The recursive resolver is the entity that does the actual work of walking the DNS hierarchy. It does not have authoritative information about google.com. What it has is a list of root server addresses, which are hardcoded into DNS resolver software and occasionally updated.
If the recursive resolver does not have a cached answer for www.google.com (which we will come back to), it starts at the top of the hierarchy. It sends a query to one of the root nameservers: "what is the address of www.google.com?" The root nameserver does not know the specific answer. It knows where to find .com records. It responds with a referral: "I don't know, but here are the addresses of the nameservers for .com."
The recursive resolver queries one of the .com nameservers: "what is the address of www.google.com?" The .com nameserver does not know the specific answer either. It knows where to find google.com records. It responds with a referral: "I don't know, but here are the addresses of Google's authoritative nameservers."
The recursive resolver queries one of Google's authoritative nameservers: "what is the address of www.google.com?" This server is authoritative for google.com. It knows the answer. It responds with the IP address and a number called the TTL, time to live, which tells the resolver how long it is allowed to cache this answer before it must ask again.
The recursive resolver returns the answer to your device, which connects to the IP address and loads the page.
This entire process, from query to answer, typically takes between 20 and 120 milliseconds the first time for a name that is not cached anywhere. Subsequent queries for the same name, while the TTL has not expired, return the cached answer in less than a millisecond.
The root servers are one of the most critical pieces of infrastructure on the internet. There are thirteen of them, identified by letters A through M. Or rather, there are thirteen root server addresses. The actual number of physical machines serving those addresses is much larger. Root server operators use a technique called anycast to make hundreds of physical machines around the world share the same IP address, routing queries to whichever machine is geographically closest. The root server infrastructure as a whole receives hundreds of millions of queries per day.
Record types and what they mean
DNS is not just about IP addresses. It carries many types of records, each serving a different purpose, and the variety of record types is part of what makes DNS the infrastructure layer it has become.
The A record is the most basic: a mapping from a name to an IPv4 address. AAAA records do the same for IPv6 addresses. These are what most people think of when they think of DNS.
NS records are nameserver records. They specify which servers are authoritative for a domain. When the .com registry delegates authority for google.com to Google's nameservers, it does so by publishing NS records for google.com.
MX records are mail exchanger records. When you send an email to someone@gmail.com, the mail server handling the sending side queries DNS for the MX records of gmail.com. These records specify which servers accept email for that domain and in what order of preference to try them. Without MX records, email routing would require manual configuration at every mail server in the world.
CNAME records are canonical name records. They allow one name to be an alias for another. cdn.example.com might be a CNAME pointing to example.cdn-provider.net. When a resolver encounters a CNAME, it follows the chain until it finds an A or AAAA record. CNAMEs enable operators to point multiple names at a single IP address without duplicating records, and to change the underlying IP by changing only the target of the CNAME rather than every record that needs to point there.
TXT records carry arbitrary text. They were originally intended for human-readable information but have been repurposed for machine-readable data of many kinds. Today TXT records are used for domain ownership verification, for SPF records that specify which mail servers are authorized to send email for a domain, for DKIM records that carry public keys used to sign email, and for dozens of other purposes that the designers of DNS in 1983 did not anticipate.
SOA records, start of authority records, are present at the apex of every zone and contain administrative information about the zone: the primary nameserver, the email address of the responsible person, and several timing values that control how secondary nameservers synchronize with the primary.
PTR records are reverse DNS records. They map IP addresses back to names. When a web server receives a connection from an IP address and wants to know the hostname associated with it, it queries the PTR record for that address. Reverse DNS is maintained in a special part of the namespace, in.addr.arpa for IPv4 and ip6.arpa for IPv6, structured so that the IP address is represented as a name in the DNS hierarchy.
SRV records allow services to publish location information. Instead of hardcoding the hostname and port of a service in client configuration, a client can query an SRV record for a service name and discover where the service is running, including multiple servers with relative weights for load balancing.
Caching and TTLs
The cache is what makes DNS practical at internet scale. Without caching, every request for a web page would require three or more DNS lookups, each taking tens of milliseconds, before the first byte of content could be requested. With caching, most lookups return an answer in microseconds.
The TTL on a DNS record is the domain operator's instruction to resolvers about how long to cache the answer. A TTL of 300 means resolvers should discard their cached answer after five minutes and ask again. A TTL of 86400 means the answer can be cached for twenty-four hours.
The choice of TTL involves trade-offs that are not obvious until you have had to make a change to a DNS record in a production environment.
A low TTL means changes propagate quickly. If you need to move a service from one IP address to another, a low TTL means that once you update the record, resolvers around the world will have the new address within minutes. If you make a mistake and publish the wrong address, a low TTL means you can correct it quickly.
A low TTL also means every resolver that handles queries for your domain has to ask your nameservers more frequently. For a high-traffic domain, this increases load on authoritative nameservers and adds latency for users who happen to query after a cache has expired.
A high TTL means less frequent queries to authoritative nameservers and lower latency for most users. It also means that when you need to make a change, you need to have lowered the TTL long before you plan to make the change, because cached records with long TTLs will be honored by resolvers until they expire. The standard practice before a migration is to lower the TTL to 300 or lower several days in advance, wait for all existing high-TTL caches to expire, make the change, and then raise the TTL again once the new value has been stable for some time.
The relationship between TTLs and DNS propagation is the source of an enormous amount of confusion. People talk about DNS changes "propagating" as if the update spreads outward from the source. What actually happens is the inverse: caches expire and resolvers ask for the current value. A change is "propagated" when all active caches of the old value have expired. The time this takes is roughly equal to the TTL that was set on the record when the change was made.
Zones and zone transfers
The DNS namespace is divided into zones. A zone is a portion of the namespace managed by a particular set of authoritative nameservers. The boundary between zones occurs at delegation points: when a zone operator uses NS records to delegate authority for a subdomain to a different set of nameservers, the subdomain becomes its own zone.
For example, google.com is a zone. mail.google.com might be a separate zone if Google has delegated authority for it to different nameservers. The .com TLD is a zone. The root is a zone.
Each zone has a primary authoritative nameserver, the one where changes are made, and typically one or more secondary nameservers that serve as replicas. Secondaries synchronize with the primary through a mechanism called zone transfer. In a full zone transfer, AXFR in DNS parlance, the secondary requests the entire zone file from the primary. In an incremental zone transfer, IXFR, the secondary requests only changes since the last synchronization.
Zone transfers have historically been a security concern. An AXFR query to a misconfigured nameserver would return every record in the zone, a complete inventory of every host and service in a domain. This information is useful for network reconnaissance. Modern nameservers are configured to restrict zone transfers to known secondary nameservers, but misconfigurations still occur and are still exploited.
DNSSEC: trying to make DNS trustworthy
DNS has a fundamental security problem that is different in character from BGP's trust problem but equally serious.
DNS responses are unauthenticated. When your recursive resolver receives an answer, it has no cryptographic way to verify that the answer came from the actual authoritative nameserver for that domain and was not modified in transit. An attacker positioned between a resolver and an authoritative nameserver can intercept a query and return a forged response, redirecting traffic to an address of their choosing.
This attack is called DNS spoofing or DNS cache poisoning. Because resolvers cache responses, a successful poisoning attack can affect every user who queries through that resolver until the TTL expires, which could be hours or days.
The classic cache poisoning attack exploits a race condition. DNS uses UDP for most queries, which means there is no established connection that an attacker would have to hijack. An attacker who can observe a resolver's query can flood the resolver with forged responses, trying to win the race against the legitimate response. A successful forgery requires only that the attacker's response arrive before the legitimate one and include the correct transaction ID, a 16-bit number that DNS uses to match responses to queries.
In 2008, a security researcher named Dan Kaminsky discovered a variant of the cache poisoning attack that was far more dangerous than the theoretical versions that had been discussed previously. The Kaminsky attack could poison a cache for an entire domain, not just a single record, and could do so extremely quickly by repeatedly querying for randomly-generated subdomains. This forced all resolvers in the world to ask the authoritative nameserver for the domain, creating opportunities to race the legitimate responses. The fix, randomizing the source port of DNS queries as well as the transaction ID, increased the attacker's search space from 65,536 possibilities to several billion, buying time but not solving the underlying problem.
DNSSEC, DNS Security Extensions, is the actual solution. It adds a chain of cryptographic signatures to the DNS hierarchy, allowing resolvers to verify that the answers they receive were produced by the legitimate authoritative nameserver and have not been modified in transit.
In a DNSSEC-enabled zone, each record set is accompanied by an RRSIG record containing a digital signature over that record set. The zone also publishes DNSKEY records containing the public keys needed to verify these signatures. The question of how you verify that the DNSKEY records themselves are legitimate is answered by a chain of trust extending up the DNS hierarchy: the parent zone signs a hash of the child zone's DNSKEY records, creating a chain of trust from the root zone down to any DNSSEC-signed domain.
The root zone has been signed since July 15, 2010. Most TLDs are now signed. But the adoption of DNSSEC at the second-level domain level has been slow. Operators are reluctant to deploy it because the configuration is complex, key management is operationally demanding, and a misconfiguration can make an entire domain unreachable for the duration of the TTL on its records. The benefit, protection against cache poisoning, is invisible when things are working correctly and catastrophic when things go wrong.
As of 2025, approximately one third of internet users are behind resolvers that perform DNSSEC validation. The other two thirds are protected only by the source port randomization fix from 2008.
DNS over HTTPS and the privacy problem
Traditional DNS has a privacy problem that has received increasing attention over the past decade.
DNS queries are sent in plaintext, unencrypted, to the resolver. Every DNS query you send reveals which domains you are looking up. Your ISP's resolver receives every query, can log every query, and can sell that log to data brokers or hand it to governments with appropriate legal process. A network operator anywhere between your device and your resolver, a coffee shop, an employer, a carrier, can see your query traffic.
For most of the history of DNS this was not considered a problem. DNS queries were just infrastructure traffic, uninteresting metadata about where you were browsing. The rise of mass surveillance, targeted advertising based on browsing behavior, and authoritarian governments using DNS monitoring for population surveillance changed that calculation.
DNS over HTTPS, or DoH, encrypts DNS queries by sending them over HTTPS connections to a resolver. From the perspective of anyone observing network traffic, DoH queries are indistinguishable from ordinary HTTPS traffic. The ISP no longer knows which domains you are querying. The coffee shop cannot build a profile of your browsing. Governments that want your DNS traffic must subpoena the DoH resolver provider rather than reading it off the wire at any convenient network tap.
DoH was standardized in RFC 8484 in 2018. Firefox adopted it in 2020, defaulting all DNS traffic in the United States to Cloudflare's resolver unless the user changed the setting. Chrome added DoH support. Apple implemented encrypted DNS in iOS 14 and macOS Big Sur.
The response from some ISPs and network operators was not enthusiastic. ISPs argued that DoH was bypassing their ability to implement parental controls, malware filtering, and content blocking that operated at the DNS level. Some operators argued that concentrating DNS traffic at a handful of large providers, rather than the distributed ecosystem of ISPs, was a centralization of the internet that created new chokepoints and dependencies.
Both arguments are partially valid. Content filtering via DNS is genuinely useful for some users and some networks, and DoH as implemented routes around it. The concentration of DNS traffic at a small number of providers is also a real architectural concern: if Cloudflare's 1.1.1.1 has a major outage, it is potentially disruptive in a way that a single ISP's resolver going down is not.
DNS over TLS, DoT, is an alternative encrypted DNS mechanism that uses TLS over a dedicated port rather than HTTPS. It offers the same privacy properties but is more visible to network operators because it uses a dedicated port, allowing ISP-level controls to be applied without breaking general HTTPS traffic. Different communities have different preferences about whether this is an advantage or a disadvantage.
Split-horizon DNS and the edge cases
DNS in production is more complicated than the textbook describes. One of the common complications is split-horizon DNS, also called split-view or split-brain DNS.
Many organizations run internal services that should only be accessible from within their network. They also want these services to have sensible names. A company might want api.internal.example.com to resolve to a private IP address when queried from inside the corporate network, but return no record or a different IP address when queried from outside.
Split-horizon DNS solves this by running separate nameservers for internal and external queries. An authoritative nameserver visible to the public internet serves one set of records. An authoritative nameserver visible only to internal resolvers serves a different set. Both are authoritative for the same domain name, but they give different answers depending on where the query is coming from.
This is entirely invisible to users. They type the same name and get the right answer for their location. But it means that "what does this name resolve to" no longer has a single answer. The answer depends on who is asking and where they are asking from.
Split-horizon DNS complicates debugging. "The DNS record says X" is not a complete statement. "The DNS record says X when queried from a public resolver from outside your network" is more accurate, but still only tells half the story if you also need to know what internal resolvers say.
DNS as attack surface
The Dyn attack in 2016 was a distributed denial of service attack: overwhelming a DNS provider with traffic until it cannot respond to legitimate queries. When an authoritative nameserver cannot respond, resolvers get no answer and return errors to clients. The domains hosted on that nameserver become unreachable.
DNS can also be used as an attack vector rather than an attack target. DNS amplification attacks exploit the fact that small DNS queries can produce large DNS responses. An attacker sends queries with a forged source IP address to open DNS resolvers, which send their large responses to the forged address, the actual target. Because the response is much larger than the query, the attacker generates more traffic at the target than they send to the resolvers: amplification.
ANY queries, which ask a nameserver to return all records for a name, can produce responses hundreds of times larger than the query. DNSSEC-signed zones produce even larger responses. A botnet that can send a gigabit of DNS queries can generate hundreds of gigabits of traffic at a target, more than enough to saturate most connections.
DNS tunneling uses DNS itself as a covert communication channel. Because DNS queries and responses are allowed through most firewalls, an attacker who has compromised a system inside a network can communicate with a command-and-control server outside the network by encoding data in DNS queries and responses. The data is slow to transmit this way, but the channel is often undetected because DNS traffic is considered infrastructure noise rather than application traffic.
Fast-flux DNS is a technique used by malware operators and phishing campaigns to make takedown difficult. The A records for a domain are cycled rapidly, sometimes seconds apart, pointing to a rotating set of IP addresses. At any moment the domain is active. But by the time a security researcher identifies one of the IP addresses as malicious and has the hosting provider take it down, the domain has already moved to a different set of addresses.
The dependency no one talks about
DNS is one of those systems that only becomes visible when it breaks. The Dyn attack in 2016 made DNS infrastructure visible to consumers in a way it had never been before. People who had never heard of DNS suddenly understood that their inability to reach Twitter was not Twitter's fault.
What the Dyn attack clarified for people paying attention was the degree to which the internet's functional behavior depends on an infrastructure layer that most people have no awareness of and no control over. You can build the most reliable web service in the world. If the DNS provider that hosts your domain's authoritative records goes down, your service goes down with it.
The attack also clarified a structural problem in the DNS provider market. In the years before 2016, many major websites had consolidated their DNS hosting at a small number of providers, primarily because those providers offered global anycast networks, automatic failover, low-latency responses, and advanced features that smaller or self-hosted alternatives could not match. Consolidation made economic and operational sense. It also meant that a single provider going down could take dozens of major platforms with it, which is precisely what happened.
The post-Dyn response among large platform operators was to distribute DNS across multiple providers. If one provider goes down, the other continues to serve queries. This is operationally more complex, requires synchronizing records across multiple providers, and adds cost. But the 2016 experience made the argument for redundancy very difficult to dismiss.
How your operating system resolves names
The DNS system described above is what operates at the network level. There is also a layer of name resolution that operates inside your operating system, and the two interact in ways that are not always obvious.
Your operating system's resolver is the software that handles DNS queries on behalf of applications running on your machine. When a browser needs to look up www.example.com, it asks the operating system's resolver, which may check several sources before sending a query to a DNS server.
Most operating systems check a local file first. On Linux and macOS this is /etc/hosts. On Windows it is %SystemRoot%\System32\Drivers\etc\hosts. This file is a holdover from the original HOSTS.TXT architecture: a local mapping of names to addresses that takes precedence over DNS. You can add entries to this file to override DNS for specific names, which is useful for development and testing but can also be exploited by malware.
The order in which an operating system checks different sources for name resolution is configured in a file called nsswitch.conf on Linux systems, or through system policies on other platforms. The default is usually to check the hosts file first, then DNS. Some systems also check mDNS, multicast DNS, which is used for local network name resolution in environments where a DNS server is not present.
The operating system's resolver also maintains its own cache of recent DNS responses, separate from the resolver's cache at your ISP or DNS provider. On macOS, you can flush this cache with a specific command. On Windows, the DNS Client service maintains the cache. On Linux it depends on what software is installed: systemd-resolved, nscd, or no cache at all if the system is configured to send every query to the network resolver.
What the next forty years look like
DNS was designed for a world where the primary use case was translating hostnames to IP addresses. It has been extended to carry email routing, domain ownership verification, cryptographic keys, service discovery, and dozens of other functions that the original designers could not have anticipated.
The extensions have worked, mostly. DNS is still the infrastructure layer it was designed to be. But several stresses are accumulating.
The growth of the internet means the DNS infrastructure handles vastly more queries than it was designed for. The introduction of new generic TLDs, hundreds of them approved since 2013, has expanded the namespace and created new administrative complexity. The deployment of IPv6 requires every dual-stack device to make AAAA queries in addition to A queries, roughly doubling query volume. DNSSEC signatures increase the size of responses significantly, straining the UDP packet size limits that DNS was designed around.
The privacy conversation around DNS is ongoing. DoH and DoT have shifted query traffic from ISP resolvers to a handful of large commercial resolvers, a centralization that improves privacy for individual users but changes the architecture of the system in ways that are not obviously beneficial for the internet as a whole.
The security situation is better than it was ten years ago but far from resolved. DNSSEC validation rates have grown slowly. The ecosystem of open resolvers that enable amplification attacks is large and stubbornly persistent. The threat model for DNS continues to evolve.
What has not changed is the fundamental design. A hierarchical, delegated namespace, maintained by distributed authoritative servers, queried through recursive resolvers with caching: this is still the architecture that handles every name lookup for every connected device on the planet. It was designed in a small number of offices in 1983 by engineers who were trying to scale the name resolution system for a network with fewer than a thousand hosts.
The system they built now handles billions of queries per second for a network with billions of hosts.
The next time your browser cannot find a website, before you call your ISP, check whether the problem is DNS. The next time you are debugging a production deployment and traffic is not going where it should, check the TTLs on your records. The next time you see an incident report for a major platform that blames DNS, think about the fact that the protocol underneath that incident was designed in 1983, when the internet was a research project with a few dozen nodes, and has been routing every name you have ever typed ever since.
It is not glamorous infrastructure. It is not the kind of thing that generates conference talks or career-defining projects. It is closer to plumbing than to architecture, the kind of thing people only notice when it fails.
It also has to be right every single time.
Top comments (0)