The Domain Name System

To connect to a site, your computer needs its IP address, a number such as 141.193.213.20. But nobody types numbers: we type names, such as en.wikipedia.org or www.berkeley.edu. What bridges the two is the DNS, the system of domain names of the internet. Every time you open a site, send an email or an app connects to a server, the DNS is asked first, usually in a few thousandths of a second. Type a name in the field below and follow the way of the question:

name

Your computer does not go around asking: it asks a single question of a resolver, which does the heavy work. The resolver starts at the top, at a root server, which sends it to the servers in charge of the ending of the name, such as .org, which in turn send it to the servers of the organization that owns the name. Only these last know the answer. In the figure, the questions are in orange, the pointers to whom to ask in blue and the answers in teal. On the way, the resolver keeps everything it learns, and so the same question, asked again, is answered at once: choose “Repeated query” to see the difference.

The address that appears at the end is made up, from a range reserved for examples. Further on, we will follow a real query, with the messages that actually went across the network.

This conversation happens trillions of times a day, and the system that supports it is one of the most successful of the internet: a database of more than 400 million registered domains, kept by thousands of independent organizations, without any of them having to know the whole. In this guide, we will see where the idea came from, how names are organized in a tree divided into zones, how a resolver finds an answer and why it keeps what it learns. Then we will open a message byte by byte, and see how an attacker can poison a cache and how signatures and encryption protect the answers and the privacy of whoever asks.

A list in a file

In the beginning, there was no DNS. On the ARPANET, the network from which the internet grew, each computer had a short name, such as SRI-NIC, and the table that tied each name to its address was kept in a single text file, HOSTS.TXT. It was looked after by the Network Information Center, the NIC, at SRI, a research institute in California. To register a new computer or change an address, an administrator sent a request to the NIC, which updated the file; every so often, each computer of the network downloaded the whole new version.

With a few dozen computers, this worked well. But the network grew fast: there were 213 computers in August 1981, 562 two years later and more than a thousand in 1984. Drag the slider and see what happens when all of them download the file:

The trouble is that two things grow together: the file gains a line for each new computer, and each new computer is one more downloading the file. The traffic of each update grows with the square of the size of the network: with ten times as many computers, a hundred times as many lines go round. And it was not only the traffic. A change could take days to reach everyone, and whoever had downloaded the version before went on with old data. The names were all on the same level, and two institutions could not give their computers the same name. And everything hung on a single team, in California.

In 1983, Paul Mockapetris, of the Information Sciences Institute of the University of Southern California, proposed an alternative, in the documents RFC 882 and RFC 883: a distributed system, in which each organization looks after its own names, and a hierarchical structure to tie them all together. It is the Domain Name System. The specification was revised in 1987, in RFC 1034 and RFC 1035, which are still the basis of the DNS, with dozens of extensions added since. The first name registered under .com, symbolics.com, dates from 15 March 1985. By the end of 1987, the internet already had more than 28,000 computers.

The old file, by the way, has not quite disappeared. Every computer still has a small local list of names, the file hosts, which is at /etc/hosts on Linux and macOS and at C:\Windows\System32\drivers\etc\hosts on Windows. It is looked up before the DNS, and, on Linux and macOS, it is what makes the name localhost work even without a network.

A tree of names

The first idea of the DNS is to give names a structure. A name such as en.wikipedia.org is read from right to left, from the most general to the most specific: org is one of the top-level domains, wikipedia is a name within org, and en is a name within wikipedia.org. Each part between the dots is a label, and the labels form a tree, with the root at the top:

name

Type other names and see the path they take in the tree; the labels that are not yet in it are added. You can also tap a label to choose it. The full name of a label is its path up to the root, and so the same label can appear in several places: www.berkeley.edu and www.bbc.co.uk are not confused, because the two www are on different branches. The owner of each branch chooses the names below it freely, without asking anyone.

The root has a label too, which is empty. That is why the complete form of a name, such as en.wikipedia.org., ends with a dot, after which comes the empty label of the root. In the browser, the final dot is almost always left out, but it appears in configuration files and in diagnostic tools.

There are a few rules. Each label has at most 63 characters, and the whole name at most 253. Traditionally, only letters without accents, digits and the hyphen are used, and capitals and small letters are the same: WWW.BERKELEY.EDU is the same name as www.berkeley.edu. Names with accents or in other scripts, such as café.co.uk, are converted into a form that uses only those characters and begins with xn--: xn--caf-dma.co.uk. Try typing it in the figure. This conversion, called Punycode, appears in the guide to Unicode.

The labels just below the root are the top-level domains. Some are generic, such as com, org and net; others, of two letters, belong to countries and territories, such as uk, ie and jp; and there are hundreds of newer generic ones, such as app and london. In all, there are more than 1,400. The United Kingdom's .uk, for example, was delegated on 24 July 1985, one of the very first, to Andrew McDowell, at University College London, and today it is run by Nominet, with more than 10 million registered names, most of them under co.uk.

Zones and delegation

The tree is huge, and no one keeps the whole of it. It is divided into zones, pieces run independently, each by its own name servers. The root zone knows which are the top-level domains, but nothing about what exists within them; the edu zone knows which names were registered under .edu, but not which computers exist within berkeley.edu. Tap the labels to see the zone of each, with its servers:

Handing a piece of the tree over to another zone is called delegation, and it is marked in orange. To delegate berkeley.edu, the edu zone publishes the names of the servers in charge of it, in records of the type NS, for name server. Whoever asks .edu anything about berkeley.edu gets this pointer: “I don't know, ask adns1.berkeley.edu, adns2.berkeley.edu or adns3.berkeley.edu”. The names and the lists of servers in the figure are real.

Notice a detail: all three servers of berkeley.edu have names within berkeley.edu itself. To find out the address of adns1.berkeley.edu, one would have to ask the servers of berkeley.edu, but to ask them, one must know their address. To break this circle, the zone above also keeps the addresses of these servers, in extra information called glue, which comes with the pointer.

Not every dot in a name is a delegation, and not every delegation changes hands. co.uk and gov.uk are zones apart, but they are on the same servers as .uk, those of Nominet. bbc.co.uk, in turn, is delegated to the BBC's own servers. And en.wikipedia.org is in the same zone as wikipedia.org: Wikimedia need not delegate anything to make a new name, it just adds it to its zone. That is what lets the DNS grow without a centre: each zone only needs to know its own delegations.

Who asks and who answers

There are two very different kinds of server in the DNS. The authoritative servers keep the zones and answer only about them: the root servers for the root zone, those of .edu for the edu zone, those of UC Berkeley for the berkeley.edu zone. They ask nothing of anyone. Either they know the answer, because it is in their zone, or they point to whoever knows.

The resolvers are the opposite: they keep no zone at all, but they know how to walk the tree, asking from server to server until they reach the answer, and they keep in their cache everything they learn. Usually, the resolver your computer uses is your internet provider's, given to it automatically when you connect to the network. But there are also public resolvers, open to anyone, such as Google's, at the address 8.8.8.8, launched in 2009, Quad9, at 9.9.9.9, from 2017, and Cloudflare's, at 1.1.1.1, from 2018.

On your computer there is also a third participant, a much simpler one: the stub resolver, the part of the operating system that programs call when they need an address. It does not walk the tree; it only passes the question on to the real resolver, with a request for recursion, which means “go all the way and bring me the answer ready”.

A query, step by step

Let us follow a real query: the messages exchanged to find out the address of www.berkeley.edu, in October 2026, with the resolver's cache empty. Drag the slider, or tap the arrows, to see what each message holds:

The same question, “what is the address of www.berkeley.edu?”, is asked three times, of three different servers. The root does not know the answer, but it knows who runs .edu, and gives back a referral: the list of the servers of .edu, in the authority section of the message, and their addresses, the glue, in the additional section. The server of .edu does the same, one level down. Only the server of UC Berkeley has the answer, and it marks it as authoritative.

And the answer brings two addresses: www.berkeley.edu has two records of the type A, and the browser may use either. The number before the type, 300, is the lifetime of each record, in seconds; we will come to it shortly.

The times in the figure are approximate, for a resolver in California. Each round trip to a server costs from a few to tens of milliseconds, depending on the distance, and that is why the resolver does all it can not to repeat them. The next time someone asks for www.berkeley.edu, or for any other name ending in .edu, it will already know whom to turn to.

The root servers

Every search starts at the same place, and so resolvers come with a list of the addresses of the root servers. There are 13 names, from a.root-servers.net to m.root-servers.net, run by 12 different organizations: Verisign runs two, A and J, and the others are run by universities, agencies of the American government, companies and non-profit organizations, such as the RIPE NCC, in the Netherlands, Netnod, in Sweden, and the WIDE project, in Japan.

Why 13? Because of a limit of the original design: a DNS answer could have at most 512 bytes, and 13 is the number of servers whose names and addresses fit in an answer of that size. But 13 is only the number of names. Each root server is in fact a group of identical copies spread around the world, all with the same IP address: on 28 September 2026, there were 2,045 copies. The trick is called anycast. Each copy announces the same address to the networks around it, and the routing of the internet, which we saw in the guide to IP, takes each packet to the nearest copy, in terms of the network. Compare a single server with the copies spread out, and move around:

The lines on the globe separate the regions served by each copy. The 43 cities of the figure are a simplification, and on the real internet the copy that answers is not always the nearest in kilometres, because the paths depend on agreements between the networks. But the effect is real. With a single server, whoever is on the other side of the world waits hundreds of milliseconds for each question; with the copies, nearly everyone has a root a few milliseconds away. The time in the figure is an estimate: light travels through optical fibre at some 200,000 kilometres per second, and the cables seldom follow the shortest line. Anycast also protects against attacks: a flood of packets from one region hits only the copies of that region.

Even with so many copies, the root servers are not asked all the time. The referrals they give are good for two days, and a busy resolver hardly ever needs to ask the root where .com or .uk is. Many of the questions that reach the root are in fact about top-level domains that do not exist, the fruit of wrong configurations.

Cache and lifetime

If every resolver went the whole way for every query, the root and the top-level domains would get an avalanche of questions, and each visit to a site would take much longer. What saves the system is the cache: the resolver keeps each record it receives and answers the questions that follow without leaving home. But for how long? The owner of the name decides. Each record carries its lifetime, the TTL (time to live), in seconds. In the query for www.berkeley.edu, the addresses are good for 300 seconds, five minutes, and the list of the zone's servers for 10,800, three hours.

The figure below simulates two hours of queries for a name whose address changes at 75 minutes. Each dot on the top line is a user's question to the resolver; the middle line shows what the resolver keeps, and the bottom one, the address that the authoritative server gives. Change the lifetime, and how busy the site is:

The choice of the lifetime is a compromise. With short lifetimes, nearly every query goes to the authoritative server, which makes the answers slower and the servers busier, but a change soon reaches everyone. With long lifetimes, nearly everything comes from the cache, but a change can take hours to reach everyone: while the old copy has not run out, the resolver goes on handing out the old address, in full confidence. Notice too that, for a much visited site, even a short lifetime saves most of the trips to the server.

This explains the famous “DNS propagation”, the hours of waiting after moving a site to another server. In fact nothing propagates: the resolvers of the whole world just let the copies they kept run out, each in its own time. Whoever plans a change can shorten the lifetime of the records a few days before, and lengthen it again afterwards. And there are caches everywhere, not only in the resolver: the operating system and the browser also keep the answers for a while.

Even the lack of an answer goes into the cache. When a name does not exist, the authoritative server answers with an error code, NXDOMAIN, and the resolver keeps this negative answer too, for the time given in the zone's SOA record.

The types of record

So far we have only talked about addresses, but the DNS keeps many kinds of information about a name, each in a type of record. The records of a zone are usually written in a text file, in a format defined in 1987 and used to this day. This is the file of an imaginary bakery (the domain example is reserved for examples). Tap a line to see what it says:

Each line holds the name, the class (nearly always IN, for internet), the type and the data. The most common types are A and AAAA, for IPv4 and IPv6 addresses; CNAME, for aliases; MX, for email; NS and SOA, which describe the zone itself; and TXT, for free text. A name can have several records of the same type, and every question to the DNS says which type it wants: a server about to deliver an email asks for the MX, and the browser asks for the A and the AAAA.

The last record, PTR, lives in a special tree and goes the opposite way, from the address to the name. It is used, for example, by mail servers that want to know who is contacting them, and by diagnostic tools that show names instead of numbers. IPv6 addresses have a tree of the same kind, under ip6.arpa.

Inside a message

What does a question to the DNS look like, after all? It is a short message, nearly always sent in a single UDP datagram to port 53 of the server. Choose a type of record and switch between the question and the answer; tap the bytes to see what each one means:

Every message begins with a header of 12 bytes: an identification number, the control bits and four counters, which say how many records there are in each of the sections that follow, the question, the answer, the authority and the additional section. The same structure serves for questions and answers: the answer repeats the question and adds the records.

The names do not appear with dots. Each label comes after a byte with its length, and the name ends with a zero byte, the empty label of the root. That is where the limit of 63 characters per label comes from: of the eight bits of the length byte, the first two have another use. When both are 1, the byte is not a length, but the start of a pointer to a name that appeared earlier in the message. Switch to the answer and notice that the name is not repeated: in its place are the two bytes C0 0C, a pointer to byte 12, where the question begins.

Small messages were a requirement of the original design: over UDP, an answer could have at most 512 bytes. When the answer does not fit, the server sends what fits and sets a bit that says it was truncated, and the resolver asks again over TCP. In 1999, an extension called EDNS let whoever asks announce that it accepts larger answers. Since 2020, the limit most used is 1,232 bytes, so that the answer fits in a single packet, without being fragmented on the way; what goes beyond that goes over TCP.

Cache poisoning

The resolver's trust in the answers it receives is at once the strength and the weakness of the DNS. In the original design, nothing guarantees that an answer really came from the server that was asked. UDP has no connection: the resolver accepts the first answer that reaches the address and port the question left from, as long as it carries the same identification number and the same question. An attacker who guesses that number can send a false answer, with the address of the real server forged as its sender. If it arrives before the true one, it goes into the cache, and all the users of that resolver start getting the address the attacker chose. This is cache poisoning.

The identification number has 16 bits, that is, 65,536 possible values. It is not much, but the attacker has little time, only the milliseconds between the question and the arrival of the true answer. And if it lost the race, it had to wait for the lifetime of the true answer to run out before trying again, hours or days later. In 2008, Dan Kaminsky showed how to avoid the wait: instead of always asking for the same name, the attacker makes the resolver ask for names that do not exist, such as x1.bank.example, x2.bank.example and so on. Each new name is a new race, and the false answer does not bring only an address: it also brings a false referral, saying that the servers of bank.example are the attacker's. One hit is enough to take over the whole domain:

With a thousand false answers per attempt, the chance of a hit is 1.5%, and some 66 attempts are enough, on average. In Kaminsky's tests, the poisoning took less than ten seconds. The discovery was kept secret while the makers of DNS servers prepared a fix together, released by all of them at once on 8 July 2008. The details were to be revealed only in August, at a security conference, but they leaked two weeks after the fix, and ready-made programs for the attack soon appeared.

The fix was to draw the source port of each question at random too. Now the false answer must hit both the identification number and the port, and, with about 64,000 possible ports, the combinations number more than 4 billion. Choose “Number and port” in the figure: hardly any false answer even hits the port, and millions of attempts would be needed. But this is a difficulty, not a guarantee: a few weeks after the fix, a researcher poisoned a patched server in less than ten hours, on a local network of one gigabit per second. The lasting solution was another: to make the answers verifiable.

Signatures: DNSSEC

The security extensions of the DNS, DNSSEC, add digital signatures to the zones. The owner of each zone has cryptographic keys: the private part stays with the owner and serves to sign the records; the public part is published in the zone itself, in records of the type DNSKEY. The signatures go in RRSIG records, which come with the answers. Whoever receives an answer checks the signature with the public key, and any change on the way, even a single bit, makes the check fail.

But how to know that the public key really belongs to the owner of the zone, and not to an attacker who signed his own false records? The guarantee comes from the zone above. It publishes a cryptographic digest of the key of the zone below, in a DS record, and signs that record with its own key. The key of berkeley.edu is vouched for by .edu, that of .edu by the root, and that of the root is known beforehand: it comes installed in the resolvers, as a trust anchor. Watch the resolver check the answer from berkeley.edu, with the real keys:

The numbers in the boxes identify the keys. Each zone usually has two: one that signs only the set of keys of the zone, and is the one that the zone above digests in its DS record, and another that signs all the rest, and can be changed often without troubling the zone above. Choose “Address swapped” and the signature no longer matches. Choose “Keys swapped”, in which the attacker signs everything again with keys of his own making: the signature matches, but the new key does not match the digest that .edu published. To fool the chain, the attacker would have to steal the private key of the zone itself or of some zone above it.

When the check fails, the resolver does not hand over the answer: it gives back an error, and the name simply does not work. It is a deliberate choice, because, for DNSSEC, it is better not to answer than to answer wrongly. This also means that a configuration error, such as an expired signature, takes the whole domain down for whoever uses a resolver that checks signatures.

The root was signed on 15 July 2010. Its private key is kept in security devices, in two facilities in the United States, and it is used only in public ceremonies, recorded on video, with representatives of the internet community from several countries present. And that key has just been changed. On 11 October 2026, the root began to sign with a new key, KSK-2024, number 38696, the one in the figure, in place of KSK-2017, number 20326. The new key had been published in the root zone in January 2025, giving resolvers time to learn it by themselves.

DNSSEC only protects those who take part at both ends: the zone must be signed, and the resolver must check. Sweden's .se, signed in 2005, was the first top-level domain to adopt it. And DNSSEC guarantees the authenticity of the answers, not their secrecy: signed answers can still be read by anyone on the way.

Who sees your questions

The DNS was designed at a time when no one thought about privacy, and the questions travel in the clear. Whoever is on the way between you and the resolver, such as the Wi-Fi network of a café or your provider, sees each name you look up. The resolver, by definition, sees all of them, together with your IP address. And the authoritative servers see the questions that the resolver asks, usually without your address; some resolvers pass on a piece of it, so that the server can point to a copy of the site near you. Turn on the protections below to see what each one comes to see:

The first protection is to encrypt the conversation with the resolver, with the same techniques as the secure connections of the web. DNS over TLS, from 2016, uses a port of its own, 853. DNS over HTTPS, from 2018, sends the questions as if they were requests to a site, over port 443, and is hard to tell apart from the rest of the web's traffic. Browsers offer DNS over HTTPS, and the most recent operating systems one or both. But these protections do not hide everything: whoever is on the way still sees which IP addresses you connect to next. And encryption changes nothing as to the resolver itself, which still sees all your questions. To choose a resolver is to choose whom to trust.

The second protection is query name minimization: instead of asking each server the whole name, the resolver asks each one only what it needs. Of the root, it is enough to ask who runs .edu; of .edu, who runs berkeley.edu. Only the server of UC Berkeley needs to know that the question is about www.berkeley.edu. The technique was proposed in 2016, became a standard in 2021 and is already turned on in several of the most used resolvers.

The DNS in practice

You can make your own queries. On Linux and macOS, the command dig shows the answers almost as they come in the message; on Windows, the equivalent is nslookup, which also exists on the other systems:

$ dig www.berkeley.edu

;; ANSWER SECTION:
www.berkeley.edu.   300   IN   A   141.193.213.20
www.berkeley.edu.   300   IN   A   141.193.213.21

$ dig +trace www.berkeley.edu    # walks the tree from the root
$ dig berkeley.edu MX            # another type of record
$ dig -x 8.8.8.8                 # the way back, through the PTR: dns.google
$ dig +dnssec berkeley.edu       # shows the signatures too

The option +trace does what the resolver does, from the root, and shows each referral on the way, as in the figure of the query step by step. If you repeat the first query, you will see the lifetime going down: it is the time still left before that copy runs out in the resolver's cache.

When a site will not open, the DNS is one of the first suspects. On 21 October 2016, a denial of service attack made with hijacked cameras and video recorders took down the servers of Dyn, a company that hosted the DNS of many sites, and services such as Twitter, Netflix and Spotify went offline for many of their users, above all in the United States. On 4 October 2021, a mistake during maintenance cut off Facebook's internal network, and the company's DNS servers, unable to reach the rest of it, withdrew from the internet the routes to themselves. For about six hours, facebook.com, instagram.com and WhatsApp ceased to exist for the world, even with their servers running. No wonder that, among network administrators, there is a saying: when something mysterious goes wrong, “it's always DNS”.

Final words

The DNS was designed in 1983, when the network had little more than 500 computers, and today it answers for hundreds of millions of domains, without having changed its central idea. Mockapetris's proposal, to divide the tree into zones and let each owner look after its own, let the system grow without anyone having to know the whole. And the part that makes it fast is the least showy: the cache, which has most questions answered without leaving the resolver.

Its weaknesses also come from the original design, made for a network in which everyone knew everyone. There was no way to check the answers, nor to hide the questions, and the solutions came later, in layers: random ports, signatures, encryption. The next time you type a name in the browser, remember that, before the first letter of the page appears, a small question may have gone round the world, or, far more likely, been answered by a resolver that already knew the answer.