In October 2025, apps across the internet went dark for hours while the servers behind them stayed healthy. One DNS record for Amazon's DynamoDB service in Northern Virginia had been left empty, so nothing could find the database. So what is DNS, and how can one blank entry do that much damage?
This guide shows how the Domain Name System turns names into addresses, which servers pass your request along, and where DNS caching and TTL keep things fast. Your browser does this quietly every time you open a page. You'll also learn what breaks when it fails, how long changes take to spread, and whether encrypted DNS is worth turning on.
What Is DNS and Why Does Every Website Depend on It?
DNS, short for Domain Name System, is the internet's naming layer. It converts a domain name such as example.com into the numeric IP address a computer needs, so you can type words instead of 192.0.2.44. Your browser can't open a connection to a name. It needs a number first, and DNS is the service that supplies it.
When that lookup works, you rarely notice it. When it breaks, a working website looks dead. That gap between "the server is fine" and "nobody can reach it" is why DNS sits underneath nearly everything you do online, from loading a page to sending email.
DNS in Simple Terms
Picture the contacts app on your phone. You tap a name, and the phone dials a number you didn't memorize. DNS does that job for the entire internet, only the contact list is spread across millions of servers instead of living in one place. No single machine holds every record, which helps explain why the system keeps running when parts of it fail.
DNS vs IP Address: What Is the Difference?
They aren't interchangeable, though people mix them up constantly. An IP address is the actual network location, written as four numbers for IPv4 or a longer hexadecimal string for IPv6. A domain name is a human-friendly label that maps to one or more of those addresses.
The label stays put while the address underneath can change. Move a shop's website to a new host and the owner updates one record. Customers keep typing the same name and typically don't notice the switch.
How Does DNS Work? Following One Lookup From Browser to Webpage
Say you type example.com into your browser on a Tuesday morning. Nothing on your laptop knows where that site lives yet, so a short chain of questions begins. Most of it finishes in a fraction of a second, and all you see is the finished page.
The Four Servers Behind Every DNS Lookup
Four kinds of server cooperate on an uncached DNS lookup: a recursive resolver, a root nameserver, a TLD nameserver and an authoritative nameserver. None of them knows the whole answer. The resolver is the one your device talks to. The root server knows who handles .com, .org and every other top-level domain. The TLD server knows which nameservers are responsible for the domain you asked about, and the authoritative nameserver holds the record itself.
Quick Fact: The root zone is served from only 13 addresses, yet the figures published at root-servers.org counted 1,843 server instances behind them in April 2024, run by 12 independent organizations.
Anycast routing is what makes that math work. Many physical machines answer on the same address, and your query reaches a nearby one, which is how a system with 13 addresses survives local failures.
Recursive Resolver vs Authoritative DNS Server
Which one holds the answer, and which one goes looking for it? The authoritative server holds it. It's the source of truth for a domain's records and answers from its own data. A recursive resolver owns no records at all. It hunts them down on your behalf and remembers what it finds. Your ISP runs one, and so do public services such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1.
If you host a website, you deal with the authoritative side through a provider like Amazon Route 53 or your domain registrar. Cloudflare's learning center walks through the same split with diagrams if you want a second explanation.
DNS Resolution Step by Step
DNS resolution is the full trip a name takes before it becomes an address. Here is the sequence when nothing is cached yet.
- You enter example.com. Your browser checks its own cache, then your operating system's stub resolver checks its cache.
- If neither has the answer, the query goes to a recursive resolver, usually run by your ISP or a public DNS provider, which checks its cache next.
- On a miss, the resolver asks a root server. The root doesn't know the IP address but points to the servers for the .com top-level domain.
- The resolver asks a .com TLD server, which replies with the authoritative nameservers for example.com.
- The resolver asks one of those authoritative nameservers, which returns the record containing the IP address.
- The resolver stores the answer for the length of its TTL and passes the IP address back to your device.
- Your browser connects to that IP address and requests the page. That last part is web traffic, not DNS.
The full trip is the exception. Your browser, your operating system and the resolver each keep recent answers, so most lookups end at step 1 or step 2.
Recursive, Iterative and Non-Recursive Queries
Your device sends a recursive query, which demands a final answer or an error. The resolver then works through iterative queries, accepting a referral from each server and following it down the chain. A non-recursive query is the shortcut case: a server answers from its own records or cache without asking anyone else.
DNS Caching and TTL: Why Most Lookups Stay on Your Device
Why doesn't your browser repeat that whole chain for every image and script on a page? It remembers recent answers. Your browser keeps a DNS cache, your operating system keeps another, and the recursive resolver keeps a much larger one shared by every customer using it. The closer the saved answer sits to you, the fewer servers get involved.
The speed difference is measurable. Azion's learning guide puts a full uncached lookup at roughly 20 to 120 milliseconds and a cached one under a millisecond, though real figures shift with network distance and resolver load.
How TTL Decides How Long an Answer Is Remembered
Every record carries a time to live, or DNS TTL, counted in seconds. A TTL of 300 means five minutes. A TTL of 86400 means a full day. Once the timer runs out, the cache drops the answer and asks again.
This is where site owners get burned. Imagine you're moving a store's website to a new host late on a Saturday. If the old record had a 24-hour TTL, some visitors keep landing on the old server until Sunday night, because their resolvers are still serving the saved answer.
Pro Tip: Lower the TTL on the records you plan to change to 300 seconds at least 24 hours before the move, then raise it again once everything is stable.
DNS Records Explained: What an Authoritative Server Stores
An authoritative server is basically a zone file full of records, and each record type has one job. You'll meet these six most often.
| Record type | What it does | Example value |
|---|---|---|
| A | Points a name to an IPv4 address | 192.0.2.44 |
| AAAA | Points a name to an IPv6 address | 2001:db8::1 |
| CNAME | Makes one name an alias of another | www.example.com is an alias of example.com |
| MX | Names the mail server for the domain | mail.example.com |
| TXT | Holds free text, used for SPF, DKIM and domain verification | v=spf1 include:example.net ~all |
| NS | Lists the authoritative nameservers for the domain | ns1.example.com |
One quirk trips up a lot of new site owners. The DNS standard doesn't allow a CNAME at the root of a domain (example.com itself), only on subdomains such as www. Many DNS providers offer ALIAS or ANAME records as a workaround, and Azion's guide covers the same limitation.
How Long Does DNS Propagation Take?
The term DNS propagation suggests your change is being pushed out to servers around the world. Nothing is pushed. Resolvers keep serving the old answer until their cached copy expires, then fetch the new one.
So the wait depends on the TTL that was set before you made the change. With a 300-second TTL, most resolvers pick up an edit within minutes. With 86400, it can take a day. Changing nameservers at your registrar tends to be slower, because TLD delegation records often carry TTLs of around 48 hours, so plan for up to two days.
New records have their own catch. If someone looked the name up before it existed, resolvers can cache the "no such name" answer for a period set in the zone's SOA record, which makes a fresh record look missing for longer than you'd expect. Checking from a public resolver and clearing your local cache usually clears up the confusion.
DNS vs DHCP: Two Systems That Get Mixed Up
Join a coffee shop's Wi-Fi and your phone gets an address, a gateway and a resolver to use within a second or two, with no typing on your part. That's DHCP at work.
DHCP assigns your device an IP address and usually tells it which DNS resolver to ask. DNS then handles the naming, turning the sites you type into addresses. They are separate protocols, yet one routinely hands the other its settings, which is why a flaky DHCP lease can sometimes look like a DNS problem. When you compare DNS vs DHCP in a troubleshooting session, ask which of the two failed first.
Does DNS Affect Website Speed?
Yes, but usually by a small amount, and mostly on the first visit. The lookup happens before your browser can request the page at all, so a slow resolver or a distant authoritative server adds delay to everything that follows.
Two habits make it worse. Long chains of CNAME records force extra lookups, since each hop is another query. Very low TTLs make caches expire more often, so visitors repeat those cold lookups more frequently. That's the trade-off behind the migration advice earlier: short TTLs are useful for a few days around a change, and a poor default the rest of the year.
What Happens When DNS Fails or Goes Down?
What You See on Your Screen
Browsers show a "site can't be reached" page, often with a code such as DNS_PROBE_FINISHED_NXDOMAIN. The site's servers are usually fine. Only the name lookup failed. NXDOMAIN means the resolver was told the domain doesn't exist, which can come from a typo, an expired registration or broken nameserver settings.
If you see a DNS not responding message, test a different network first, then try to flush the DNS cache on your device. On Windows, run ipconfig /flushdns in Command Prompt. Switching to another public resolver for a minute also tells you whether your usual one is the culprit.
Outages can look patchy. Sites already sitting in a resolver's cache often keep loading for a while, so some pages fail while others work until their saved answers expire.
A Real Case: One Empty Record Inside AWS
Honestly, this is the incident I'd show anyone who thinks DNS is boring plumbing. According to Amazon's own post-event summary, a disruption in its Northern Virginia region ran from 11:48 PM PDT on October 19, 2025 to 2:20 PM PDT on October 20. The root cause was a race condition in the DNS management system for DynamoDB that left an incorrect empty record for the service's regional endpoint, and the automation failed to repair it.
Clients couldn't resolve the endpoint, so they couldn't connect, and the failure spread to other services that depend on DynamoDB. The database itself wasn't the first thing to break. The name pointing to it was.
For your own sites, the lesson is practical. Monitor DNS answers from outside your network, keep a second DNS provider in mind for anything revenue critical, and don't set TTLs so low that a provider outage empties every cache within minutes.
DNS Security and Privacy: DNSSEC, DoH and DoT
DNSSEC: Proving an Answer Is Genuine
DNSSEC adds cryptographic signatures to DNS records so a resolver can check that an answer wasn't forged or altered on the way. It makes cache poisoning and spoofing meaningfully harder, though it only helps when both the domain owner and the resolver support it. It does not encrypt anything, a point Azion's guide also stresses.
DNS over HTTPS and DNS over TLS: Hiding the Question
Traditional DNS queries travel in plain text, typically over UDP port 53, so anyone on the path, such as an ISP or a hotspot owner, can see which names you look up. DNS over HTTPS (DoH) wraps the query in an encrypted HTTPS connection, as defined in RFC 8484. DNS over TLS does something similar on a dedicated port.
There's a trade-off. You stop trusting the network with your lookups and start trusting your chosen resolver instead, and the IP address you connect to afterward is still visible to the network. On public Wi-Fi I'd turn encrypted DNS on. At home, it comes down to whether you trust your ISP or the resolver more. Major browsers include a setting for it.
Should You Change Your DNS Server?
Your router usually hands out your ISP's resolver by default. Switching to a public resolver can help if the ISP's one is slow or unreliable, and you can test that by timing a few lookups before and after. It rarely changes download speed, since DNS only covers the name lookup. If you do change your DNS server, set it on the router so every device inherits it, and write down the old values in case you need to revert.