How Does DNS Work? From Domain Names to IP Addresses

In everyday life

To open a website, we type a name such as "www.example.com" or tap a link. Email addresses also end in a name after the "@." We almost never type a number.

Yet we also hear things like "I changed the DNS settings, but the old site still shows up." Or "A DNS failure took down a major service." What is going on behind the names?

Why there are both names and numbers

The internet sends data in small chunks called packets. The destination on a packet can only be a number, called an IP address. How these numbers work is explained in "What Is an IP Address?"

But numbers like "203.0.113.10" are hard for people to remember. Also, when a site moves to a different server, its number changes. If a name serves as the front door, users can keep using the same name even when the number changes.

So a system was built to look up which number goes with which name. It is called DNS (the Domain Name System). Its basic form today was set in 1987.

Before DNS, every name and number was listed together in one file, and each computer kept a copy. As the number of computers grew, updates could not keep up. DNS splits this list into parts, and each owner manages its own part.

Read a domain name from the right

A name split by dots, such as "www.example.com," is called a domain name. The further right you go, the larger the part it stands for. It is like an address written as street, city, country, with the largest unit last. Unlike an address, though, a domain name does not say where anything is located.

The rightmost part, such as "com" or "jp," is called the top-level domain (TLD). "com" was originally meant for companies, and "jp" is for Japan. The "example" to its left is the part that an organization or person applies for and uses. The leftmost "www" is a name the owner picks freely; here it points to a web server.

Some names have an extra level. In the Japanese name "example.co.jp," "co" (for companies in Japan) is the second level. The organization's name comes to the left of it.

In fact, there is a dot at the far right of every domain name that is usually left out. The full form is "www.example.com." with a final dot, which stands for the starting point of all names. This starting point is called the root. All names together form one tree that branches out from the root.

The steps from a name to a number

Looking up a number from a name is called "name resolution." Three kinds of helpers with different roles take part in it.

The first helper lives inside your phone or PC. It is a small part built into the operating system. It simply asks a fixed partner, "What is the number for this name?" It does not search on its own. This is called a stub resolver. The partner to ask is usually given automatically by DHCP when you join a Wi-Fi network.

The second helper is a server that takes this question and searches on your behalf. Most are run by internet providers or companies, and some public ones are open to anyone. This server is called a full-service resolver, or a caching DNS server. Below, we simply call it the "resolver."

The third helper is a server that holds the original answer. The names and numbers of example.com are written on a server prepared by its owner. A server that holds the official answers for its part of the name is called an authoritative DNS server.

The resolver first asks the server in charge of the root. This is called a root server. The root server does not know the answer, but it says, "For com, ask the com servers." The com server (a TLD server) says, "For example.com, ask this server." Finally, the authoritative DNS server for example.com answers, "It's 203.0.113.10."

Each server knows only about its own part of the name, plus where to send people for the next part down. That is why no single place has to hold every name in the world.

Remembering answers: caching and TTL

Asking from the root every time would be slow, and root servers would be flooded with questions. So the resolver remembers each answer for a while. This "remembering for a while," and the place where answers are kept, is called a cache. Phones and browsers also have small caches.

How long to remember is decided by the owner of the domain, who sends it along with the answer. This time is called the TTL (Time To Live), and it is given in seconds. For example, with a TTL of 3600, the remembered answer is used for one hour, and then the resolver asks again.

Referrals such as "where the com servers are" are remembered in the same way, so root servers are asked only rarely. For commonly used names, the answer comes from the resolver's cache alone.

This design has a flip side. Suppose a site moves to a new server and its number changes. Resolvers around the world keep using the old answer until its TTL runs out. This is what people mean by "waiting for DNS propagation." In reality, nothing spreads across the world step by step. You are waiting for caches in many places to expire. So a common precaution is to shorten the TTL before a move.

Are there only 13 root servers?

The root servers have 13 names, from a to m. They are run by 12 organizations; the US company Verisign handles both A and J. M is run by Japan's WIDE Project.

But this does not mean "there are only 13 machines in the world." Behind each name are many copies placed around the world. According to root-servers.org, run jointly by the operators, there were about 2,000 sites as of 2026.

The copies in different places all claim the same number at once. Routers along the way deliver packets for that number to the copy that is closest along the route. This way of delivering is called anycast. If one site breaks down or comes under attack, the others can keep answering.

What DNS stores: the main records

An authoritative DNS server stores lines for each name, each labeled with the kind of information it holds. Each of these lines is called a record.

IPv6 numbers are four times as long as IPv4 numbers (128 bits). You can see the differences in the table at "IPv4 vs IPv6."

CNAME is used when you hand delivery to a service such as a CDN. A CDN delivers content for you from servers in many places. If your name is an alias of the service's name, you don't need to change your own settings when the service changes its numbers.

A server that sends email looks up the MX record of the name after the "@" in the address. That is how it finds where to deliver the mail.

DNS and privacy

Traditional DNS queries are sent without encryption. So people on the same Wi-Fi, or network operators along the way, can read which names you looked up.

As we saw in "What Does HTTPS Mean?," HTTPS protects the contents. But which site you tried to visit can still be learned from DNS.

So methods were created that encrypt the DNS queries themselves. One wraps them in TLS, the same protection HTTPS uses. It is called DNS over TLS (DoT) and became a standard in 2016. Another sends them as HTTPS traffic. It is called DNS over HTTPS (DoH) and became a standard in 2018. Both are available in many browsers and operating systems.

However, only the link between your device and the resolver is encrypted. The resolver itself knows which names were looked up. Most queries from the resolver to authoritative DNS servers are also still unencrypted. Choosing a resolver is also choosing "who gets to keep the record of your lookups."

Attacks on DNS, and how it is defended

Making a resolver remember a fake answer: cache poisoning

An attack that makes a resolver remember a fake answer is called DNS cache poisoning. If it works, users who type the correct name are still sent to a fake server. While the fake answer is remembered, everyone using that resolver is affected.

A resolver treats an answer as genuine if it carries the same number (ID) as its query. This ID is 16 bits, so there are only 65,536 possible values. The attacker sends a flood of fake answers with guessed IDs, trying to arrive before the real answer.

In 2008, researcher Dan Kaminsky found a way to make this attack far more likely to succeed. The method makes the resolver look up one nonexistent name after another, so the attacker can try again and again. On July 8 that year, the US response center CERT/CC announced it, and many DNS programs were fixed at the same time. The main fix was to also pick the port number at random each time. This greatly increases the combinations an attacker must guess.

Signing the answers: DNSSEC

A more fundamental defense is DNSSEC. The domain owner adds an electronic seal to the records, called a digital signature. The resolver follows the signatures in order from the root. It checks that the answer is genuine and was not altered along the way. The root has been signed since July 2010.

But there are things DNSSEC cannot do. It does not encrypt answers, so it cannot hide which names you looked up (that is the job of DoH and DoT). It does not work for domains without signatures, or with resolvers that don't check them. It also cannot stop attacks that overwhelm a target with huge amounts of traffic (DDoS).

Another defense is HTTPS. Even if you are sent to a fake server, that server usually lacks a valid certificate for the name. So the browser shows a warning. If you see a warning, it is important not to continue.

When DNS goes down: the 2021 Facebook outage

On October 4, 2021, Facebook, Instagram and WhatsApp were unreachable for more than six hours. Below is a summary of the explanation that the operating company (now Meta) published the next day.

It started with maintenance work on the company's internal network. A command meant to check how much spare capacity the links had instead cut every link between its data centers worldwide. A checking tool that should have stopped such mistakes also had a bug.

The company's authoritative DNS servers were built to assume a connection problem if they could not reach the data centers. In that case, they stop announcing directions to the internet, such as "for these numbers, come this way." The rules for exchanging such directions are called BGP. As a result, the DNS servers themselves were running, but no one outside could reach them.

Resolvers around the world could no longer look up the numbers for names such as facebook.com. Even with the service's servers running, users cannot connect without knowing the number. The company's internal tools relied on the same network, so engineers went to the data centers in person to restore service. Meta says the outage was not caused by an attack.

Try it yourself

You can watch name resolution on your own computer. In the Windows Command Prompt or the Mac Terminal, type "nslookup example.com." It shows the number and the resolver that answered.

On a Mac or similar, type "dig +trace example.com" to watch the lookup follow the chain from the root. Both commands only look things up; they don't change any settings.

Common myths

By the numbers

Learn more

• Compare in a table: TCP vs UDP (why DNS queries mainly use UDP)
• How routes are announced: OSPF vs BGP (where BGP, which came up in the Facebook outage, fits in)
• Try the math: the availability calculator (why running several servers makes outages less likely)
• A term for the next step: URL (how a web page's location is written, including the domain name)
• What happens after the name is looked up: "How Is Data Sent Over the Internet?"