DNS is the system that turns a domain name like example.com into the IP address a computer connects to. Every website visit and every email starts with a DNS lookup. This guide explains what DNS is and how it works, step by step, with a real lookup of example.com run on 12 October 2026.
Quick Answer: DNS (Domain Name System) is a distributed database that maps domain names to IP addresses and other data. When you open a site, a resolver asks a root server, then the TLD server (for example
.com), then the domain's authoritative nameserver, and caches the answer for the time the record's TTL allows. To see the DNS records of any domain, use our DNS lookup tool.
What is DNS?
DNS stands for Domain Name System. Computers on the internet find each other by IP address, such as 104.20.23.154. People use names, such as example.com. DNS stores the link between the two.
Nobody runs DNS from one place. Each domain owner publishes their own records on their own authoritative nameservers. A hierarchy of servers tells everyone else where to find them. That split is why DNS scales to every domain on the internet: the .com servers only need to know which nameservers hold each .com domain, not every record in it.
How DNS resolution works
When you type a domain into a browser, your device needs its IP address. The search for that address is called DNS resolution.
1. Local caches
The browser checks its own cache first, then the operating system's. If you visited the site a few minutes ago, the address is probably still there, and no query leaves your device.
2. The recursive resolver
If neither cache has the answer, your device asks a recursive resolver. This is usually your internet provider's resolver, or a public one such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. The resolver does the rest of the work for you. It has its own cache, shared by everyone who uses it.
3. Root, TLD and authoritative servers
On a cache miss, the resolver walks down the hierarchy. You can watch each step with dig +trace, which does the walk itself instead of asking a resolver. Here is the trace for example.com, trimmed to the important lines:
dig +trace example.com A. 509452 IN NS a.root-servers.net.
. 509452 IN NS b.root-servers.net.
...
. 509452 IN NS m.root-servers.net.
;; Received 525 bytes from 100.100.100.100#53(100.100.100.100) in 14 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
...
com. 172800 IN NS m.gtld-servers.net.
;; Received 1171 bytes from 192.5.5.241#53(f.root-servers.net) in 13 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 506 bytes from 192.5.6.30#53(a.gtld-servers.net) in 131 ms
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
;; Received 179 bytes from 172.64.35.228#53(elliott.ns.cloudflare.com) in 10 ms
Each block is one answer, and the Received line under it says which server sent it. Reading it from top to bottom:
- Root servers. dig first gets the list of root servers from the local resolver. There are 13 root server names,
atom.root-servers.net. The f root server did not know example.com, but it named the servers for.com. According to root-servers.org, 12 organizations run those 13 names on more than 2,000 servers worldwide. - TLD servers. The
.comserver (a.gtld-servers.net) did not know the address either. It answered with example.com's nameservers: two Cloudflare servers. - Authoritative server. elliott.ns.cloudflare.com holds the example.com zone and returned the answer: two IPv4 addresses, valid for 300 seconds.
The three server hops took between 10 and 131 milliseconds each. A resolver rarely does the whole walk. It caches the root list for days and the .com delegation for up to two days (the TTLs of 509452 and 172800 seconds above), so most lookups go straight to the last step.
4. The answer comes back
The resolver returns the addresses to your device, which caches them and connects. In this case both addresses belong to Cloudflare, because example.com sits behind Cloudflare's network. A hosting check shows that kind of detail for any domain: who owns the IP addresses, which content delivery network (CDN) is in front, and who runs the DNS.
DNS records
A domain's zone holds more than addresses. Each entry is a DNS record, and its type says what the value means. These are example.com's real records:
| Record | What it holds | example.com |
|---|---|---|
| A | IPv4 addresses | 104.20.23.154, 172.66.147.243 |
| AAAA | IPv6 addresses | 2606:4700:10::6814:179a, 2606:4700:10::ac42:93f3 |
| NS | Authoritative nameservers | hera.ns.cloudflare.com, elliott.ns.cloudflare.com |
| MX | Mail servers | 0 . (a "null MX": the domain accepts no email) |
| TXT | Text, such as an SPF policy | "v=spf1 -all" (no server may send mail as example.com) |
Other common types are CNAME (an alias to another name), SOA (zone settings), SRV (service host and port), PTR (reverse DNS), CAA (which certificate authorities may issue certificates) and HTTPS (connection hints for browsers). DNS records explained covers every type with real examples.
Caching and TTL
Every record carries a TTL (time to live): the number of seconds a resolver may keep it. example.com's A records have a TTL of 300, so a resolver asks again after five minutes at most. The .com servers hand out the NS records for example.com with a TTL of 172800, or two days.
TTL is a trade-off:
- Short TTL (such as 300): changes reach everyone within minutes, but resolvers ask the nameservers more often.
- Long TTL (such as 86400, one day): fewer queries, but a change can take a day to reach every resolver.
The time a change takes to reach every resolver is what people call DNS propagation. Nothing is pushed out to the internet. Each resolver keeps its cached copy until the TTL runs out, then fetches the new one. Caching is also why two people can see different versions of a site for a while after a move.
DNS security: DNSSEC
DNS was designed in the 1980s without any way to check that an answer is genuine. An attacker who can forge a response, or plant one in a resolver's cache, can send visitors to the wrong server.
DNSSEC (DNS Security Extensions) fixes the authenticity part. The zone owner signs each set of records, and the parent zone vouches for the signing key. Root signs .com, .com signs example.com, and so on down. A validating resolver checks the chain and rejects answers whose signatures do not match. ICANN's DNSSEC overview explains the chain in more detail.
example.com is signed. Ask for its records with +dnssec, and the answer carries a signature (RRSIG) and the ad flag, which means the resolver validated it:
dig @1.1.1.1 example.com A +dnssec;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
example.com. 10 IN A 104.20.23.154
example.com. 10 IN A 172.66.147.243
example.com. 10 IN RRSIG A 13 2 300 20261013074543 20261011054543 34505 example.com. 2W26FxtMiRyF55jFNvczBzc8qg4gWsApCnp+8HvTAoQD6sQ+979IZQMZ pF/FVBnVAc1g5Gz07J6990SeDaANSQ==
Many domains are not signed. wikipedia.org, for example, has no DS record at .org, so resolvers cannot validate its answers.
What DNSSEC does and does not protect against:
| Attack | How it works | Does DNSSEC help? |
|---|---|---|
| Cache poisoning | Forged answers are planted in a resolver's cache | Yes. Forged answers fail validation |
| Tampering in transit | Someone on the network path changes answers | Yes, for resolvers that validate |
| Registrar or DNS account takeover | The attacker changes the real records or nameservers | No. The attacker's changes are signed like any others. Use two-factor login and a registrar lock |
| Eavesdropping | Someone on the network sees which names you look up | No. DNSSEC signs answers but does not encrypt them |
DNS privacy: DoH and DoT
Classic DNS queries travel unencrypted over port 53. Your internet provider, the Wi-Fi operator and anyone else on the path can see every name you look up. Two protocols encrypt the queries between your device and the resolver.
DNS over HTTPS (DoH), defined in RFC 8484, sends DNS queries inside ordinary HTTPS on port 443. To an observer, it looks like any other web traffic. Firefox, Chrome and Edge each have a secure DNS setting that turns it on.
DNS over TLS (DoT), defined in RFC 7858, wraps DNS in TLS on its own port, 853. Observers can see that you use encrypted DNS, but not what you look up. Android has supported it system-wide since Android 9, under the Private DNS setting.
| DNS over HTTPS | DNS over TLS | |
|---|---|---|
| Port | 443, shared with web traffic | 853, dedicated |
| Looks like | Ordinary HTTPS | Encrypted DNS |
| Typically set up in | The browser | The operating system or router |
Both hide your queries from the network. The resolver still sees them, so the resolver's own logging policy matters.
Public DNS resolvers
You can replace your internet provider's resolver with a public one. These are four common choices:
| Provider | IPv4 addresses | Notes |
|---|---|---|
| Cloudflare | 1.1.1.1, 1.0.0.1 | Does not store client IPs on disk and deletes its resolver logs within 25 hours. 1.1.1.2 blocks malware and 1.1.1.3 also blocks adult content |
| Google Public DNS | 8.8.8.8, 8.8.4.4 | Keeps temporary logs with the full client IP for 24 to 48 hours |
| Quad9 | 9.9.9.9, 149.112.112.112 | Blocks known malicious domains and validates DNSSEC on its main addresses |
| OpenDNS | 208.67.222.222, 208.67.220.220 | Run by Cisco, with optional content filtering |
Changing your device's resolver only changes who answers your own lookups. It does not change the DNS of any domain you own. A domain's DNS comes from its nameservers, which you set at the registrar.
Why DNS matters if you run a website
- Pointing a domain at a host means setting A, AAAA or CNAME records, or moving the nameservers to the host.
- Email depends on MX records and on SPF, DKIM and DMARC records in TXT. How to check MX records covers the mail side.
- CDNs usually take over through a CNAME or by becoming the domain's nameservers.
- SSL certificates depend on DNS too. CAs check CAA records, and many validate control of the domain with a DNS record.
- Outages often start in DNS: an expired domain, a deleted record or a wrong nameserver.
To read the records yourself, use our DNS lookup tool or follow how to check DNS records for any domain, which covers dig, nslookup and DoH.
Check a domain's DNS
Enter any domain to see its DNS records, the hosting provider behind its IP addresses, its SSL certificate and its server location in one lookup.
Try it yourself
Check any website's hosting
Enter a domain or IP to see hosting provider, DNS records, and more.
Frequently Asked Questions
What is DNS in simple terms?
DNS is the system that finds the IP address for a domain name. Your device asks a resolver. The resolver finds the domain's nameservers through the root and TLD servers, and the nameservers return the address.
What is DNS propagation?
It is the delay between changing a DNS record and every resolver seeing the change. Resolvers keep the old record until its TTL runs out. With a TTL of 300 seconds, that takes up to five minutes. A nameserver change can take up to two days, because TLD servers such as .com hand out NS records with a 172800-second TTL.
What is a DNS server?
A DNS server is any server that answers DNS queries. Recursive resolvers (such as 1.1.1.1) look up answers for clients. Root, TLD and authoritative nameservers hold the data. When people say "change your DNS server", they usually mean the recursive resolver your device or router uses.
Can DNS be hacked?
Yes. Attackers can poison resolver caches, take over a registrar or DNS provider account and change the records, or flood DNS servers with traffic. DNSSEC stops forged answers. Two-factor login and a registrar lock protect the account. Encrypted DNS hides your queries from the network.
What happens when DNS fails?
The browser cannot find the site's IP address, so the site looks down even if the server is fine. Chrome shows errors such as DNS_PROBE_FINISHED_NXDOMAIN. If only your resolver is failing, switching to a public resolver such as 1.1.1.1 restores access. If the domain's own nameservers fail, nobody can reach it until they recover.
How do I change my DNS provider?
For a domain you own, add your records at the new provider first, then replace the nameservers at your registrar with the ones the new provider gives you. If you are choosing a new provider, EuroAlternative lists managed DNS services based in Europe. For your own device, change the DNS server in the network settings. That change affects only your own lookups.
Wrapping up
A DNS lookup goes from a local cache to a resolver, then to the root, TLD and authoritative servers. The TTL decides how long each answer is reused. To watch the steps for a real domain, run dig +trace on it, or look up its records with our DNS lookup tool.
Related articles
Written by
Piotr KulpinskiFounder of HostingChecker.online and a web developer with over a decade of experience in DNS, hosting infrastructure, and domain management. Piotr builds tools that help developers and site owners understand their web stack. Other products: Highseat, OpenAlternative, EuroAlternative, Revinel and Dirstarter.