# What is DNS? Records, resolvers and TTLs in plain language

> DNS turns the names people type into the addresses machines connect to. How a lookup really travels, every record type that matters, TTLs, caching and the commands to see it yourself.

Updated 2026-10-11 · Best practices · HTML version: https://getreport.app/guides/what-is-dns

DNS, the Domain Name System, is the internet's naming system: it translates the domain names people type, such as `example.com`, into the IP addresses machines connect to, such as `203.0.113.10`. Every website visit, every email and most app requests start with a DNS lookup, usually finished in a few milliseconds before anything else happens. You rent a name once a year at a registrar; DNS is what makes that name mean something, every second, everywhere.

This guide is the map of the whole topic for whoever looks after a domain. By the end you will know how a lookup actually travels, what each record type does with a real example of each, what TTLs and "propagation" really are, who controls what between your registrar and your DNS host, and how to read your own records with `dig`: enough to change DNS without fear and to know where to look when it breaks.

## Quick answer

- **DNS translates names to addresses.** `example.com` → `203.0.113.10`. Machines route by IP address; people remember names; DNS connects the two.
- **A lookup is a chain of referrals**: your device asks a recursive resolver, which asks a root server, then the `.com` servers, then your domain's own nameservers; with caching at every step.
- **Eight record types cover almost everything**: A and AAAA (addresses), CNAME (alias), MX (incoming mail), TXT (text, mostly proofs like SPF), NS (which servers answer for the domain), SOA (zone metadata), CAA (which certificate authorities may issue).
- **TTL is how long an answer may be cached**, in seconds. 300 s to 3,600 s suits most records; drop it to 300 s a day before any planned change.
- **"Propagation" is not pushing**: it is old answers expiring from caches, so it takes at most the old TTL, not a mystical 48 hours.
- **Check yourself** with `dig` (or `nslookup` on Windows), and run the free [email and DNS health check](https://getreport.app/tools/email-dns-check) for the mail-critical records.

## What DNS actually is

Forget the image of one big directory that somebody looks your name up in. DNS works more like asking for directions in a well-organised city where nobody knows the whole map, but everyone knows exactly who to ask next. The root servers don't know where `example.com` is: they know who answers for `.com`. The `.com` servers don't know either; they know which nameservers answer for `example.com`. Only that last stop, your domain's **authoritative** nameservers, holds the actual records.

Technically, DNS is a distributed, hierarchical database, defined in RFC 1034 and RFC 1035 back in 1987 and still running on the same design. "Distributed" means no single machine holds it and no single failure stops it. "Hierarchical" means authority is delegated downwards: the root delegates `.com` to its registry, the registry delegates `example.com` to your nameservers, and you can delegate `internal.example.com` further if you want. Each delegated slice is called a **zone**, and the records in it are what this guide is about.

One name can hold many records at once: an A record for the website, MX records for mail, TXT records proving things to Google and mail receivers. A lookup always asks for a specific **type**, which is why your site can be fine while your mail records are broken, and the other way round.

## How a DNS lookup actually travels

Type `example.com` into a browser and this happens, usually in under 50 ms:

1. **The stub resolver asks.** Your device's operating system has a tiny DNS client, the stub resolver. It checks its own cache and the browser's, and if the answer isn't there, sends the question to the recursive resolver your network is configured with: your router, your ISP, or a public one such as Cloudflare's `1.1.1.1`, Google's `8.8.8.8` or Quad9's `9.9.9.9`. The stub does no detective work; it asks one server and waits.
2. **The recursive resolver does the legwork.** If the answer is in its cache (someone nearby asked recently), it answers instantly. If not, it starts at the top.
3. **A root server refers it onwards.** The resolver asks one of the root servers, which doesn't know `example.com` but replies with the list of servers for `.com`.
4. **The TLD server refers it again.** The `.com` registry's servers reply with the nameservers registered for `example.com`: the NS records your registrar holds.
5. **The authoritative server answers.** Your domain's nameservers hold the zone and return the actual record: `example.com A 203.0.113.10`, with a TTL saying how long that answer may be reused.

The answer then flows back down the chain, and **every step caches it** for the TTL: the recursive resolver, the operating system, the browser. Caching is why step 2 ends the story for almost every real lookup; the full root-to-authoritative walk happens only when every cache is cold. It is also why a changed record takes time to be seen everywhere, which is the whole "propagation" story below.

![How a DNS lookup travels: the stub resolver in the browser and OS asks a recursive resolver, which walks from a root server to the .com TLD servers to the domain's authoritative nameserver, with a cache at each hop](https://getreport.app/guides/img/what-is-dns/diagram.svg "Almost every real lookup stops at a cache; the full walk to the root happens only when every cache is cold.")

Two directions of travel are worth naming. A **recursive query** is what the stub sends: "get me the full answer, however many steps it takes". An **iterative query** is what the resolver sends upwards: each server either answers or refers it one level closer. DNS runs on port 53 over UDP, falling back to TCP for large answers; modern devices and browsers increasingly send the same questions encrypted, as DNS over HTTPS or DNS over TLS, to the same kinds of resolver.

## The DNS record types that matter

Zones can hold dozens of record types, but these eight do nearly all the work. Each example is one real line in zone-file form: name, TTL in seconds, class (always `IN`), type, value.

| Type | Job | Example |
| --- | --- | --- |
| **A** | Name → IPv4 address | `example.com. 3600 IN A 203.0.113.10` |
| **AAAA** | Name → IPv6 address | `example.com. 3600 IN AAAA 2001:db8::10` |
| **CNAME** | Alias: "this name is that name" | `www.example.com. 3600 IN CNAME example.com.` |
| **MX** | Who receives mail, with priority (lower first) | `example.com. 3600 IN MX 10 smtp.google.com.` |
| **TXT** | Free text, mostly machine-read proofs | `example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"` |
| **NS** | Which nameservers answer for the zone | `example.com. 86400 IN NS ns1.example-dns.net.` |
| **SOA** | Zone metadata: primary server, contact, serial, negative-answer TTL | `example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. 2026101101 7200 3600 1209600 300` |
| **CAA** | Which certificate authorities may issue for the name | `example.com. 3600 IN CAA 0 issue "letsencrypt.org"` |

A few of these deserve a sentence more:

- **A CNAME replaces every other record at that name.** RFC 1034 forbids a CNAME next to anything else, and the lookup restarts at the target, inheriting all its records. That is fine for `www`, and exactly why it fails at the apex: next section.
- **MX records point to names, never to IP addresses**, and the priority number picks the order: senders try the lowest first. Mail works without MX only by accident; the [MX records fix page](https://getreport.app/learn/mx-records) covers the details.
- **TXT is where the rest of the internet asks you to prove things**: SPF for mail, site-verification strings for Google and Microsoft, DMARC at `_dmarc`, DKIM keys under `_domainkey`. A domain with email ends up with more TXT records than anything else.
- **NS records exist twice**: at the `.com` registry (put there by your registrar; that is the delegation) and in your own zone. They should match, and their TTLs run long: the `.com` zone hands them out with a 2-day TTL, which is where the "48 hours" folklore comes from.
- **The SOA's last field sets negative caching**: how long resolvers may remember "this name does not exist" (RFC 2308). Set it long and a typo'd record you just fixed stays invisible for that long.
- **CAA is cheap insurance.** Certificate authorities have been required to check it before issuing since September 2017 (CA/Browser Forum ballot 187), so one line limits who can get a certificate in your name.

### The apex problem: ALIAS, ANAME and CNAME flattening

The bare domain (`example.com`, the **apex**) must hold SOA and NS records, so it cannot be a CNAME. But modern hosting wants exactly that: "point your domain at `your-app.hosting-provider.com`", whose IP addresses change. DNS providers solve it with a non-standard trick sold as **ALIAS**, **ANAME** or **CNAME flattening**: you enter what looks like a CNAME, the provider resolves the target itself and serves the result as plain A/AAAA records. It works well; just know it is a provider feature, not a standard, so it does not transfer between DNS hosts. The standardised long-term fix is the HTTPS record type (RFC 9460), which browsers already query on every lookup, but provider ALIAS remains the practical answer in 2026.

## TTLs: how long an answer lives

Every record carries a TTL, time to live, in seconds: how long any cache may reuse the answer without asking again. A TTL of 3600 means a visitor's resolver can serve your old IP address for up to an hour after you change the record. That is the entire trade-off: long TTLs mean fewer lookups, faster repeat visits and resilience when your nameservers blip; short TTLs mean changes land fast but every cache comes back sooner.

Sensible defaults: **300 s to 3,600 s (5 minutes to 1 hour)** for records you may need to move, such as A/AAAA records behind which servers change; **3,600 s to 86,400 s (1 hour to 1 day)** for records that change rarely, such as MX and TXT. Many DNS hosts default to "auto" (Cloudflare serves 300 s for proxied records), which is fine to leave alone.

The one habit worth building: **before any planned change, lower the TTL first and wait out the old TTL**. Dropping an A record from 86,400 s to 300 s the day before a migration means the actual switch completes worldwide in about 5 minutes instead of a day. Raise it again once the change has settled. Going below about 300 s buys little: some resolvers quietly enforce minimums, and you pay in lookup volume for every visitor.

## DNS propagation is really cache expiry

"Waiting for DNS to propagate" suggests your change is being pushed around the world. It is not. Nothing is pushed anywhere: your authoritative server answers with the new value the moment you save. What takes time is every cache that holds the **old** answer serving it until its TTL runs out. Propagation is expiry.

That makes the maths honest: a record with a 3,600 s TTL is fully switched everywhere at most 1 hour after you change it, because no cache was allowed to keep the old answer longer. The famous "allow 24-48 hours" applies to one specific case: changing **nameservers** (moving DNS hosts), because the NS records at the TLD registry carry long TTLs (2 days in the `.com` zone) and you cannot lower those yourself. For ordinary record edits on the same DNS host, propagation is just your own TTL.

Two things muddy the picture. A few resolvers (some ISPs, some corporate networks) ignore short TTLs and cache longer than they should: rare, but real, and the reason to keep both old and new endpoints alive during a migration rather than cutting the old one off at the hour mark. And your own machine has caches below the resolver: the OS and browser keep answers too, which is why "it still shows the old site for me but nobody else" is almost always local. If you are moving a whole site to a new name, DNS is only step one; the guide to [changing domains without losing SEO](https://getreport.app/guides/domain-change-seo) covers the rest.

## Registrar, DNS host, nameservers: who controls what

Three roles get mixed up constantly, partly because one company often plays all three:

- **The registry** runs a TLD. Verisign runs `.com`; every country code has an operator. You never deal with a registry directly.
- **The registrar** is where you bought the domain: it records your ownership with the registry, renews it, and holds exactly one DNS-shaped power: which **nameservers** the registry lists for your domain. That NS delegation is the master switch.
- **The DNS host** runs the authoritative nameservers that hold your actual records. This is where you add A, MX and TXT records day to day.

By default your registrar is also your DNS host, which is why the distinction stays invisible until you change one without the other. Point the nameservers at Cloudflare and every record you later edit at the registrar does nothing: the registry sends resolvers to Cloudflare, full stop. Equally, your web host is usually **neither**: "hosted at provider X" just means some A record points there.

The practical rule for any confusing DNS situation: find out which nameservers the registry currently lists (`dig NS yourdomain.com`; next section), and edit records **there**. Everything else is a stale copy.

## Reading DNS yourself: dig and nslookup

`dig` (macOS and Linux; Windows via WSL) asks DNS questions and shows the raw answers. `nslookup` ships with Windows and covers the basics. The five commands worth memorising:

```bash
dig example.com                  # full answer with status, flags and TTLs
dig +short example.com           # just the A record values
dig +short MX example.com        # any type works: MX, TXT, NS, AAAA, CAA, SOA
dig @1.1.1.1 example.com         # ask a specific resolver instead of your default
dig +trace example.com           # walk root → TLD → authoritative yourself
```

In a full `dig` answer, three things tell you most of the story. The **status** in the header: `NOERROR` means the name exists, `NXDOMAIN` means it does not, `SERVFAIL` means the resolver could not get a trustworthy answer (often broken nameservers or failing DNSSEC). The **ANSWER section** lists records as `name TTL class type value`; the same shape as the table above. And the **TTL column counts down** on cached answers: run the same query twice against the same resolver and watch the number shrink, which is caching made visible.

Comparing resolvers is the fastest propagation check: `dig @1.1.1.1` versus `dig @8.8.8.8` versus plain `dig` shows whether a change has reached the big public caches while your ISP still serves the old value. On Windows without WSL:

```powershell
nslookup example.com             # A and AAAA records
nslookup -type=TXT example.com   # any type via -type=
nslookup example.com 1.1.1.1     # ask a specific resolver
```

There is more to reading answers (authority sections, `+dnssec`, chasing CNAME chains) than fits in a pillar, and a dedicated guide to DNS lookups is planned.

## Check your DNS records

> **Free tool:** [DMARC checker: free SPF, DKIM and MX record check](https://getreport.app/tools/email-dns-check): Free DMARC checker that also tests SPF, DKIM and MX. See what is missing or broken and get the exact DNS records to add. No sign-up, results in seconds.

The check covers the records your email depends on: the part of DNS where silent breakage costs real money. It reads your MX, SPF, DMARC, MTA-STS, TLS-RPT and BIMI records, follows every SPF include to the end, tries 27 common DKIM selectors, and checks DNSSEC. Every problem comes with the exact record to paste, written for your provider when the MX records reveal it. It reads public DNS only and sends no mail.

> **Check: Mail servers (MX).** Without an MX record, mail sent to your address bounces or is guessed from the website's address. Mailbox providers also trust domains that receive mail more than send-only ones.
>
> 1. Add the MX records your email provider lists (Google Workspace, Microsoft 365, Zoho and your host all publish them) in your DNS zone.
> 2. If the domain never receives email, publish a null MX ("0 .") so senders fail fast instead of retrying.

For records the check does not cover (A, AAAA, CNAME, CAA) `dig` from the previous section answers in seconds, and `dig @1.1.1.1` versus your default resolver shows whether a recent change has landed.

## DNS and email

Email leans on DNS harder than the web does: MX records say who receives your mail, and three TXT-based records prove the mail you send is really yours. SPF lists your allowed sending servers, DKIM publishes the keys that sign your messages, and DMARC ties both to the visible From address and tells receivers what to do when they fail. Gmail, Yahoo and Outlook now require them from any serious sender, so these are the DNS records with a deadline attached.

The detail lives in its own topic: the pillar on [SPF, DKIM and DMARC email authentication](https://getreport.app/guides/spf-dkim-dmarc-email-authentication) maps all of it, the [SPF record guide](https://getreport.app/guides/spf-record) goes through that record's syntax term by term, and the [DMARC guide](https://getreport.app/guides/what-is-dmarc) covers your first `_dmarc` record and policies. If you only do one thing after reading this page, run the email check above; a missing or doubled SPF record is the most common serious DNS problem we see.

## When DNS fails

When DNS breaks, it does not look like DNS: it looks like the site vanished. Browsers show `DNS_PROBE_FINISHED_NXDOMAIN` when the name cannot be resolved at all, and the causes split cleanly: for a visitor it is usually their own resolver or network; for the owner it is an expired domain, wrong nameservers after a move, or a typo'd record. `SERVFAIL` points at the nameservers themselves or at broken DNSSEC, and a lapsed registration takes mail down with the website, which is the expensive part.

The dedicated guide to [DNS_PROBE_FINISHED_NXDOMAIN](https://getreport.app/guides/dns-probe-finished-nxdomain) has the visitor-side fix in two minutes and the owner-side diagnosis in order of likelihood. The short version of the owner path: check the domain has not expired, check the registry's NS records point where you think (`dig NS yourdomain.com`), then check the record itself exists at that DNS host.

Chrome often wraps all of this in one message, "This site can't be reached", with a code underneath that says which step failed. [This site can't be reached: every variant of the Chrome error](https://getreport.app/guides/this-site-cant-be-reached) maps each code to the layer behind it, DNS or otherwise.

## DNS security basics

Classic DNS has no proof of origin: a resolver asks a question over the network and believes whichever answer comes back, which enables forged answers that send your visitors or your mail somewhere else. **DNSSEC** fixes that by signing records: your DNS host signs the zone, a DS record at the registry links your keys into the chain of trust, and validating resolvers reject answers whose signatures fail. It is authenticity only; DNSSEC does not encrypt anything or hide what you look up.

The honest picture in 2026: turning it on is one switch at most big DNS hosts (plus pasting the DS record at the registrar when it is a separate company), validation is on by default at the big public resolvers, and the main real-world risk is operational; move DNS hosts while forgetting the old DS record and validating resolvers answer `SERVFAIL` for your whole domain until it is removed. Turn it on, and put "remove the DS record first" on your checklist for any future DNS-host move. The [DNSSEC fix page](https://getreport.app/learn/dnssec) has the test and the per-provider steps.

> **Check: DNSSEC protects the domain's DNS answers.** DNSSEC signs your DNS records so resolvers can reject forged answers, the attack behind hijacked websites and intercepted mail. Most registrars turn it on with one switch.
>
> 1. Turn on DNSSEC at your DNS host (Cloudflare, most registrars and hosts have a switch) and, if the registrar is separate, add the DS record it gives you there.

Two cheaper habits close most of the remaining gap. **Registrar lock** (the `clientTransferProhibited` status, on by default at good registrars) stops your domain being transferred away without you unlocking it first; check it is on, and treat the email account your registrar talks to as critical infrastructure, because whoever controls that controls everything on this page. And a **CAA record** (the one-liner from the table above) stops certificate authorities other than yours issuing certificates for your name.

## WHOIS and RDAP: who owns a domain

Every registration carries public metadata: registrar, creation and expiry dates, nameservers, and contact details that privacy rules have mostly redacted since 2018. The old WHOIS protocol is being retired in favour of RDAP, which serves the same data as structured JSON; ICANN ended the contractual requirement for registrars to run WHOIS in January 2025, so expect RDAP-based lookup pages. The two fields worth a regular glance are the **expiry date** and the **nameservers**, because both failure modes above start there. A fuller guide to reading WHOIS and RDAP data is planned.

## Does domain age matter?

Less than the folklore says. A domain's registration date is public, and older domains often rank better, but Google has said for years that age itself is not a ranking factor; old domains simply tend to have accumulated links, content and history. Where age does bite: brand-new domains sending email start with no reputation and get filtered harder for their first weeks, and registering a domain for multiple years signals nothing to search engines but does protect you from the expiry failure mode. A dedicated guide with the evidence is planned.

## Questions people ask

### What is DNS in simple terms?

DNS is the internet's naming system: it translates the domain names people type, like example.com, into the IP addresses machines actually connect to, like 203.0.113.10. It works as a chain of referrals; root servers point to the servers for .com, which point to your domain's own nameservers, which hold the answer. Every website visit and email starts with a DNS lookup.

### How does a DNS lookup work?

Your device asks a recursive resolver (your ISP's or a public one like 1.1.1.1). If the answer is cached, it comes back instantly; if not, the resolver asks a root server, which refers it to the TLD's servers, which refer it to your domain's authoritative nameservers, which answer. Every step caches the result for the record's TTL, so most lookups never travel the full chain.

### What are the most common DNS record types?

Eight types do nearly all the work: A and AAAA map a name to an IPv4 or IPv6 address, CNAME makes one name an alias of another, MX names the servers that receive your mail, TXT holds machine-read text such as SPF, NS names your authoritative nameservers, SOA carries zone metadata, and CAA limits which certificate authorities may issue for your domain.

### What is a DNS resolver?

A resolver is the server that answers DNS questions for you. The stub resolver built into your device sends every question to a recursive resolver (run by your ISP, your router or a public service such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8) which walks the chain from root to authoritative servers and caches the answers so repeat lookups are instant.

### How do I check my DNS records?

Run `dig example.com` in a terminal for A records, or `dig +short TXT example.com` for any other type; on Windows, `nslookup -type=TXT example.com` does the same. Asking a specific resolver, like `dig @1.1.1.1`, shows whether a change has reached public caches. For the email-critical records (MX, SPF, DKIM, DMARC) the free email and DNS health check reads them all at once.

### What happens when DNS is down?

The site becomes unreachable even though the server is running fine: browsers show DNS_PROBE_FINISHED_NXDOMAIN or a resolver error instead of the page, and mail bounces or queues because senders cannot find your MX records. Cached answers keep working until their TTLs expire, so an outage hits gradually. The usual owner-side causes are an expired domain, broken nameservers or failed DNSSEC validation.

### Who runs the DNS root servers?

Twelve organisations operate the 13 named root servers, a.root-servers.net through m: among them Verisign (which runs two), NASA, the University of Maryland, RIPE NCC and ICANN itself. Each name is really hundreds of anycast copies spread worldwide, over a thousand instances in total; root-servers.org maps them. ICANN's IANA function manages the root zone's contents, and changes to it are signed.