What Is DNS and How Does It Work?
DNS, the Domain Name System, is the service that turns names people can remember into addresses computers can reach. When you type a shop or news address into a browser, DNS looks up the matching IP address and sends your request to the right server, all in a fraction of a second. Without it, you would need to memorise strings of numbers for every site you visit. This guide explains what DNS records are, how a lookup travels from your device to the answer, and how long changes take to spread. If you are still choosing a name, start with our free domain search, and browse the wider set in our guides.
You will learn the four records almost every site owner meets (A, CNAME, MX, and TXT), the four-step resolution path, and what propagation really means when you point a domain at new hosting. The examples use small fictional businesses so the numbers stay concrete. By the end, a DNS settings page should look like a simple address book rather than a wall of codes, and you will know which values to check first when a site or mailbox stops responding.
What Is DNS?
DNS is a distributed directory for the internet. Its core job is name-to-address translation: it maps a domain such as a shop name to an IP address such as 192.0.2.10, which identifies the server. The system is distributed, meaning no single computer holds every answer. Instead, millions of servers each hold parts of the directory and refer questions to one another until the answer is found. This design spreads load and avoids a single point of failure.
Several roles take part. A recursive resolver, usually run by your internet provider or a public service, does the legwork of asking around on your behalf. Root servers answer the first question: which servers handle a given ending such as .co.za or .com. TLD servers for that ending then point to the domain's authoritative nameservers, which hold the actual records. Authoritative answers are the final word for a domain, while cached copies held by resolvers speed up repeat visits.
People sometimes mix DNS up with neighbouring services. Domain registration, explained in our guide to WHOIS lookups, records who owns a name. Web hosting stores the site files. DNS sits between them: it directs visitors from the name to the hosting. You can register a name in one place, host the site in another, and handle email in a third, with DNS records steering each stream to its destination.
Why DNS Matters
First, DNS controls whether your site and email work at all. A missing or mistyped A record means browsers cannot find the server, so visitors see errors instead of pages. A wrong MX record sends incoming mail to the wrong place or nowhere. Because nearly every online action starts with a lookup, even small record errors have large effects. Knowing the basics lets you spot these faults instead of waiting days on support queues.
Second, DNS affects speed. Resolvers cache answers, so repeat visits skip most of the lookup chain and connect faster. The TTL value on each record sets how long caching lasts. Short TTLs let you move servers quickly but force more fresh lookups. Long TTLs speed up steady sites but slow down emergency moves. Site owners who understand this trade-off plan migrations calmly instead of during an outage.
Third, DNS carries trust signals. TXT records publish email policies such as SPF, DKIM, and DMARC, which help receiving servers tell genuine mail from forgeries. Search engines also need stable, correct records to crawl and index a site. A domain whose DNS is tidy, with one clear www setup and no stray records, gives both visitors and crawlers a reliable path in. That reliability supports everything else you build, from content to the marketing tracked with tools like a UTM builder.
How DNS Works
A lookup follows the same four steps each time. Step one: your browser asks the configured recursive resolver for the address of the name. Step two: if the resolver has a fresh cached answer, it replies at once; if not, it asks a root server, which points to the right TLD servers. Step three: the resolver asks the TLD servers, which point to the domain's authoritative nameservers. Step four: the resolver asks the authoritative nameserver, receives the record, caches it for the TTL period, and hands the address to your browser. The whole chain often completes in well under a tenth of a second.
Records are the entries the authoritative server returns. An A record maps a name to an IPv4 address, for example shop.example pointing to 192.0.2.10. An AAAA record does the same for the longer IPv6 addresses. A CNAME record maps one name to another name, so blog.example can point at hosting.example and follow wherever that target leads; note that a CNAME cannot sit alongside other records on the same name, which is why the bare domain usually uses an A record instead. An MX record names the servers that accept incoming mail and carries a priority number, where lower numbers are tried first. A TXT record holds free text used for verification and email policy, including SPF, DKIM, and DMARC entries.
Two supporting records appear often. NS records list the authoritative nameservers for the domain, which is how delegation works: the TLD points at these names, and they answer for everything below. The SOA record holds zone settings including the serial number and timing values. TTL, the time to live in seconds, rides on every record and tells resolvers how long to cache it. A TTL of 3600 means one hour; 86400 means a full day.
Propagation is simply caches catching up. When you change a record, resolvers that cached the old value keep serving it until its TTL expires. That is why some visitors see the new site while others see the old one for a while. Lowering the TTL to 300 seconds (five minutes) a day or two before a planned move shortens this window, since caches then refresh quickly. After the move succeeds, you can raise the TTL again for normal speed.
Examples
Imagine a fictional bakery, example-bakery.co.za, moving to a new host. The owner lowers the TTL to 300 two days early, then on moving day updates the A record for the bare domain to the new address 203.0.113.40 and sets the www CNAME to point at the host's target. Mail stays with the current provider, so MX records are left untouched. Within minutes many visitors reach the new server, and within a few hours nearly all caches have refreshed. The arithmetic of the window is simple: worst-case wait roughly equals the old TTL plus resolver behaviour, so planning around TTL values removes the mystery.
| Record | Example value | Job |
|---|---|---|
| A (bare domain) | 203.0.113.40 | Sends visitors to the web server (IPv4) |
| AAAA (bare domain) | 2001:db8::40 | Sends visitors to the web server (IPv6) |
| CNAME (www) | hosting.example.net | Points www at the host target name |
| MX (priority 10) | mail.provider.example | Directs incoming email (tried first) |
| MX (priority 20) | mail2.provider.example | Backup mail server if the first is down |
| TXT (SPF) | v=spf1 include:provider.example -all | Lists servers allowed to send your mail |
| TTL | 300 to 86400 seconds | How long resolvers may cache the record |
A second example covers email setup for a small consultancy. The provider asks for three changes: an MX record pointing at their mail server with priority 10, a TXT record containing the SPF policy, and a second TXT record with a DKIM key. Each entry is pasted exactly as given, since one wrong character breaks verification. Mail testing then shows messages passing checks. The lesson generalises: DNS values are copied, not invented, and the provider's setup page is the source of truth. For developers formatting such values in code or configs, a JSON formatter can help keep pasted data tidy.
Common Mistakes
Editing the wrong nameservers. Records only take effect where the domain is delegated. If the domain points at the registrar's nameservers but you edit records at the host, nothing changes. Always confirm which NS set is live first, then edit in that panel only.
Putting a CNAME on the bare domain. The bare (apex) domain needs records such as A, MX, and TXT side by side, but a CNAME cannot share its name with other records. Use an A record (or the provider's special apex option) for the bare domain and reserve CNAMEs for subdomains such as www.
Forgetting email records during a move. Site migrations often update the A record while MX and TXT entries get dropped or mistyped, which silently breaks mail. Copy all mail-related records before touching anything, and verify sending and receiving after the change.
Panicking during normal propagation. Checking the site thirty seconds after saving and seeing the old page is normal, not failure. Confirm the authoritative record is correct, then allow up to the old TTL before troubleshooting further. Testing with a fresh network or mobile data can show whether the issue is just a local cache.
Typing values by hand. IP addresses, hostnames, and TXT strings must match exactly. Paste provider values rather than retyping them, and read back each character group. A single transposed digit in an A record sends visitors to a stranger's server or nowhere at all.
Frequently Asked Questions
What is DNS in simple terms?
DNS is the system that translates domain names into IP addresses. You type a readable name, DNS finds the numeric server address, and your browser connects. It functions like a contacts list for the internet.
What is the difference between A and CNAME records?
An A record points a name directly to an IPv4 address, such as 203.0.113.40. A CNAME points one name to another name, so subdomains like www can follow a hosting target without repeating the address.
How long does DNS propagation take?
Most changes are widely visible within a few hours, but full propagation can take up to 48 hours. The old TTL value and each resolver's caching behaviour set the pace, so plan moves around TTL values.
What is a TTL in DNS?
TTL means time to live: the seconds a resolver may cache a record before asking again. A TTL of 300 allows fast changes, while 86400 favours speed for stable records. Lower it before planned moves.
Why does my new domain not load yet?
Work through the layers: registration still provisioning, nameservers not yet delegated, a missing A record, or a cached negative answer. Verify each step at the authoritative server before assuming propagation is the cause.
Do DNS changes affect my email?
Yes. MX records route incoming mail and TXT records carry sender policies, so careless edits can stop delivery. Back up working values before changes and test both sending and receiving afterwards.
Related Tools
- Domain Search, check name ideas and availability before setting up records.
- JSON Formatter, tidy API and config output when working with DNS data.
- Word Counter, draft clear change notes for clients during migrations.
- Password Generator, secure registrar and hosting logins before editing zones.
See the full tools collection and all guides, including the companion piece on WHOIS lookups, for the ownership side of domains.
Conclusion: DNS maps names to addresses through resolvers, roots, TLD servers, and authoritative nameservers. A records point sites at servers, CNAMEs alias subdomains, MX records route mail, and TXT records carry verification policies. Edit at the live nameservers, copy values exactly, plan around TTLs, and most DNS tasks become routine.