Every time you type a web address into your browser and press Enter, something remarkable happens in the background — a global lookup system springs into action, translates a human-readable name like example.com into a machine-readable number, and delivers you to exactly the right server somewhere in the world. All of this takes place in milliseconds, invisibly, and billions of times a day.

That system is DNS — the Domain Name System. It is one of the most fundamental pieces of infrastructure the modern internet runs on, and yet most people who build, manage, or own websites have only the haziest understanding of how it actually works.

This guide changes that. Whether you’re setting up your first website and confused about nameservers, migrating a site to a new host and puzzled by propagation delays, or simply curious about what’s happening under the hood — this is the clear, thorough explanation you’ve been looking for.

1. What DNS Actually Is

DNS stands for Domain Name System. Its job is simple in concept: translate domain names that humans can read and remember — like google.com or yoursite.com — into IP addresses that computers use to locate each other on the internet.

An IP address is a numerical label assigned to every device connected to the internet. IPv4 addresses look like 192.168.1.1. IPv6 addresses look like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Computers navigate using these numbers. Humans navigate using names. DNS is the bridge between the two.

Why DNS Exists

Before DNS was created in 1983, the internet was small enough that a single text file called HOSTS.TXT — maintained by the Stanford Research Institute — contained every hostname and its corresponding IP address. Network administrators would periodically download updated copies of this file.

As the internet grew, this approach became completely unmanageable. The solution was DNS: a distributed, hierarchical database system that could scale to handle billions of domain names without any single organization needing to maintain the entire list. Today, DNS handles trillions of queries every day across thousands of servers worldwide.

The Hierarchy of DNS

DNS is organised as a hierarchy, structured like an upside-down tree:

• The root — at the very top, managed by ICANN. Represented by a dot (.) that you rarely see but is technically always there.
• Top-level domains (TLDs) — .com, .org, .net, .co.uk, .io, and hundreds more. Each TLD has its own registry organization.
• Second-level domains — the name you register, like yoursite in yoursite.com.
• Subdomains — prefixes you add yourself, like www or mail or blog.

When you register a domain, you’re securing a place in this hierarchy. When you configure DNS records, you’re filling in entries in a directory that the entire internet can look up.

2. How a DNS Lookup Works — Step by Step

When you type yoursite.com into your browser and press Enter, here is exactly what happens before your browser loads a single byte of the page:

1. Browser cache check — Your browser first checks its own internal cache. If you’ve visited the site recently, it may already know the IP address and skip the rest of the process entirely.
2. Operating system cache check — If the browser cache misses, your OS checks its local DNS cache. On most systems this is where the HOSTS file also lives.
3. Recursive resolver query — If neither cache has the answer, your device contacts a recursive DNS resolver — typically one operated by your ISP or a public provider like Google (8.8.8.8) or Cloudflare (1.1.1.1). This resolver does the hard work on your behalf.
4. Root nameserver query — The recursive resolver contacts one of the 13 root nameserver clusters and asks where to find the .com TLD nameservers.
5. TLD nameserver query — The resolver contacts the .com TLD nameservers and asks where to find the authoritative nameservers for yoursite.com.
6. Authoritative nameserver query — The resolver contacts the authoritative nameservers for yoursite.com (usually operated by your domain registrar or hosting provider) and requests the actual DNS records.
7. Answer returned — The authoritative nameserver returns the IP address. The resolver caches this result and passes it to your browser.
8. HTTP connection — Now knowing the IP address, your browser connects directly to the web server at that address and requests your website.

TTL: How Long Results Are Cached

Every DNS record includes a TTL — Time to Live — measured in seconds. This tells resolvers and caches how long they should store the result before checking again. A TTL of 3600 means the record can be cached for one hour. After that, the resolver must query the authoritative nameserver again to get a fresh answer.

TTL is important when you’re making DNS changes: a low TTL means changes propagate faster but puts more load on nameservers. A high TTL means faster responses for visitors but slower propagation when you change records.

3. DNS Record Types Explained

DNS isn’t just about pointing domain names to IP addresses. A domain’s DNS zone contains multiple types of records, each serving a specific purpose. Here are the ones you’re most likely to encounter:

A Record — The Core Record

An A record maps a domain or subdomain to an IPv4 address. This is the most fundamental DNS record — it’s what tells the internet which server IP address to send visitors to when they load your domain.

Example: yoursite.com → 185.220.101.5

AAAA Record — IPv6 Version

An AAAA record does the same thing as an A record but for IPv6 addresses. As the internet transitions to IPv6, more hosting providers are assigning IPv6 addresses alongside IPv4.

CNAME Record — Alias

A CNAME record (Canonical Name) creates an alias that points one domain to another domain name — not directly to an IP address. The lookup then follows through to wherever that target domain resolves.

Example: www.yoursite.com → yoursite.com

CNAME records are commonly used to point www to the root domain, or to point subdomains to external services like CDNs, email marketing platforms, or e-commerce systems.

MX Record — Email Routing

An MX record (Mail Exchange) tells the internet where to deliver email sent to addresses at your domain. Without correct MX records, email to [email protected] won’t be delivered anywhere. MX records include a priority value — lower numbers are tried first.

TXT Record — Verification and Authentication

TXT records store arbitrary text strings associated with your domain. They’re used for a wide range of purposes including domain ownership verification (for Google Search Console, for example), email security configurations (SPF, DKIM, DMARC), and service authentication tokens.

NS Record — Nameserver Delegation

NS records specify which nameservers are authoritative for your domain — meaning which servers hold the definitive DNS records. When you change hosting providers and point your domain to new nameservers, you’re updating the NS records at your registrar.

SOA Record — Zone Authority

The SOA record (Start of Authority) contains administrative information about the DNS zone including the primary nameserver, the email of the zone administrator, and timing values for zone transfers. You rarely need to edit this manually.

4. Nameservers and Who Controls Them

Nameservers are the servers that hold and serve your domain’s DNS records. Understanding the relationship between domain registrars, nameservers, and hosting providers is one of the most important things you can learn about how DNS works in practice — and it’s the source of most confusion when setting up or migrating a website.

Domain Registrar vs. DNS Host vs. Web Host

These three roles are often confused — and they can be handled by the same company or three completely different companies:

• Domain registrar — the company where you registered (purchased) your domain. Examples: Namecheap, GoDaddy, Google Domains. They record your ownership with the TLD registry and let you set nameservers.
• DNS host — the company whose nameservers hold and serve your DNS records. This is often (but not always) your domain registrar or your web hosting provider.
• Web host — the company whose servers actually store and serve your website files. Examples: SiteGround, Hostinger, Cloudways.

How to Change Nameservers

Nameservers are set at your domain registrar — not at your hosting provider. When your hosting company says “point your domain to our nameservers,” they mean: log in to wherever you registered your domain, find the nameserver settings, and replace the current nameservers with the ones your host provides.

Hosting providers typically give you two nameservers for redundancy, formatted like ns1.hostingcompany.com and ns2.hostingcompany.com. Once you update these at your registrar, all DNS queries for your domain will be routed to your hosting provider’s nameservers.

5. How Domain Names Connect to Hosting

This is the practical core of DNS for most website owners: how do you make a domain name actually point to your hosting account? There are two main approaches, and understanding the difference matters.

Method 1: Change the Nameservers (Recommended for Beginners)

The simplest approach is to point your domain’s nameservers directly to your hosting provider. When you do this, your hosting provider becomes responsible for managing all of your DNS records — your A record, MX records, and everything else.

1. Log in to your domain registrar
2. Find the nameserver settings for your domain
3. Replace the existing nameservers with the ones your host provided
4. Save the changes and wait for propagation

Advantage: Simple setup. Your host manages everything from one place. When you add email accounts or subdomains through your host’s control panel, the DNS records are updated automatically.

Disadvantage: All your DNS is centralised with one provider. If you use Cloudflare or another DNS service for performance or security, you’ll lose those benefits.

Method 2: Keep Nameservers, Update the A Record Manually

The more flexible approach is to leave your nameservers where they are (your registrar or Cloudflare) and manually update just the A record to point to your hosting provider’s IP address.

1. Get your hosting server’s IP address from your hosting provider
2. Log in to wherever your DNS is managed (registrar or Cloudflare)
3. Find the A record for your domain (or create one if it doesn’t exist)
4. Update it to point to your hosting server’s IP address
5. Do the same for the www subdomain (either another A record or a CNAME)

Advantage: You maintain control of DNS. You can keep Cloudflare for performance and security while using any hosting provider. You can point different subdomains to different servers.

Disadvantage: Slightly more technical. You need to remember to manually update DNS records for email and other services.

6. DNS Propagation Explained

One of the most frustrating experiences in website management is making a DNS change and then waiting — sometimes for hours — for it to take effect everywhere. This waiting period is called DNS propagation, and understanding why it happens makes it significantly less stressful.

Why Propagation Takes Time

When you update a DNS record, the change is immediately live on your authoritative nameservers. However, the rest of the internet doesn’t know about this change yet. Recursive resolvers all over the world have cached your old DNS records — and they’ll keep using those cached results until the TTL expires.

This is why propagation time depends directly on your TTL value. If your TTL was set to 86400 (24 hours), resolvers can cache your old records for up to 24 hours before checking again. If your TTL was 300 (5 minutes), propagation completes much faster.

The “48 Hours” Myth

You’ve probably heard that DNS changes take “24 to 48 hours to propagate.” This figure is outdated and overly pessimistic for most situations. In practice:

• With a low TTL (300–3600 seconds), most of the world sees your change within 1–4 hours
• With a default TTL of 86400 (24 hours), it can genuinely take up to 24 hours
• A small number of resolvers with unusual caching behaviour may take longer

How to Check Propagation Status

Several free tools let you check whether your DNS changes have reached different resolvers around the world:

• whatsmydns.net — shows your record’s current value from dozens of locations globally
• dnschecker.org — similar global view with a clean interface
• Google Admin Toolbox — useful for diagnosing specific DNS record issues

During propagation, it’s completely normal to see different results from different locations — some showing your old IP, others showing your new one. This is not a sign that something is wrong; it’s the distributed cache system working exactly as designed.

7. Common DNS Problems and How to Fix Them

DNS issues are responsible for a significant proportion of “my website is down” situations. Here are the most common problems and what to do about them.

Site Shows “Server Not Found” After Changing Hosts

Cause: DNS hasn’t propagated yet, or the A record wasn’t updated correctly.

Fix: Use whatsmydns.net to check whether your A record is resolving to the correct IP address. If the record is correct but you’re still seeing the old site, clear your browser cache and try a different DNS resolver — some ISP resolvers are slow to update.

www Works But Root Domain Doesn’t (or Vice Versa)

Cause: You have an A record for one but not the other. Most sites need both yoursite.com (the root/apex domain) and www.yoursite.com configured.

Fix: Add an A record for your root domain pointing to your server IP. Add a CNAME for www pointing to your root domain, or a second A record pointing to the same IP.

Email Stops Working After Moving the Site

Cause: You changed nameservers to your new host, and your email MX records didn’t transfer correctly. Your new host’s default DNS zone may not have the right MX records configured.

Fix: Log in to your new host’s DNS management panel and check the MX records. They should point to your email provider (Google Workspace, Microsoft 365, Zoho, etc.). Don’t assume they carried over automatically.

SSL Certificate Showing as Invalid After DNS Change

Cause: The SSL certificate was issued for a specific server. If you moved to a new server, the new server may not yet have a valid SSL certificate installed, or the certificate validation is failing because DNS hasn’t fully propagated.

Fix: Install a new SSL certificate on your new host before or immediately after the DNS change. Most hosting providers have a one-click Let’s Encrypt SSL installation in cPanel.

8. DNS and Email: Understanding MX Records

Email routing is one of the most important — and most commonly misconfigured — aspects of DNS. When someone sends an email to [email protected], the sender’s mail server performs a DNS lookup for MX records on yoursite.com to find out where to deliver the message.

How MX Records Work

MX records point to a mail server hostname (not an IP address directly). That hostname then has its own A record. MX records include a priority number — when multiple MX records exist, the server with the lowest priority number is tried first, with others serving as fallbacks.

Example MX records for a domain using Google Workspace:

Email Authentication Records (TXT)

Modern email requires additional TXT records to prevent your messages from being marked as spam and to verify that emails from your domain are legitimate:

• SPF (Sender Policy Framework) — lists the servers authorised to send email on behalf of your domain. Receiving servers check this to verify the sender. Example: v=spf1 include:_spf.google.com ~all
• DKIM (DomainKeys Identified Mail) — adds a digital signature to outgoing emails that receiving servers can verify against a public key stored in your DNS. Your email provider generates this for you.
• DMARC (Domain-based Message Authentication) — a policy that tells receiving servers what to do with emails that fail SPF or DKIM checks. Example: v=DMARC1; p=quarantine; rua=mailto:[email protected]

9. DNS Security Basics

DNS is a foundational infrastructure layer, which makes it an attractive target for attackers. Understanding the basic threats and protections helps you make better decisions about how you manage your domain.

DNS Hijacking

DNS hijacking occurs when an attacker modifies DNS records — either by compromising your domain registrar account or through an attack on the DNS infrastructure — to redirect your visitors to a malicious server. The attack is insidious because from a visitor’s perspective the domain looks correct; only the destination has changed.

Protection: Enable two-factor authentication on your domain registrar account. Use a registrar with domain locking features. Monitor your DNS records periodically for unexpected changes.

DNS Spoofing / Cache Poisoning

Cache poisoning is an attack where an attacker injects false DNS records into a resolver’s cache, causing it to return incorrect IP addresses to anyone using that resolver. Victims are redirected to attacker-controlled servers without any visible sign that something is wrong.

Protection: DNSSEC (see below) is specifically designed to prevent this attack. Using trusted public resolvers like Cloudflare’s 1.1.1.1 also reduces risk.

DNSSEC — DNS Security Extensions

DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that the records they receive are authentic and haven’t been tampered with in transit. If a record fails DNSSEC validation, the resolver rejects it rather than returning potentially poisoned data.

DNSSEC is enabled at the registrar level and must be supported by your DNS provider. Cloudflare offers free DNSSEC with a single toggle. It’s worth enabling for any domain used for professional or business purposes.

Domain Locking

Most registrars offer domain locking — a feature that prevents any changes to your domain’s registration or nameservers without first explicitly unlocking it. This stops an attacker who gains partial access to your account from immediately redirecting your traffic. Keep domain lock enabled unless you’re actively making changes.

10. DNS Settings Reference Checklist

Whether you’re setting up a new website, migrating to a new host, or auditing an existing setup, this checklist covers the DNS records you need to verify.

For a New Website Launch

• A record for root domain (yoursite.com) points to your hosting server IP
• A record or CNAME for www subdomain configured and working
• Nameservers set correctly at your domain registrar
• SSL certificate installed and HTTPS working on both root and www
• DNS propagation verified via whatsmydns.net

For Email Configuration

• MX records point to your email provider’s mail servers
• SPF TXT record added and correct for your email provider
• DKIM TXT record added (generated and provided by your email provider)
• DMARC TXT record added with appropriate policy
• Send a test email and verify it lands in inbox, not spam

For a Site Migration

• Lower TTL to 300 seconds at least 24 hours before migration
• Get new hosting server IP address before making any DNS changes
• Update A record to new server IP
• Keep old hosting active for at least 72 hours after DNS change
• Verify MX records are intact and email is working after migration
• Restore TTL to normal value (3600 or higher) once migration is confirmed

For Ongoing Security

• Two-factor authentication enabled on domain registrar account
• Domain lock enabled (unlock only when making changes)
• DNSSEC enabled if your registrar and DNS provider support it
• DNS records reviewed periodically for unexpected changes