DNS (the Domain Name System) is the internet's directory service: it translates human-friendly names like www.example.com into the numeric IP addresses that computers use to connect to each other. It does this through a distributed hierarchy of servers, with heavy caching at every step to keep lookups fast.
Almost every website visit, email and app connection starts with a DNS lookup. It usually takes milliseconds, but when it breaks, nothing seems to work even though your connection is fine.
Why DNS exists
Devices find each other using IP addresses such as 192.0.2.10 or 2001:db8::10. Those numbers are hard for people to remember, and they change when a site moves to a new host or a new cloud region. Names, on the other hand, are memorable and stable.
DNS separates the two. The name stays the same while the address behind it can change at any time, and DNS records tell everyone where to go right now. Before DNS, this mapping lived in a single text file that every computer downloaded. DNS replaced it in the 1980s with a database split across many servers, each responsible for its own part of the namespace.
The DNS hierarchy
Domain names are read from right to left, from the most general part to the most specific. In www.example.com. (note the usually invisible trailing dot):
- The root is the empty label at the very end, represented by the final dot. It sits at the top of the tree.
- Top-level domains (TLDs) such as
.com,.orgor country codes like.deand.uksit directly below the root. - Second-level domains such as
example.comare what people register through a registrar. - Subdomains such as
wwwormailare created freely by whoever controls the domain.
Each level delegates authority to the level below it. The root servers know which servers handle each TLD, the TLD servers know which name servers handle each registered domain, and those name servers hold the actual records. No single server has the whole picture, which is why the system scales.
How a DNS lookup works, step by step
Four kinds of servers take part in a typical lookup. Here is what happens when you type www.example.com into a browser for the first time:
- Stub resolver. Your operating system has a small built-in resolver. It first checks its own cache (and the browser checks its cache too). If there is no answer, it sends the question to a recursive resolver, usually one run by your ISP or a public service you configured.
- Recursive resolver. This server does the legwork. If it has no cached answer, it starts at the top and asks one of the root servers: "Where is
www.example.com?" - Root server. The root does not know the answer, but it replies with a referral: the list of name servers responsible for
.com. - TLD server. The resolver asks a
.comserver, which replies with another referral: the authoritative name servers forexample.com, for examplens1.example.netandns2.example.net. - Authoritative server. The resolver asks one of those servers, which holds the domain's records and returns the real answer, such as an A record pointing to
192.0.2.10. - Answer and caching. The resolver hands the answer back to your device and stores every piece it learned along the way, so the next lookup can skip most of these steps.
There are 13 named root server identities (a.root-servers.net through m.root-servers.net), but each is served by many physical machines around the world using anycast, where the same IP address is announced from many locations and your query goes to the nearest one. Resolvers rarely need the root because TLD referrals are cached for days.
Caching and TTL
If every lookup walked the full hierarchy, DNS would be slow and the root and TLD servers would be overwhelmed. Caching solves this. Every DNS record carries a TTL (time to live), a number of seconds that tells resolvers how long they may keep the answer before asking again.
| TTL value | Duration | Typical use |
|---|---|---|
300 | 5 minutes | Records you expect to change soon, failover setups |
3600 | 1 hour | A common default for most records |
86400 | 24 hours | Very stable records, NS delegations |
Caching happens in several places at once: in your browser, in your operating system, sometimes in your home router, and in the recursive resolver shared by thousands of other users. Failed lookups are cached too. If a name does not exist, the resolver remembers that "NXDOMAIN" answer for a period set by the zone's SOA record, so creating a record right after someone queried it can still leave them seeing "not found" for a while.
Why "DNS propagation" is really cache expiry
When you change a DNS record, you will often hear that it needs "24 to 48 hours to propagate". The word is misleading. Your new record is live on your authoritative servers almost immediately; nothing is pushed out. What actually happens is that resolvers around the world are still holding the old answer in their caches, and each one will only fetch the new answer when its cached copy reaches the end of its TTL.
In practice:
- Lower the TTL before a planned change. If a record has a TTL of 86400, drop it to 300 at least a day before you migrate. Once the old long TTL has expired everywhere, your change will be picked up within minutes.
- Changing name servers is slower. NS records at the TLD level often have TTLs of a day or more, and you do not control them, so moving a domain to a new DNS provider genuinely takes longer.
- Different people see different answers for a while. That is normal during the transition. You can watch it happen with our DNS propagation checker, which compares answers from several major public resolvers.
Public resolvers and encrypted DNS
By default, your device uses whatever recursive resolver your network hands out, usually your ISP's. You can switch to a public resolver instead, such as Cloudflare's 1.1.1.1 or Google Public DNS at 8.8.8.8. Whichever resolver you use can see every domain you look up, so pick one whose privacy policy you trust.
Traditional DNS travels unencrypted over port 53, which means anyone on the network path can read, and potentially tamper with, your queries. Two standards fix that:
- DNS over TLS (DoT), defined in RFC 7858, wraps DNS in TLS on a dedicated port, 853. Android's "Private DNS" setting uses it.
- DNS over HTTPS (DoH), defined in RFC 8484, sends DNS queries as HTTPS requests on port 443, so they blend in with normal web traffic. Major browsers support it.
Encryption protects queries in transit, but it does not prove that the answer is authentic. That is the job of DNSSEC, which lets domain owners cryptographically sign their records so resolvers can detect forged responses.
Querying DNS yourself with nslookup and dig
You can run DNS queries from a terminal. nslookup is available on Windows, macOS and Linux:
nslookup www.example.com
nslookup -type=MX example.com
nslookup www.example.com 1.1.1.1The last form sends the query to a specific resolver, which is useful for checking whether your local resolver has a stale cached answer. On macOS and Linux, dig gives more detail, including the TTL remaining in the cache:
$ dig www.example.com A
;; ANSWER SECTION:
www.example.com. 3600 IN A 192.0.2.10Useful variations include dig example.com MX +short for a compact answer, dig @8.8.8.8 example.com to query a chosen resolver, and dig +trace www.example.com, which performs the root, TLD and authoritative walk-through itself and prints every referral. If you prefer a browser, our DNS lookup tool queries A, AAAA, MX, TXT and other records for any domain.
Frequently asked questions
What happens if DNS stops working?
Websites and apps fail to load even though your connection is up, often with errors like "server not found" or "DNS_PROBE_FINISHED_NXDOMAIN". Connecting directly to an IP address still works, which is a quick way to confirm DNS is the problem. Switching to a different resolver usually fixes it if your ISP's resolver is down.
How do I clear my DNS cache?
On Windows, run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Browsers keep their own cache, so restarting the browser helps too. Note that this only clears your local cache, not your ISP's resolver.
Is DNS the same as my IP address?
No. Your IP address identifies your connection, while DNS is the service that converts names into IP addresses. The DNS servers you use do appear in your network settings, but they are separate from the public IP address shown on the ToolsForAnyone homepage.
Does changing my DNS server make my internet faster?
It can make the first connection to each site slightly quicker, but it does not change your download speed. The main benefits are reliability, filtering and encrypted DNS.