DNS: A Complete Guide to the Domain Name System

What DNS is and why every internet connection needs it

The Domain Name System is the phonebook of the internet. Every time you open a browser, send an email, or fetch an API, your machine performs a DNS lookup. Without DNS, you would have to type raw IP addresses, 142.250.190.78 for Google, 151.101.1.140 for Reddit, into every address bar. The system translates human-readable names like example.com into the numeric addresses that routers and switches use to forward packets.

Paul Mockapetris invented DNS in 1983, replacing the single HOSTS.TXT file that the ARPANET had outgrown. That file was a plain text list of every hostname and its IP, maintained by the Stanford Research Institute. As the network grew from dozens of hosts to hundreds, that model broke. DNS solved the problem with a distributed, hierarchical database. No single server holds every name. Instead, authority is delegated down the tree: root servers know about TLD servers, TLD servers know about authoritative servers for each domain, and so on.

What a DNS resolver actually does

When you type www.example.com into a browser, your operating system sends a query to a resolver (usually run by your ISP or a public provider like Cloudflare at 1.1.1.1 or Google at 8.8.8.8). The resolver walks through the hierarchy: it asks a root server which server handles .com, then asks the .com TLD server who is authoritative for example.com, then asks that authoritative server for the IP of www.example.com. It returns the answer to your machine, usually caching it locally for a period set by the domain owner (the TTL, or time to live).

Without DNS, most internet services stop working

This is not a theoretical problem. When DNS infrastructure goes down, millions of users cannot reach any site in an affected domain. A misconfigured delegation can orphan an entire company’s email. TLD outages, like the .com root zone glitch in 2018 that sent truncated data from Verisign’s servers, caused partial failures for days. Because DNS is a single point of dependency for nearly every internet protocol, HTTP, SMTP, SSH, SIP, LDAP, a DNS failure is effectively an internet failure for that name space.

DNS maps not just web sites but email servers (MX records), security policies (TXT records with SPF and DKIM), and even cryptographic fingerprints (CAA records for certificate authorities). Choosing a reliable DNS provider, setting proper TTLs, and monitoring query success rates are basic operational requirements. Most web developers and sysadmins spend their day debugging higher-level protocols, but nearly every connection starts with a DNS query.

How a DNS lookup actually flows, root to authoritative

A DNS lookup is not a single query to one server. It is a chain of queries that walks from the top of the namespace down to the server that holds the final answer. Understanding this chain matters because every hop adds latency, and knowing where delays come from is the first step to fixing them.

The process starts when an application such as a web browser calls getaddrinfo(). The operating system first checks its local DNS cache. On Linux that cache is usually managed by systemd-resolved or dnsmasq. Windows uses the DNS Client service. If the name is not cached, the resolver configured on the system (typically a recursive resolver at your ISP, 8.8.8.8, or 1.1.1.1) takes over.

Step 1: The root servers

The recursive resolver cannot guess the answer. It sends a query to one of the 13 root server addresses. There are 13 logical names (a.root-servers.net through m.root-servers.net) but 190+ physical instances running on anycast. The root does not know where example.com lives. It only knows where the .com Top Level Domain (TLD) servers are. It responds with a referral: a set of NS records for .com along with glue records so the resolver can reach them.

Step 2: The TLD servers

The resolver now queries a .com TLD server. These servers are run by Verisign under contract with ICANN. The TLD server does not know the IP of www.example.com. It only knows the servers authoritative for example.com. It responds with the NS records for the domain (e.g. ns1.example.com and ns2.example.com) and the glue records if those names are inside the domain itself.

Step 3: The authoritative servers

Finally, the resolver queries one of the domain's authoritative servers. That server sees the full query for www.example.com and returns the actual A or AAAA record. The resolver caches this answer according to the TTL and passes it back to your machine.

How dig shows the whole path

You can walk this chain manually with dig. To see the referral from the root to .com:

dig @a.root-servers.net example.com

To see the TLD referral:

dig @a.gtld-servers.net example.com

And to get the final answer:

dig @ns1.example.com www.example.com

In practice, a recursive resolver does all three steps for you. Most resolvers also maintain a cache of root hints and TLD delegations, so they rarely need to repeat steps 1 and 2. The full walk happens once per TTL period per domain name in the delegation chain.

Every record type explained (A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, PTR)

DNS records are stored in a zone file on an authoritative nameserver. Each record has a type, TTL, and type-specific data. The ten types below cover almost everything you will encounter.

A and AAAA records

An A record maps a hostname to an IPv4 address. For example, example.com A 93.184.216.34. The AAAA record does the same for IPv6: example.com AAAA 2606:2800:220:1:248:1893:25c8:1946. Virtually every domain needs at least one A or AAAA record. You can have multiple A records pointing to different IPs for round-robin load balancing, but modern setups usually hand that off to a load balancer.

CNAME records

A CNAME (canonical name) points one name to another name. It cannot coexist with any other record type at the same name. For instance, www.example.com CNAME example.com means the www subdomain inherits all records from the apex. The DNS specification (RFC 1034) forbids a CNAME at the zone apex because the SOA and NS records already live there. Many DNS providers work around this with a synthetic ALIAS or ANAME record, but those are not standard DNS record types.

MX records

Mail exchange records tell email servers where to deliver mail for a domain. Each MX record has a priority number; lower values are preferred. Example: example.com MX 10 mail.example.com. The target must be a hostname, not an IP address. RFC 5321 requires the hostname to resolve to an A or AAAA record. A common mistake is pointing MX to a CNAME. Mail servers technically support it, but many do not follow the CNAME chain.

TXT records

TXT records hold arbitrary text, originally for human notes. Today they carry machine-readable data: SPF/DKIM/DMARC email authentication, domain verification tokens, and miscellaneous policy statements. The value is a quoted string. Example: example.com TXT "v=spf1 mx ~all". TXT records have no length limit per se, but UDP DNS limits them to around 512 bytes without EDNS0. Modern DNS always uses EDNS0, but keep TXT values under 512 bytes to avoid truncation.

NS records

Nameserver records delegate a zone to a set of authoritative servers. They appear both in the parent zone and in the zone itself (glue records for in-bailiwick names). Example: example.com NS ns1.example.com. Most domains have at least two nameservers for redundancy. You can delegate subdomains by adding NS records pointing to other nameservers.

SOA records

The Start of Authority record begins every zone file. It contains the primary nameserver, the responsible admin email, and five time parameters: serial, refresh, retry, expire, minimum TTL. The serial number is a version stamp; secondary nameservers check it to see if they need to transfer the zone. Common convention uses YYYYMMDDNN format, though any 32-bit integer works. Example: example.com SOA ns1.example.com admin.example.com 2025010101 3600 900 604800 300.

SRV records

Service records (RFC 2782) specify the location of a particular service: protocol, port, and hostname. Format: _service._proto.name SRV priority weight port target. Example: _sip._tcp.example.com SRV 10 5 5060 sip.example.com. Weight values allow load balancing. SRV is widely used for SIP, XMPP, and Active Directory LDAP. Not all applications support it.

CAA records

Certification Authority Authorization (RFC 6844) lets domain owners specify which certificate authorities can issue certificates for the domain. A CAA record looks like: example.com CAA 0 issue "letsencrypt.org". Without CAA, any CA can issue a certificate (subject to domain validation). Most CAs check CAA, but the standard is not a security guarantee; it is a policy hint. You can add multiple CAA records for different CAs or set an issuewild tag for wildcard certs.

PTR records

PTR records map IP addresses back to hostnames, the reverse of A/AAAA. They live in special zones under .in-addr.arpa for IPv4 and .ip6.arpa for IPv6. Typically you do not manage these yourself; your ISP or hosting provider does. Example: 34.216.184.93.in-addr.arpa PTR example.com. PTR records are used for reverse DNS lookups in mail server verification and logging.

Recursive resolvers vs authoritative servers

The DNS infrastructure relies on two fundamentally different server roles. Understanding the difference between them is essential for diagnosing lookup failures, configuring DNS software, and choosing where to host your zones.

An authoritative server holds the actual DNS records for a domain. It is the source of truth. When you register a domain and add A, MX, or NS records through your DNS provider, those records live on authoritative servers. An authoritative server answers queries only for zones it knows about. If asked about a domain it does not manage, it responds with a refusal or no answer. Authoritative servers do not go looking for answers elsewhere. Their job is to publish your data and let the rest of the internet find it. For example, Cloudflare's ns1.cloudflare.com is an authoritative server for millions of domains. It never caches or recursively resolves external domains.

A recursive resolver (often called a caching resolver) is the workhorse that clients talk to. When you type a domain into a browser, your computer sends the query to a recursive resolver. That resolver does the legwork: starting at the root hints, it follows delegations to the TLD server, then to the authoritative server for the domain, and finally returns the answer to the client. The resolver caches the result according to the record's TTL value. Well known public resolvers include Google Public DNS (8.8.8.8), Cloudflare's 1.1.1.1, and Quad9 (9.9.9.9). ISPs also run recursive resolvers for their customers.

The line between the two roles can blur. A server can run recursive resolution and serve authoritative zones at the same time, but this is rarely a good idea. BIND, the oldest widely used DNS server software, can run as both a recursive resolver and an authoritative server on the same machine. However, doing so opens up a host of security and performance issues. For example, a resolver that also serves authoritative zones can be tricked into poisoning its cache for domains it thinks it owns. Modern best practice is to run separate instances: one for recursive resolution (listen on 127.0.0.1 or a LAN interface), another (or a cluster using a hidden master) for authoritative answers.

When you run dig example.com, the client sends the query to the configured resolver. The resolver does the recursion. If you add the +norecurse flag, you ask the server to answer only from its local cache or its own authority, which simulates how an authoritative server alone would respond. This flag is useful for testing whether a resolver is actually recursing or blindly forwarding queries.

TTL and caching: how it speeds things up and breaks things

Every DNS response includes a Time To Live (TTL) value. The TTL tells the receiver how many seconds it can cache the record before asking again. RFC 1035 defined the original TTL field as a 32-bit integer, allowing values up to 2^31-1 seconds (about 68 years), though practical TTLs range from 30 seconds to 86400 seconds (one day).

Caching is what makes DNS usable at internet scale. Without it, every website visit would require a full traversal from root servers to the authoritative nameserver. Recursive resolvers (like 8.8.8.8 or your ISP's resolver) cache answers and serve them to thousands of users. Browser and operating system caches add another layer. The result: most lookups never hit an authoritative server.

How TTL values work in practice

When you query a recursive resolver for example.com, the resolver stores the answer along with its TTL. It decrements the TTL internally. If another client asks for the same record within the TTL window, the resolver returns the cached answer immediately. After the TTL expires, the resolver discards the record and performs a fresh lookup.

Typical TTLs by record type:

• A/AAAA records: often 300-3600 seconds (5 minutes to 1 hour). CDNs like Cloudflare may use 120-300 seconds to allow fast traffic shifting.
• MX records: 3600 seconds (1 hour) is common. Email systems tolerate longer caching.
• TXT records: 3600 seconds for SPF or DKIM, though verification tools may suggest shorter.
• SOA record: the minimum TTL field in the SOA (often 3600) controls negative caching (NXDOMAIN responses) per RFC 2308.

Negative caching: caching failures

When a recursive resolver gets an NXDOMAIN (domain does not exist) or NODATA (record type missing) response, it caches that failure too. The SOA record's minimum TTL sets the negative cache lifetime. This prevents repeated queries for nonexistent names, but it also means a newly created subdomain may be invisible for hours if the negative cache hasn't expired.

Why caching breaks things

TTL and caching cause three common problems:

1. Propagation delay: After changing a DNS record (e.g., switching web hosts), old cached values persist until TTLs expire. If your old TTL was 86400 seconds (24 hours), users may see the old IP for a full day. Best practice: lower the TTL to 300 seconds at least 48 hours before a planned change, then raise it back after the change propagates.
2. Stale records during failover: If a server goes down, DNS-based failover is slow because resolvers cache the old IP. Services like AWS Route 53 use health checks and short TTLs (60 seconds) to mitigate this, but not all resolvers honor sub-60-second TTLs.
3. Resolver non-compliance: Some ISP resolvers ignore TTLs and cache records for longer than specified. This is a violation of RFC 1035 but still happens. You can check with dig +noall +answer example.com and compare the TTL in the response to the authoritative TTL.

Checking TTLs with dig

The dig command shows the remaining TTL in the answer section. For example:

dig +noall +answer example.com
;example.com. 86399 IN A 93.184.216.34

The number 86399 is the remaining TTL in seconds. To see the authoritative TTL (the original value set by the zone administrator), query the authoritative nameserver directly:

dig @ns1.example.com example.com +noall +answer

If the two values differ significantly, an intermediate resolver is extending the cache beyond the intended TTL.

DNSSEC and why most people still don't run it

DNSSEC (Domain Name System Security Extensions) adds a layer of cryptographic verification to DNS responses. Without it, a resolver has no way to tell whether the A record it received for example.com actually came from the real example.com authoritative server, or from an attacker who poisoned the cache along the way. DNSSEC uses public key cryptography: each zone signs its records with a private key, and resolvers verify those signatures using public keys published in the zone itself and anchored at the parent zone (the root or TLD).

The core standards are RFC 4033, RFC 4034, and RFC 4035. A DNSSEC-enabled zone publishes several new record types: RRSIG (signatures), DNSKEY (public keys), NSEC or NSEC3 (proof of non-existence), and DS (delegation signer) records in the parent zone. The DS record creates a chain of trust: the root zone signs the .com zone's key, .com signs example.com's key, and so on. A resolver that is configured to validate DNSSEC (like 1.1.1.1 or 8.8.8.8) will query up the chain to verify every signature. If any signature fails, the resolver returns SERVFAIL.

So why do so few domains run DNSSEC? As of early 2025, roughly 35% of .com domains have DS records in the registry. For smaller TLDs the number is often lower. The main reasons are operational complexity and risk. Generating and rotating keys properly is harder than it sounds. A zone signing key (ZSK) needs to be flipped every few months; a key signing key (KSK) every year or two. Lose the private key and your zone goes dark. Automating key rollover with tools like dnssec-keygen and pdnsutil helps, but many small DNS operators find the manual steps intimidating.

Another barrier: DNSSEC can break when a hosting provider doesn't support it. If you use a third party DNS service and a separate registrar, you need to copy the DS record from the provider to the registrar. If the DS record doesn't match, your domain becomes unreachable for anyone using a validating resolver. The risk of silent misconfiguration has kept many sysadmins from enabling it. There is also a performance cost: larger responses (RRSIG records add 50-200 bytes per query) and more CPU for signature verification, though modern hardware handles this easily.

For web developers and sysadmins, the payoff of DNSSEC is elimination of certain cache poisoning attacks, like the Kaminsky attack (2008) and more recent off-path injection variants. But most internet users never notice when DNSSEC is off, because TLS/HTTPS already protects the content after the DNS lookup. DNSSEC protects the lookup itself. That distinction matters for email (MX records), for certificate issuance (CAA records), and for any service that trusts the DNS answer as an authentication mechanism. Until tooling improves and the ecosystem makes DNSSEC as easy as flipping a switch, adoption will remain a minority pursuit.

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

Traditional DNS sends queries and responses in cleartext over UDP or TCP, usually on port 53. This means anyone on the network path, your ISP, a coffee shop Wi-Fi operator, or an attacker on the same LAN, can see every domain you look up. DNS over TLS (DoT) and DNS over HTTPS (DoH) fix this by encrypting the DNS traffic between your client and a resolver.

DoT was standardized in RFC 7858 (May 2016). It wraps DNS in a TLS tunnel on a dedicated port, port 853. The resolver must present a valid TLS certificate, and the client verifies it. Because DoT uses a separate port, network administrators can identify and block or permit DoT traffic at the firewall. That visibility is a feature for some, a drawback for others.

DoH came a bit later, RFC 8484 (October 2018). It sends DNS queries inside HTTPS requests on port 443, the same port used for web traffic. To the network, DoH looks like ordinary HTTPS to a server like cloudflare-dns.com or dns.google. This makes DoH harder to block without also blocking all HTTPS traffic, which is impractical. It also makes it harder to inspect or log.

Which one should you use?

The choice often comes down to control versus privacy. DoT is simpler to audit on a corporate network: you allow port 853 outbound only to approved resolvers. DoH is better for evading censorship or ISP-level logging, because it blends into normal web traffic. For a home user who just wants their ISP out of their DNS traffic, either works fine.

Major public resolvers support both. Cloudflare's 1.1.1.1 offers DoT at 1dot1dot1dot1.cloudflare-dns.com and DoH at https://cloudflare-dns.com/dns-query. Google's 8.8.8.8 provides DoT at dns.google and DoH at https://dns.google/dns-query. Quad9 (9.9.9.9) supports both as well.

Enabling DoT or DoH on your system

Modern operating systems and browsers have built-in support. Android 9+ has a Private DNS mode that uses DoT. You set it to a hostname like dns.google and all system DNS queries go over TLS. iOS and macOS support DoT and DoH through configuration profiles or apps. Windows 11 added DoH support in network adapter settings for IPv4 and IPv6.

For browsers, Firefox has DoH built-in. Go to Settings, Network Settings, and enable DNS over HTTPS. Choose a provider like Cloudflare or NextDNS. Chrome on desktop uses the system resolver by default, but you can enable a flag (chrome://flags/#dns-over-https) to use a hardcoded DoH provider.

If you run your own resolver like Unbound, you can configure it to forward queries over TLS. In unbound.conf:

forward-zone:
 name: "."
 forward-tls-upstream: yes
 forward-addr: 1.1.1.1@853#cloudflare-dns.com
 forward-addr: 8.8.8.8@853#dns.google

That forwards all queries to Cloudflare and Google over DoT. The # part is the TLS authentication name, which must match the resolver's certificate.

One important caveat: DoH and DoT only encrypt the transport between your client and the resolver. They do not add authentication to the DNS data itself. That is what DNSSEC does. You can (and should) use both: DoH or DoT to protect the channel, DNSSEC to validate the response.

Anycast DNS: how Cloudflare and Google answer in milliseconds

When you run dig google.com from a server in Frankfurt and a colleague runs the same command from a laptop in Tokyo, you both query the same authoritative nameservers: ns1.google.com, ns2.google.com, and so on. But the responses arrive in milliseconds from both locations. That is not because Google operates a single server farm that is magically equidistant from Germany and Japan. It is because Google uses Anycast.

Under normal (unicast) routing, each server has a unique IP address. If Google published ns1.google.com as a unicast address, traffic from Frankfurt would route to whichever data center that address lived in. Clients far from that data center would suffer higher latency. Anycast solves this by announcing the same IP prefix from multiple physical locations. BGP (Border Gateway Protocol, RFC 4271) causes routers in Frankfurt to send traffic to the nearest Google data center in Europe, while routers in Tokyo send traffic to a Google data center in Asia. The network itself decides which instance answers.

Latency and resilience

Anycast drops lookup times dramatically. Cloudflare operates from over 330 cities as of 2025 (they call this the global network, but it is really Anycast BGP announcements at each location). Their 1.1.1.1 resolver uses Anycast across all of those sites. A query from a user in Cape Town hits a local Cloudflare cache, not a server in San Francisco. The same Anycast technique powers Cloudflare's authoritative DNS: when you use Cloudflare as your DNS provider, your records are served from the nearest of those 330+ locations.

Anycast also provides instant failover. If one data center loses power or suffers a DDoS attack, BGP withdraws that route. Traffic shifts to the next closest site within seconds. This is why major DNS providers survive attacks that would flatten a single data center.

Common Anycast DNS providers

Beyond Cloudflare and Google Public DNS (8.8.8.8, 8.8.4.4), any large DNS operator uses Anycast:

• Amazon Route 53 uses Anycast across multiple AWS regions via ns-*.awsdns-*.com.
• Azure DNS uses Anycast via ns1-*.azure-dns.com.
• Quad9 (9.9.9.9) runs Anycast resolvers in over 200 locations.
• OpenDNS (208.67.222.222, 208.67.220.220) has used Anycast since 2006.

Pitfalls for authoritative DNS

When you host your own DNS servers from a single /24 netblock and announce them via BGP, the Anycast behavior depends on your upstream provider. Most managed DNS providers handle this for you. One thing to watch: if you run DNSSEC with a short TTL and rely on Anycast, ensure all Anycast instances have synchronized signing keys and the same zone content. A stale secondary instance can serve expired signatures, causing validation failures.

Anycast is not magic. It is routing trickery that leverages BGP's shortest-path selection. But for DNS, it is the difference between a 200 ms lookup and a 5 ms lookup.

Common DNS problems and how to debug them with dig

When DNS breaks, the effect is instant: sites go dark, email stops flowing, and users blame the network. The good news is that dig (Domain Information Groper) is the single most useful tool for figuring out why. It ships with BIND but you can install it separately on any OS. You do not need a GUI or a web portal. This section walks through the most common DNS failures and the exact dig incantations that expose them.

No answer or NXDOMAIN

The simplest problem: a query returns nothing, or returns NXDOMAIN (non-existent domain). Run a baseline query first:

dig example.com A +noall +answer

If you see nothing, check whether the domain exists at all by querying the authoritative name servers directly. Use +trace to follow the delegation chain from root to authority:

dig example.com A +trace

The trace output shows you which name servers were queried at each step and which one gave the NXDOMAIN. If the zone’s NS records point to servers that no longer serve the zone, you will see SERVFAIL after the delegation step. Compare the NS records in the TLD with what the registrar shows. They must match.

Wrong answers from a misconfigured recursive resolver

Sometimes a recursive resolver caches a stale or poisoned record. Bypass the resolver entirely by querying the authoritative servers with the +norecurse flag and specifying the NS IP:

dig @192.0.2.1 example.com A +norecurse

If this gives the correct answer but your local dig without the @ gives something else, the problem is a broken intermediary resolver or a stale cache. Flush your local resolver or wait for the TTL to expire (see TTL section above for how TTLs interact with caching).

SOA serial number checks for propagation delays

After changing a record (or adding one), you want to know if the change has reached all authoritative servers. Compare the SOA serial across multiple authoritative servers:

dig @ns1.example.com example.com SOA +short
 dig @ns2.example.com example.com SOA +short

If the serials differ, the secondary server has not picked up the zone transfer yet. Zone transfers happen via AXFR or IXFR. You can test whether a server allows zone transfers (a security hole if open) with:

dig @ns1.example.com example.com AXFR

DNSSEC validation failures

When DNSSEC is enabled but a delegation is broken, clients see SERVFAIL even though the record itself exists. Use +dnssec to see the RRSIG records and +cd to disable validation on the resolver:

dig @8.8.8.8 example.com A +dnssec +multiline
 dig @8.8.8.8 example.com A +cd

Compare. If the +cd query returns a valid answer but the plain query returns SERVFAIL, the resolver thinks the DNSSEC chain is broken. Run delv (also part of BIND) for a detailed validation trace:

delv +vtrace example.com A

Slow resolution or timeout

Measure query time with dig +stats or look at the Query time line in default output. If it is over a second, try switching to a faster resolver like @1.1.1.1 or @8.8.8.8. For authoritative servers, use dig +time=2 +tries=1 to set a two-second timeout and one retry. A server that never responds within that window is effectively down.

Picking a managed DNS provider

Once your site or service outgrows a single server, running your own authoritative DNS becomes more trouble than it is worth. You need multiple nameservers in different data centers, DDoS protection for your zone, fast failover, and API access for automation. That is when you start looking at managed DNS providers. The market is crowded, but the differences between providers come down to four things: network architecture, feature set, pricing model, and support quality.

Anycast networking is the baseline for performance today. A provider like Cloudflare (which launched its DNS service in 2015) or AWS Route 53 uses Anycast to broadcast the same nameserver IPs from dozens of locations. A query from a user in Tokyo hits a nearby PoP, not a server in Virginia. If a provider still uses unicast-only nameservers (a single IP per server), your global users will see slower resolution. Check the provider's PoP count. Cloudflare claims 330+ cities. Nexigen offers DNS Made Easy with 18+ global nodes. The right number depends on your audience, but anything under 10 Nodes in different continents is a red flag for a global site.

Feature depth matters more as your zone grows. DNSSEC signing should be one-click and free. Not all providers support all record types. For example, some budget DNS hosts still do not serve CAA or SSHFP records properly. Look for native support of ALIAS or ANAME records (sometimes called CNAME flattening) so you can point an apex domain at a CDN without breaking MX records. API support is critical for infrastructure-as-code shops. Route 53 has the richest AWS SDK integration, but Cloudflare's API is well-documented and has Terraform providers for both. DDoS mitigation is another differentiator. A SYN flood hitting your nameservers can knock your zone offline. Cloudflare and NS1 offer built-in DDoS protection at the network layer. Smaller providers may rely on upstream filtering from their data center provider.

Pricing varies wildly. Some providers charge per zone per month, some charge per million queries, and some bundle DNS free with other services. Cloudflare's free plan is genuinely usable for many personal and small business sites, but it has limits (you cannot use it with non-Cloudflare proxied records on the free tier). Route 53 charges $0.50 per hosted zone per month plus $0.40 per million queries, which adds up fast for high-traffic zones. DNS Made Easy charges by query volume and zone count. A site with 10 zones and 5 million queries per month could pay $30 to $200 depending on provider. Read the fine print on overage charges.

Finally, consider management overhead. Some providers give you a simple web UI and little else. Others, like NS1, offer traffic steering rules based on user geography or server health. If you need automated failover (switching records when your origin is down), you need health checks. Route 53 has them built in. Cloudflare's load balancing is a separate paid product. Pick the provider whose complexity matches your team size. A five-person startup does not need NS1's filtering rules, and a busy ecommerce site should not rely on a three-person DNS company.