Every time you type a web address into your browser, something invisible happens in the background that makes the whole internet work. That invisible system is called the Domain Name System, or DNS. Most people never think about it until something breaks. Then suddenly, a website won't load, email stops arriving, or a brand-new domain seems to vanish into thin air. Understanding DNS is not just for network engineers. Anyone who owns a website, runs a small business online, or manages a hosting account will eventually need to know what DNS is, how it works, and how to fix it when it goes wrong.
What DNS Actually Is
DNS stands for Domain Name System. Think of it as the internet's phone book. Computers communicate using numerical IP addresses, like 104.21.45.68. Humans are much better at remembering names like dnschecker.ca. DNS bridges that gap by translating human-readable domain names into machine-readable IP addresses.
Without DNS, you would have to memorize the IP address of every website you wanted to visit. DNS was invented in 1983 by Paul Mockapetris specifically to solve this problem as the internet grew beyond a handful of research computers. Today it handles billions of lookups every second, globally, and most of those lookups resolve in under 100 milliseconds.
How DNS Works Step by Step
When you type a domain name into your browser, a process called DNS resolution kicks off. Here is exactly what happens:
- Your browser checks its local cache. If you visited the site recently, the answer might already be stored on your computer. This is the fastest possible outcome.
- Your operating system checks its hosts file. On Windows this lives at C:\Windows\System32\drivers\etc\hosts. On macOS and Linux it is at /etc/hosts. Entries here override everything else, which is why malware sometimes targets this file.
- Your device asks a recursive resolver. This is usually a DNS server run by your ISP, or a public one like Google (8.8.8.8) or Cloudflare (1.1.1.1). The recursive resolver does the heavy lifting of finding the answer.
- The resolver asks a root nameserver. There are 13 sets of root nameservers worldwide. They do not know individual domain answers but they know where to find the correct top-level domain (TLD) servers.
- The resolver asks a TLD nameserver. For a .com domain, this is a Verisign-operated server. For .ca, it is managed by CIRA. The TLD server points to the authoritative nameserver for the specific domain.
- The resolver asks the authoritative nameserver. This is the server that actually knows the DNS records for your domain. It returns the final answer, like an IP address.
- Your browser connects to that IP address and the page loads.
All of that happens in a fraction of a second. The recursive resolver caches the answer for a period defined by the record's Time to Live (TTL) so future queries are much faster.
DNS Record Types You Actually Need to Know
DNS is not just one record that points a name to an IP. There are several record types, each serving a specific purpose. These are the ones that matter most:
A Record
Maps a domain or subdomain to an IPv4 address. This is the most common record type. Example: example.com pointing to 198.51.100.42.
AAAA Record
Same as an A record but for IPv6 addresses. Example: pointing example.com to 2001:db8::1.
CNAME Record
Creates an alias from one domain name to another. For example, www.example.com pointing to example.com. Important rule: you cannot use a CNAME at the root of a domain (the apex). You also cannot combine a CNAME with other record types for the same name.
MX Record
Tells mail servers where to deliver email for your domain. Without a correct MX record, nobody can email you at your custom domain. MX records have a priority value. Lower numbers mean higher priority. If you use Google Workspace, your MX records will point to Google's mail servers.
TXT Record
A flexible record used to store text data. The most common uses are domain ownership verification (for Google, Microsoft, etc.), SPF records to prevent email spoofing, and DKIM keys to authenticate outgoing mail.
NS Record
Specifies which nameservers are authoritative for your domain. These are set at your domain registrar, not your hosting company. If your NS records point to the wrong servers, nothing else in your DNS will work.
SOA Record
Start of Authority. Contains administrative information about the zone, including the primary nameserver and contact email. Managed automatically by most DNS providers.
PTR Record
Reverse DNS. Maps an IP address back to a hostname. Critical for email deliverability because receiving mail servers check PTR records to verify sender identity.
What TTL Means and Why It Matters
Every DNS record has a TTL, measured in seconds. This tells resolvers how long to cache the record before asking again. A TTL of 3600 means the record can be cached for one hour. Common values:
- 300 seconds (5 minutes) - Used when you are about to make changes and want them to propagate quickly.
- 3600 seconds (1 hour) - A good default for most records.
- 86400 seconds (24 hours) - Used for stable records that rarely change.
If you are migrating a website to a new server, lower your A record TTL to 300 seconds at least 24 hours before the cutover. That way, once you make the change, most visitors will see the new IP within 5 minutes instead of waiting up to a day.
The Difference Between Your Registrar and Your DNS Host
This confuses beginners more than anything else. Your domain registrar is the company where you bought your domain name (GoDaddy, Namecheap, Google Domains, etc.). Your DNS host is whoever runs the nameservers that actually answer DNS queries for your domain.
By default, these are often the same company. But they do not have to be. Many people buy their domain at one registrar and then use Cloudflare, AWS Route 53, or their web host's nameservers as the DNS host. When you change nameservers at your registrar, you are redirecting all DNS queries to a completely different provider. Any DNS records you had with the old provider do not automatically transfer. You need to recreate them manually.
Common DNS Problems and How to Fix Them
Website Not Loading After Changing Hosting
You moved your website to a new host, updated your A record, but the old site still shows up. This is almost always a caching issue. Here is how to diagnose it:
If the correct IP appears in the output but your browser still shows the old site, the problem is your local DNS cache. Flush it:
If nslookup or dig also returns the old IP, your TTL has not expired yet or the change has not fully propagated. Wait it out or check that you edited the correct A record in the correct DNS zone.
Email Not Working After Domain Setup
No MX records means no email. Log in to your DNS provider, find the DNS management section, and add MX records as specified by your email provider. For Google Workspace they look like this:
After saving, verify the MX records are live using the DNS Lookup tool or this command:
CNAME Record Not Working for www Subdomain
If your CNAME for www points to the root domain but www does not resolve, check two things. First, confirm the CNAME is pointing to a valid hostname that itself has an A record. Second, make sure you are not trying to set up a CNAME at the domain apex (the bare domain without www). Apex CNAMEs are not standard. Use an A record or a flattened CNAME (a feature some DNS providers like Cloudflare offer as CNAME flattening).
How to Check DNS Propagation
DNS changes do not take effect everywhere at once. Resolvers around the world hold cached copies of old records until the TTL expires. This process is called propagation. It can take anywhere from a few minutes to 48 hours, depending on the original TTL.
A common mistake is changing a record and then immediately checking if it worked from the same computer. If you cached the old record with a 24-hour TTL an hour ago, you will still see the old record for 23 more hours even though the authoritative nameserver is already returning the new one. Always test using an external tool or query a specific resolver with nslookup or dig.
Public DNS Servers Worth Knowing
Your ISP's default DNS resolver is fine for most use cases, but public alternatives offer benefits like speed, privacy, and filtering. Here are the most reliable ones:
- Cloudflare: 1.1.1.1 and 1.0.0.1 - Fastest average response time globally, strong privacy policy.
- Google Public DNS: 8.8.8.8 and 8.8.4.4 - Extremely reliable, widely used for testing.
- OpenDNS: 208.67.222.222 and 208.67.220.220 - Offers content filtering options.
- Quad9: 9.9.9.9 and 149.112.112.112 - Blocks malicious domains based on threat intelligence.
To change your DNS resolver on Windows, go to Control Panel > Network and Sharing Center > Change adapter settings, right-click your active adapter, select Properties, click Internet Protocol Version 4, and enter your preferred DNS server addresses. On macOS, go to System Settings > Network > your connection > Details > DNS and add the IP addresses there.
DNSSEC: An Introduction to DNS Security
Standard DNS has no built-in authentication. A resolver that receives a DNS response has no way to verify it came from the real authoritative server and was not tampered with in transit. This attack is called DNS spoofing or cache poisoning. DNSSEC (DNS Security Extensions) solves this by adding cryptographic signatures to DNS records. When DNSSEC is enabled, resolvers can verify that the records they received are exactly what the zone owner published and have not been altered.
Enabling DNSSEC requires support from both your DNS host and your domain registrar. The DNS host signs your zone and generates a DS record, which you then publish at your registrar. If either side does not support it, DNSSEC cannot be fully deployed. Many major registrars and DNS providers now support DNSSEC, including Cloudflare, AWS Route 53, and most cPanel-based hosts.
How to Prevent DNS Problems Before They Happen
- Lower your TTLs before any planned change. Give the low TTL time to propagate before you make the actual DNS update.
- Document your DNS records. Keep a spreadsheet of every record in your zone. When something breaks, you will thank yourself.
- Use a reliable DNS provider. Free DNS from budget registrars can be slow and unreliable. Cloudflare's free DNS is genuinely excellent.
- Set up monitoring. Use uptime monitoring services that alert you if your domain stops resolving. Knowing within 60 seconds beats finding out from customers.
- Never delete old records before the new ones work. When migrating, run old and new configurations in parallel until the new one is confirmed working.
DNS is one of those foundational technologies that works so reliably most of the time that people forget it exists. But when it breaks, everything breaks with it. A solid understanding of how the system works, what the records mean, and how to test and fix issues will save hours of frustration and prevent downtime that costs real money. The good news is that DNS is not that complicated once you see it for what it is: a distributed, hierarchical, globally cached directory of names and addresses that the internet depends on every single second of every day.