The Complete DNS Guide for Website Owners

Every time someone visits your website, DNS is quietly doing the work behind the scenes. It translates your domain name into the IP address that actually serves your pages. When DNS works, nobody notices. When it breaks, your entire site disappears.

This guide covers everything you need to know about DNS as a website owner. Not the theory-heavy version aimed at network engineers, but the practical knowledge you need to keep your site running, configure records correctly, and fix problems when they come up.

What Is DNS

DNS stands for Domain Name System. It is the system that translates human-readable domain names (like example.com) into machine-readable IP addresses (like 93.184.216.34).

You have probably heard the "phone book of the internet" analogy. It is a decent starting point, but here is a more accurate way to think about it.

Imagine you are in a city where every building has a street address, but no building has a sign. You know you want to go to "Joe's Coffee Shop," but you do not know the address. So you pull out a directory, look up the name, and find the street address. That is what DNS does for web browsers. Your browser knows you want example.com, but it needs the IP address 93.184.216.34 to actually connect.

The key difference from a phone book: DNS is not one big list sitting in one place. It is a distributed, hierarchical system spread across millions of servers worldwide. No single server knows every domain. Instead, they work together, each responsible for a piece of the puzzle.

For a deeper look at why DNS matters for your site's availability, see our article on DNS monitoring explained.

How DNS Resolution Works

When you type a domain name into your browser, a chain of lookups happens before the page loads. This process is called DNS resolution, and it typically takes less than 100 milliseconds [1].

Here is the step-by-step process:

Step 1: The Browser Cache

Your browser first checks its own cache. If you visited example.com five minutes ago, the browser probably still has the IP address stored locally. If it finds a match, the lookup is done instantly.

Step 2: The Operating System Cache

If the browser cache misses, the request goes to your operating system's DNS resolver. Your OS maintains its own cache of recent lookups. On Windows, the DNS Client service handles this. On macOS and Linux, it is typically systemd-resolved or a similar service.

Step 3: The Recursive Resolver

If the OS cache misses too, the query goes to a recursive resolver. This is usually a server run by your ISP, or a public resolver like Google (8.8.8.8) or Cloudflare (1.1.1.1).

The recursive resolver is the workhorse of DNS. It is the server that actually goes out and finds the answer by querying other servers on your behalf. Think of it as a research librarian: you ask a question, and it goes and finds the answer, no matter how many shelves it has to check.

Step 4: The Root Servers

If the recursive resolver does not have the answer cached, it starts at the top of the DNS hierarchy: the root servers. There are 13 root server clusters (labeled A through M), operated by organizations like ICANN, Verisign, and the U.S. Army Research Lab [2]. These root servers do not know the IP address of example.com, but they know where to find information about .com domains.

The root server responds with a referral to the TLD (Top-Level Domain) servers for .com.

Step 5: The TLD Servers

The TLD servers are responsible for an entire top-level domain like .com, .org, or .net. The .com TLD server does not know the IP of example.com either, but it knows which nameservers are authoritative for example.com.

It responds with a referral to those authoritative nameservers.

Step 6: The Authoritative Nameserver

Finally, the recursive resolver reaches the authoritative nameserver for example.com. This is the server that actually has the DNS records for the domain. It responds with the IP address (or whatever record was requested).

The recursive resolver caches this answer for the duration specified by the record's TTL (Time to Live), then sends it back to your browser.

Your browser connects to the IP address, and the page loads.

We cover this process in much more detail in how DNS resolution works.

A Visual Summary

Browser → OS Cache → Recursive Resolver → Root Server
                                              ↓
                          TLD Server  ←───────┘
                              ↓
                    Authoritative NS  ←───────┘
                              ↓
                         IP Address returned

All of this happens in milliseconds, thousands of times per second, for every website on the internet.

DNS Record Types

DNS records are the actual entries stored on authoritative nameservers. Each record type serves a different purpose. As a website owner, you will work with some of these regularly and others only occasionally.

For a comprehensive breakdown, see our DNS record types explained article.

A Record

The A record maps a domain name to an IPv4 address. This is the most fundamental DNS record type and the one you will use most often.

example.com.    300    IN    A    93.184.216.34

This tells the world: "The server for example.com is at 93.184.216.34." The 300 is the TTL in seconds (5 minutes).

You can have multiple A records for the same domain to distribute traffic across servers (round-robin DNS).

AAAA Record

The AAAA record (sometimes called "quad-A") is identical to an A record but maps to an IPv6 address instead of IPv4.

example.com.    300    IN    AAAA    2606:2800:0220:0001:0248:1893:25c8:1946

With IPv4 address exhaustion becoming a real constraint, setting up AAAA records alongside your A records is increasingly important.

CNAME Record

A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of pointing to an IP address, it points to another domain name.

www.example.com.    300    IN    CNAME    example.com.

This means "www.example.com is an alias for example.com." The browser will then do another lookup for example.com to get the actual IP address.

Important rules for CNAME records:

• A CNAME cannot coexist with other record types for the same name.
• You cannot put a CNAME on the root domain (the "zone apex"). So example.com itself cannot be a CNAME. Some DNS providers offer workarounds like ALIAS or ANAME records, but these are not standard DNS.

MX Record

MX (Mail Exchange) records tell the world which servers handle email for your domain. Without correct MX records, you will not receive email.

example.com.    300    IN    MX    10    mail1.example.com.
example.com.    300    IN    MX    20    mail2.example.com.

The number before the server name is the priority. Lower numbers mean higher priority. In this example, mail1 is tried first. If it is unreachable, mail2 is used as a fallback.

If you use Google Workspace, Microsoft 365, or any hosted email service, they will give you specific MX records to configure. Getting these wrong is one of the most common DNS mistakes. You can verify yours with our MX record checker.

TXT Record

TXT records store arbitrary text data. They were originally designed for human-readable notes, but today they serve critical functions in email authentication and domain verification.

example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Common uses for TXT records:

• SPF (Sender Policy Framework): Specifies which servers can send email on behalf of your domain.
• DKIM (DomainKeys Identified Mail): Publishes a public key for email signature verification.
• DMARC (Domain-based Message Authentication): Defines a policy for handling emails that fail SPF/DKIM checks.
• Domain verification: Services like Google Search Console and various SaaS platforms ask you to add a TXT record to prove you own the domain.

See our guide on checking TXT records for more.

NS Record

NS (Name Server) records define which nameservers are authoritative for a domain. These are typically set at your domain registrar and point to your DNS provider.

example.com.    86400    IN    NS    ns1.dnsprovider.com.
example.com.    86400    IN    NS    ns2.dnsprovider.com.

NS records usually have high TTL values (86400 seconds = 24 hours) because nameserver changes are infrequent and you want them to be stable.

SOA Record

The SOA (Start of Authority) record contains administrative information about the zone. Every DNS zone has exactly one SOA record.

example.com.    86400    IN    SOA    ns1.dnsprovider.com. admin.example.com. (
                                      2026041401   ; Serial number
                                      3600         ; Refresh
                                      900          ; Retry
                                      1209600      ; Expire
                                      86400        ; Minimum TTL
                                      )

As a website owner, you rarely need to edit the SOA record directly. Your DNS provider manages it. But understanding it helps when debugging, because the serial number increments with each zone change and is used by secondary nameservers to know when to update.

PTR Record

PTR (Pointer) records do the opposite of A records. They map an IP address back to a domain name. This is called a reverse DNS lookup.

34.216.184.93.in-addr.arpa.    300    IN    PTR    example.com.

PTR records are mainly used for email deliverability. Many mail servers reject email from IPs without a valid PTR record. Your hosting provider usually manages these, not you.

For more on this topic, see reverse DNS lookup explained.

SRV Record

SRV (Service) records specify the location of specific services. They include the hostname, port, priority, and weight for a service.

_sip._tcp.example.com.    300    IN    SRV    10 60 5060 sipserver.example.com.

SRV records are used by services like VoIP, XMPP, and some Microsoft services. Most website owners will not need to configure these unless they run specialized services.

CAA Record

CAA (Certification Authority Authorization) records specify which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for your domain.

example.com.    300    IN    CAA    0 issue "letsencrypt.org"
example.com.    300    IN    CAA    0 issuewild "letsencrypt.org"

This tells the world that only Let's Encrypt is authorized to issue certificates for your domain. If another CA receives a certificate request for your domain, they should refuse it. CAA records are an underused but valuable security measure.

If you are managing SSL certificates, our sibling guide on how to check your SSL certificate covers the relationship between CAA records and certificate issuance.

DNS Propagation

DNS propagation is the process by which updated DNS records spread across the global network of DNS servers. When you change a DNS record, the new information does not instantly appear everywhere. It takes time for caches to expire and servers to pick up the new data.

We have a dedicated deep dive on DNS propagation explained, but here is what you need to know.

Why Propagation Takes Time

When you update a DNS record, the change is immediately live on your authoritative nameserver. But recursive resolvers around the world have the old record cached. They will keep serving the old IP address until their cached copy expires.

The expiry time is determined by the TTL (Time to Live) value on the record. If your A record had a TTL of 3600 (one hour), resolvers that cached it will continue serving the old value for up to one hour.

But that is not the whole story. Some ISP resolvers ignore TTL values and cache records for longer periods. Some corporate networks have aggressive caching policies. This is why propagation can sometimes seem to take longer than the TTL suggests.

Typical Propagation Times

• Low TTL (300 seconds): Most resolvers update within 5 to 30 minutes.
• Standard TTL (3600 seconds): Most resolvers update within 1 to 4 hours.
• High TTL (86400 seconds): Full propagation can take 24 to 48 hours.

How to Check Propagation

You can check whether your DNS changes have propagated by querying DNS servers in different locations. Our guide on how to check DNS propagation walks through the process.

From the command line, you can query specific resolvers:

# Check against Google's resolver
dig example.com @8.8.8.8

# Check against Cloudflare's resolver
dig example.com @1.1.1.1

# Check against your authoritative nameserver directly
dig example.com @ns1.yourdnsprovider.com

If the authoritative nameserver returns the new value but public resolvers still show the old one, propagation is in progress.

DNS Caching and TTL

Caching is what makes DNS fast. Without it, every single page load would require a full chain of queries from recursive resolver to root server to TLD server to authoritative nameserver. Caching short-circuits this process by storing answers closer to the user.

Where Caching Happens

DNS answers are cached at multiple levels:

1. Browser cache: Your browser stores DNS results for a short period (usually 1 to 2 minutes in Chrome).
2. Operating system cache: Your OS maintains a DNS cache that persists across applications.
3. Recursive resolver cache: Your ISP or public resolver caches results based on the TTL.
4. Intermediate caches: Some corporate networks and CDNs maintain their own DNS caches.

Each level reduces the number of queries that reach the authoritative nameserver.

Understanding TTL

TTL (Time to Live) is a value in seconds attached to every DNS record. It tells resolvers how long they can cache the answer before they need to ask again.

example.com.    3600    IN    A    93.184.216.34
                ^^^^
                TTL = 3600 seconds (1 hour)

Choosing the right TTL is a balancing act:

• Low TTL (60 to 300 seconds): Records update quickly when changed, but authoritative nameservers handle more queries. Good for records that change frequently or when you are planning a migration.
• Medium TTL (3600 seconds): A solid default for most records. Balances freshness with query volume.
• High TTL (86400 seconds): Good for records that rarely change, like NS records. Reduces load on nameservers but makes changes slow to propagate.

For a complete breakdown, see DNS caching and TTL.

Flushing DNS Cache

Sometimes you need to see a DNS change immediately on your own machine, without waiting for caches to expire. You can flush your local DNS cache:

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd):

sudo systemd-resolve --flush-caches

This only clears your local cache. It does not affect caching at your ISP's resolver or anywhere else. See our guide on flushing DNS cache for platform-specific instructions.

Nameservers

Nameservers are the servers that actually host your DNS records. When someone asks "where is example.com?", the nameservers for your domain provide the answer.

How Nameservers Are Configured

Your domain's nameservers are set at your domain registrar (the company where you registered the domain). When you register a domain, the registrar typically sets its own nameservers by default. If you use a separate DNS provider (like Cloudflare, AWS Route 53, or DNSimple), you need to update the nameserver settings at your registrar to point to that provider's nameservers.

Registrar (e.g., Namecheap)
  └── NS records point to → DNS Provider (e.g., Cloudflare)
       └── DNS records (A, MX, TXT, etc.) managed here

Changing Nameservers

Changing nameservers is one of the most consequential DNS operations you can perform. If you point your nameservers to the wrong place, or if the new nameservers are not configured with your DNS records, your site goes offline.

Here is the safe process:

1. Set up all your DNS records on the new DNS provider before switching nameservers.
2. Verify the records on the new provider match your current records. Use our DNS record audit guide to compare.
3. Lower TTLs on your current records 24 to 48 hours before the switch.
4. Update the nameserver settings at your registrar.
5. Monitor for issues during propagation.

Nameserver changes propagate through the TLD servers and can take up to 48 hours, though most complete within a few hours.

For step-by-step instructions, see how to change nameservers.

If you are also transferring your domain to a new registrar, the domain transfer safety guide covers how to handle DNS during the transfer process.

DNS Security

DNS was designed in the 1980s without security in mind [3]. The original protocol sends queries and responses in plaintext with no authentication, which makes it vulnerable to several types of attacks.

DNS Hijacking

DNS hijacking occurs when an attacker intercepts DNS queries or modifies DNS responses to redirect users to malicious servers. This can happen at several levels:

• Router hijacking: Malware on your router changes the DNS settings to point to a rogue resolver.
• Man-in-the-middle: An attacker intercepts DNS queries on the network and returns forged responses.
• Registrar compromise: An attacker gains access to your registrar account and changes your nameservers.
• Cache poisoning: An attacker injects false records into a resolver's cache.

The consequences range from phishing attacks (users see a fake version of your site) to email interception (MX records redirected to attacker-controlled servers). Read more in DNS hijacking explained.

DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records [4]. It allows resolvers to verify that the DNS response they received actually came from the authoritative nameserver and was not tampered with in transit.

How it works:

1. The authoritative nameserver signs each DNS record with a private key.
2. The corresponding public key is published as a DNSKEY record.
3. A hash of the public key (the DS record) is stored at the parent zone (the TLD).
4. Resolvers can verify the chain of signatures from root to TLD to your domain.

DNSSEC does not encrypt DNS queries. It only provides authentication and integrity. An eavesdropper can still see what domains you are querying, but they cannot forge the responses.

Not all DNS providers support DNSSEC, and enabling it requires coordination between your DNS provider and your registrar. But if your provider supports it, enabling DNSSEC is strongly recommended.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

While DNSSEC verifies the authenticity of DNS responses, it does not encrypt the queries themselves. DNS over HTTPS (DoH) [5] and DNS over TLS (DoT) encrypt the entire DNS conversation between your device and the recursive resolver.

• DoH sends DNS queries inside HTTPS requests, making them indistinguishable from regular web traffic. Supported by major browsers and resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8).
• DoT uses a dedicated TLS connection on port 853. It is easier for network administrators to manage but also easier to block.

As a website owner, you do not need to configure DoH or DoT on your server. These are client-side and resolver-side technologies. But understanding them helps you make informed decisions about your own DNS resolver choices and your users' privacy.

For a broader look at DNS security, see DNS security best practices.

DNS Troubleshooting

DNS issues are among the most frustrating problems to debug because the symptoms are vague (site is down, email is not working) and the cause can be anywhere in the resolution chain. Here are the tools and techniques you need.

Common DNS Problems

Site not loading after a DNS change: The most common issue. Usually caused by propagation delays. Wait for the TTL to expire, or check if the authoritative nameserver has the correct record by querying it directly.

Email not being delivered: Incorrect MX records, missing SPF/DKIM/DMARC TXT records, or a recently expired domain. Check your MX records and TXT records.

"DNS_PROBE_FINISHED_NXDOMAIN" in browser: The domain does not exist in DNS. This could mean the domain expired, the nameservers are misconfigured, or the A record is missing.

Intermittent resolution failures: Could indicate that one of your nameservers is down or returning inconsistent data. If you have ns1 and ns2, and only ns1 has the correct records, half your users will see the right site and half will get errors.

SSL certificate errors after DNS change: If you moved your site to a new server and changed the A record, the new server may not have a valid SSL certificate yet. CAA records can also block certificate issuance if not configured for your new CA.

Using nslookup

nslookup is available on Windows, macOS, and Linux. It is the simplest tool for quick DNS lookups.

# Basic lookup
nslookup example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up a specific record type
nslookup -type=MX example.com

# Look up TXT records
nslookup -type=TXT example.com

Using dig

dig (Domain Information Groper) is the more powerful tool, available on macOS and Linux by default. Windows users can install it via BIND tools.

# Basic lookup
dig example.com

# Query a specific record type
dig example.com MX

# Query a specific nameserver
dig @8.8.8.8 example.com

# Short output (just the answer)
dig +short example.com

# Trace the full resolution path
dig +trace example.com

# Check DNSSEC signatures
dig +dnssec example.com

The +trace option is particularly useful. It follows the entire resolution chain from root servers to authoritative nameservers, showing you exactly where the process succeeds or fails.

A Practical Troubleshooting Workflow

When something goes wrong, here is a systematic approach:

1. Query the authoritative nameserver directly. Does it have the correct record? If not, the problem is in your DNS configuration.
2. Query a public resolver (8.8.8.8 or 1.1.1.1). Does it return the same answer? If not, the record has not propagated yet, or there is a caching issue.
3. Check all nameservers. Query each of your nameservers individually. They should all return the same answer.
4. Check for CNAME conflicts. A CNAME record cannot coexist with other record types at the same name.
5. Check the TTL. If you recently made a change, the old record might still be cached.

For a more detailed walkthrough, see the DNS troubleshooting guide. You can also verify your records using our DNS record checker.

DNS Monitoring

You have configured your DNS records, verified they are working, and moved on. But DNS is not a "set it and forget it" system. Records can change unexpectedly, nameservers can go down, and misconfigurations can creep in over time.

Why Monitor DNS

There are several scenarios where DNS monitoring catches problems you would otherwise miss:

• Unauthorized changes: Someone on your team accidentally deletes an MX record, and email stops working. Without monitoring, you might not notice for hours or days.
• Hijacking and takeover: An attacker modifies your DNS records to redirect traffic. Monitoring detects the change immediately.
• Expiration and renewal issues: Your domain or DNS hosting expires, and records stop resolving.
• Provider outages: Your DNS provider has an outage, and your authoritative nameservers stop responding.
• Configuration drift: Over time, records accumulate that are no longer needed, or records diverge from their intended values.

If your website drives revenue, handles customer data, or supports business operations, DNS monitoring is not optional. It is infrastructure monitoring. For more on this topic, see why and how to monitor DNS changes.

What to Monitor

At minimum, monitor these aspects of your DNS:

• A and AAAA records for your primary domains. If these change unexpectedly, your site is probably pointing somewhere it should not be.
• MX records for domains that receive email. Email outages caused by DNS changes are common and often go undetected.
• TXT records for email authentication (SPF, DKIM, DMARC). Changes to these can cause legitimate email to be flagged as spam.
• NS records for your domain. Unauthorized nameserver changes are one of the most dangerous DNS attacks.
• CAA records if you have them. Unauthorized changes could allow an attacker to obtain a certificate for your domain.
• Nameserver responsiveness. Your authoritative nameservers should be responding quickly and consistently.

Change Detection

The most valuable form of DNS monitoring is change detection. Rather than just checking whether your domain resolves (uptime monitoring covers that), DNS change detection tracks the actual content of your records and alerts you when something changes.

This catches problems that uptime monitors miss. Your A record could be changed to point to a phishing site that returns HTTP 200 responses. An uptime monitor would report "all good." A DNS monitor would flag the IP address change immediately.

DNS monitoring also provides an audit trail. When something goes wrong, you can see exactly what changed and when, which is invaluable for incident response and DNS change management.

Our DNS monitoring glossary covers the key terms you will encounter when setting up monitoring.

For more on how DNS failures specifically cause website downtime, the why is my website down guide on Website Uptime Monitor walks through DNS as a root cause.

Choosing a DNS Provider

Your DNS provider hosts your authoritative nameservers and the zone files that contain your records. The choice of provider affects your site's speed, reliability, and the features available to you.

What to Look For

Reliability and uptime. Your DNS provider going down means your site is unreachable. Look for providers with a strong SLA (99.99% or higher) and a globally distributed anycast network.

Speed. DNS resolution speed varies by provider and geography. A provider with servers on multiple continents will generally resolve faster for a global audience.

DNSSEC support. If you want to enable DNSSEC, your provider needs to support it and make it straightforward to configure.

API access. If you manage DNS programmatically (infrastructure as code, automated deployments), you need a provider with a robust API.

Secondary DNS support. Running a secondary DNS provider alongside your primary one protects you against provider-level outages. See our guide on multi-DNS provider strategy.

Record type support. Most providers support the standard record types, but check for support of CAA records, SRV records, and any provider-specific features like ALIAS or ANAME records at the zone apex.

Popular DNS Providers

Here is a brief overview of the major options. Our full public DNS providers guide goes into more detail.

Cloudflare DNS: Free plan available. Fast global network, easy UI, strong API, built-in DDoS protection. One of the most popular choices for websites of all sizes.

AWS Route 53: Pay-per-query pricing. Deep integration with AWS services, supports advanced routing policies (latency-based, geolocation, weighted). Best for AWS-heavy infrastructure.

Google Cloud DNS: Pay-per-zone and per-query pricing. 100% SLA, strong API, integrates well with Google Cloud. Good option for Google Cloud users.

DNSimple: Subscription pricing. Clean interface, strong API, good support. Popular with developers who want simplicity.

NS1 (IBM): Enterprise-focused. Advanced traffic management, filter chains, real-time analytics. Best for large-scale, complex DNS requirements.

When to Switch Providers

Consider switching DNS providers if:

• You experience repeated outages or slow resolution times.
• You need features your current provider does not support (DNSSEC, API access, advanced routing).
• You are consolidating infrastructure and want DNS managed alongside your other services.
• You want to add a secondary DNS provider for redundancy.

Before switching, use the nameserver change process outlined earlier in this guide. And make sure to set up DNS monitoring before, during, and after the transition.

Wrapping Up

DNS is one of those foundational technologies that most website owners interact with only when setting up a site or troubleshooting a problem. But understanding how it works gives you a significant advantage. You can diagnose issues faster, plan changes with confidence, and secure your domain against an increasingly common class of attacks.

Here are the key takeaways:

• DNS translates domain names to IP addresses through a hierarchical, distributed system of servers.
• Different record types serve different purposes. A records for web traffic, MX for email, TXT for authentication and verification.
• Propagation is not instant. Plan changes by lowering TTLs in advance and verifying with multiple resolvers.
• DNSSEC and DoH/DoT add security layers that the original DNS protocol lacks.
• Monitoring your DNS records catches unauthorized changes, misconfigurations, and outages before your users are affected.

Your DNS records are the foundation of your online presence. Monitor them accordingly.

References

[1] Cloudflare. "What is DNS?" Cloudflare Learning Center. https://www.cloudflare.com/learning/dns/what-is-dns/

[2] IANA. "Root Servers." https://www.iana.org/domains/root/servers

[3] P. Mockapetris. "Domain Names - Concepts and Facilities." RFC 1034, November 1987. https://datatracker.ietf.org/doc/html/rfc1034; P. Mockapetris. "Domain Names - Implementation and Specification." RFC 1035, November 1987. https://datatracker.ietf.org/doc/html/rfc1035

[4] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. "DNS Security Introduction and Requirements." RFC 4033, March 2005. https://datatracker.ietf.org/doc/html/rfc4033; "Resource Records for the DNS Security Extensions." RFC 4034. https://datatracker.ietf.org/doc/html/rfc4034; "Protocol Modifications for the DNS Security Extensions." RFC 4035. https://datatracker.ietf.org/doc/html/rfc4035

[5] P. Hoffman, P. McManus. "DNS Queries over HTTPS (DoH)." RFC 8484, October 2018. https://datatracker.ietf.org/doc/html/rfc8484

[6] Google. "Google Public DNS: Introduction." https://developers.google.com/speed/public-dns/docs/intro