What Is DNS? How Does the Domain Name System Work?
DNS is the phonebook of the internet. Every time someone visits a website, sends an email, or connects to any internet service, DNS translates the human-readable name into the numerical address the network actually uses. Here's how it works — and why monitoring your DNS records is one of the most critical things you can do for client infrastructure.
Key takeaways
- DNS translates domain names into IP addresses and controls email routing, SSL issuance, and more.
- A single domain can have dozens of records — each one a potential point of failure.
- DNS changes propagate globally within minutes, often with no visible warning to anyone involved.
- Unauthorised DNS changes are the vector behind account takeovers, email hijacking, and phishing attacks.
In this article
What DNS is — and what it controls
Every device on the internet communicates using IP addresses — machine-readable numbers like104.21.57.84. DNS (Domain Name System) is the globally distributed database that maps human-readable names like aideworks.com to those numbers.
Without DNS, every website visit would require memorising numeric addresses. More critically, changing a server's IP address would silently break every link, every bookmark, and every configuration that pointed to the old address — forever.
But DNS does far more than IP address mapping. The same infrastructure controls:
- Which mail servers receive email for your domain (MX records)
- Which Certificate Authorities are permitted to issue SSL certificates for your domain (CAA records)
- Email sender authentication policies that prevent spoofing (SPF and DMARC via TXT records)
- Domain ownership verification tokens for Google, Microsoft, and other third-party services (TXT records)
- Subdomain aliases and load balancing (CNAME records)
This means a single DNS zone — a few dozen text records — controls the entire operational surface of a domain. Change one record incorrectly, and email stops, websites go down, or worse: traffic routes somewhere it shouldn't.
How a DNS query works, step by step
When a browser needs to resolve app.aideworks.com, it follows a chain of servers until it finds an authoritative answer:
Local cache
The OS checks its own DNS cache. If a recent answer exists and the record's TTL (Time To Live) hasn't expired, the lookup stops here without touching the network.
Recursive resolver
If the cache misses, the query goes to a recursive resolver — usually your ISP's server or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google). The resolver acts on your behalf to find the answer.
Root nameservers
If the resolver has no cached answer, it asks one of the 13 root nameserver clusters (a.root-servers.net through m.root-servers.net, each backed by hundreds of anycast servers globally). They don't know the IP — but they know who is authoritative for .com.
TLD nameservers
The .com (or .nl, .io, .org…) nameservers know which nameservers are authoritative for each second-level domain. They return the NS records for the specific domain.
Authoritative nameservers
The domain's own nameservers — hosted at a DNS provider like Cloudflare, AWS Route 53, or a registrar — hold the actual record values and return the authoritative answer.
Response cached
The recursive resolver caches the result according to the TTL on the record. Subsequent queries for the same record skip the chain entirely until the TTL expires.
The entire chain from browser to authoritative nameserver — in a cold cache scenario — typically completes in 20–120 ms. Subsequent lookups for the same record are served from cache in under 1 ms.
DNS record types you need to know
Each record type serves a specific purpose. Understanding what each one controls helps you understand why a change to it can be catastrophic:
| Type | Purpose | If changed unauthorised |
|---|---|---|
A | Maps a hostname to an IPv4 address | Website traffic redirected |
AAAA | Maps a hostname to an IPv6 address | IPv6 traffic redirected |
CNAME | Alias from one hostname to another | Subdomain traffic redirected |
MX | Mail server(s) for the domain | Email delivery broken or hijacked |
TXT | Arbitrary text — SPF, DMARC, site verification tokens | Email auth failure, verifications lost |
NS | Authoritative nameservers for the domain | Full DNS control transferred |
CAA | Which CAs may issue SSL certs for the domain | Unauthorised certificates may be issued |
SOA | Zone metadata, serial number, refresh intervals | Zone transfer failures |
TTL — why propagation takes time
Every DNS record has a TTL (Time To Live) value, measured in seconds. This tells resolvers how long to cache the record before checking for a new value:
- TTL 300 (5 minutes) — Record changes are visible globally within 5 minutes. Good for dynamic infrastructure, but increases DNS query volume to your nameservers.
- TTL 3600 (1 hour) — The most common default. Record changes take up to an hour to reach all resolvers worldwide.
- TTL 86400 (24 hours) — Used for stable records like NS entries. Changes take up to a day to propagate — good for stability, bad for incident response.
A common mistake is lowering the TTL immediately before a planned migration, making the change, then forgetting to raise it again — leaving records with a 60-second TTL permanently, generating unnecessary load and signalling instability to monitoring tools.
Why DNS changes are so dangerous
DNS attacks don't look like attacks. There's no malware, no crashed service, no error message visible to anyone managing the domain — just traffic quietly routing somewhere it shouldn't.
Common DNS attack vectors
- ›A record manipulation: Redirects website visitors to a phishing copy. Especially effective if the attacker also obtains a DV certificate for the domain — visitors see a valid HTTPS padlock.
- ›MX hijacking: Routes all incoming email to an attacker-controlled server. Password resets, invoices, and client communications are silently intercepted.
- ›NS takeover: The most severe attack. Changing NS records transfers full control of every DNS record to an attacker. Possible when a domain registrar account is compromised.
- ›Subdomain takeover: A CNAME pointing to a decommissioned service (old Heroku app, GitHub Pages site, Azure endpoint) can be claimed by an attacker, giving them a valid hostname under your domain.
- ›Accidental changes: A developer drops a record during migration. An SPF record is edited and a character is removed. A TTL is set to 86400 during a planned change and left indefinitely. Without a baseline, you can't tell the difference until someone calls.
What Aideworks monitors
Aideworks continuously polls all DNS record types for every domain in your account, comparing them against a fingerprinted baseline:
- Full record tracking — A, AAAA, CNAME, MX, TXT, NS, CAA, SOA across every monitored subdomain.
- NS changes are critical-severity — any nameserver change triggers an immediate high-priority alert, since NS changes represent full loss of DNS control.
- MX and TXT alerts are high-priority — they affect email delivery and authentication.
- Multi-region polling — checks run from multiple geographic locations to catch propagation inconsistencies.
- Historical change log — every change is stored with timestamp, old value, and new value — a complete audit trail for incident analysis.
Monitor your DNS with Aideworks
Add any domain and Aideworks tracks all its DNS records automatically — alerting you the moment anything changes, before your clients notice.
Start monitoring free →