DEV Community: Kishore Bhavnanie

DNS Rebinding and NXDOMAIN Hijacking: Two Overlooked DNS Attacks

Kishore Bhavnanie — Fri, 19 Jun 2026 13:39:48 +0000

Most DNS attacks people know about involve changing where a domain points: cache poisoning, hijacking, subdomain takeover. But two of the more insidious DNS attack techniques work differently. DNS rebinding turns a victim's own browser into a tool for reaching systems it should never be able to touch. NXDOMAIN hijacking exploits the moment when a domain doesn't exist, turning "not found" into an opportunity for manipulation. Neither is as widely understood as it should be, and both remain relevant threats.

These attacks are worth understanding because they exploit legitimate DNS behavior rather than breaking it. They don't require compromising your nameservers or stealing credentials. They abuse the way DNS and browsers are designed to work, which makes them harder to spot and defend against.

This guide explains both attacks, how they work, who they target, and what defends against them.

DNS Rebinding: Turning a Browser Against Its Own Network

DNS rebinding is an attack that lets a malicious website bypass the browser's same-origin policy to interact with devices and services on the victim's local network, the very systems a remote attacker normally can't reach.

The Problem It Exploits

Browsers enforce a same-origin policy: a script from evil.com can't read responses from yourcompany-internal.local or 192.168.1.1. This is a fundamental web security boundary. But the same-origin policy is based on the hostname, not the IP address. DNS rebinding exploits the gap between the two.

How the Attack Works

The victim visits a malicious site. They load attacker.com, perhaps through an ad, a link, or a compromised page. The attacker controls the DNS for this domain.
The first DNS response is legitimate. When the browser resolves attacker.com, the attacker's nameserver returns the attacker's real server IP, with a very short TTL (a few seconds). The malicious JavaScript loads and runs.
The attacker "rebinds" the domain. After the page loads, the short TTL expires. The malicious script makes another request to attacker.com. This time, the attacker's nameserver responds with a different IP, an internal address like 192.168.1.1 (the victim's router) or 127.0.0.1 (their own machine).
The browser now talks to the internal target. As far as the browser's same-origin policy is concerned, the script is still talking to attacker.com, the origin hasn't changed. But the requests now go to the internal IP. The attacker's script can now interact with the victim's router admin panel, local services, internal APIs, or IoT devices, reading responses and sending commands.

The attack effectively uses the victim's browser as a proxy into their own private network, defeating the network boundary that would normally protect those internal systems from the internet.

What DNS Rebinding Targets

Router and gateway admin interfaces (often at predictable IPs like 192.168.1.1 with default or weak credentials)
IoT and smart home devices with local web interfaces and little authentication
Internal services and APIs that assume "if you can reach me, you're trusted" because they're not exposed to the internet
Local development servers and admin tools running on the victim's own machine

The core danger is that many internal services have weak or no authentication precisely because they rely on network isolation for protection. DNS rebinding breaks that isolation.

Defending Against DNS Rebinding

DNS rebinding protection in resolvers: Many resolvers and DNS filtering services can block responses where an external domain resolves to a private/internal IP address. This is the most effective network-level defense. Some routers and resolvers (and tools like a configured Pi-hole or NextDNS) offer this.
Host header validation: Internal services should validate the Host header and reject requests that don't match their expected hostname. Since the rebinding attack sends requests with the attacker's domain in the Host header, strict validation blocks them.
Authentication on internal services: Never rely solely on network isolation. Internal admin panels, routers, and APIs should require authentication, so reaching them isn't enough to control them.
HTTPS on internal services: TLS certificate validation adds another barrier the attack must overcome.

NXDOMAIN Hijacking: Exploiting "Does Not Exist"

NXDOMAIN is the DNS response code meaning "this domain does not exist." NXDOMAIN hijacking (also called NXDOMAIN substitution or redirection) is the practice of intercepting these "does not exist" responses and replacing them with something else, usually a page the interceptor controls.

How It Works

When you type a domain that doesn't exist, you should get an NXDOMAIN response and your browser shows an error. In NXDOMAIN hijacking, an intermediary, often an ISP or a resolver, intercepts that NXDOMAIN and instead returns an IP address pointing to their own server, typically showing a search page, ads, or a "did you mean?" page.

This was historically common among ISPs, who monetized typos and mistyped domains by redirecting NXDOMAIN responses to ad-laden search pages. While it might seem like a minor annoyance, it has real security implications.

Why It's a Security Problem

It breaks the expected "does not exist" signal. Applications and security tools that rely on NXDOMAIN to detect non-existent domains get a false "this exists" answer, which can mask problems or break functionality.
It creates an injection point. An intermediary substituting DNS responses is, by definition, manipulating your traffic. If that intermediary is malicious or compromised, the same mechanism used for ad redirection can be used to redirect real traffic.
It interferes with security mechanisms. Some security and anti-malware systems use NXDOMAIN responses as signals. Substituting them can blind these systems or cause false results.
It can expose user behavior. The intermediary sees every mistyped or non-existent domain a user queries, a privacy concern.

NXDOMAIN and Attack Detection

There's an important defensive flip side. Monitoring NXDOMAIN patterns is actually a useful security signal. A sudden spike in NXDOMAIN responses from inside a network can indicate malware using a domain generation algorithm (DGA), where malware algorithmically generates many candidate domains to find its command-and-control server. Most generated domains don't exist (NXDOMAIN), so a flood of NXDOMAIN responses is a red flag. NXDOMAIN hijacking that masks these responses can hide this signal, which is another reason it's problematic.

Defending Against NXDOMAIN Hijacking

Use a trustworthy resolver. Reputable public resolvers (and properly configured private ones) return honest NXDOMAIN responses rather than substituting them. Choosing a resolver that doesn't hijack NXDOMAIN is the first step.
Use encrypted DNS (DoH/DoT). DNS over HTTPS and DNS over TLS prevent on-path intermediaries from seeing and modifying your DNS queries and responses, blocking the interception that NXDOMAIN hijacking relies on. We cover these in our DoH vs DoT guide.
DNSSEC for your own domains. While DNSSEC doesn't directly stop NXDOMAIN substitution for domains you query, it does cryptographically authenticate responses for signed domains, including authenticated denial of existence (proving a name really doesn't exist), which prevents forged NXDOMAIN-related manipulation for your zones.

What These Attacks Have in Common

DNS rebinding and NXDOMAIN hijacking both share a defining characteristic: they exploit DNS as a manipulation layer rather than attacking DNS records directly. They don't change your A record or compromise your nameserver. Instead, they abuse the resolution process itself, the short-TTL re-resolution in rebinding, the response substitution in NXDOMAIN hijacking.

This makes them different from the attacks much of DNS security focuses on. They're a reminder that DNS security isn't only about protecting your own records from unauthorized change; it's also about the integrity of the resolution process that connects users to your domain, and the systems that process DNS responses.

How DNS Assistant Fits In

DNS Assistant focuses on monitoring the security posture of your own domains, the authoritative side of DNS. While rebinding and NXDOMAIN hijacking are primarily resolver-side and client-side attacks, strong posture on your own domains is part of the broader defense:

DNSSEC validation monitoring ensures your domains are properly signed, enabling authenticated denial of existence and protecting against forged responses for your zones.
Record monitoring ensures your legitimate records are correct and unchanged, so the authoritative answers feeding resolvers are trustworthy.
Continuous validation of your DNS configuration, with alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Defending against rebinding and NXDOMAIN hijacking primarily involves resolver choice, encrypted DNS, internal service authentication, and host-header validation, but maintaining strong DNSSEC and record integrity on your own domains is the authoritative-side contribution to a healthy DNS ecosystem.

Check Your DNS Posture

Verify your domains are properly signed with DNSSEC and your records are correct using the DNS lookup tool at dnsassistant.com/tools, or run a Free Domain Risk Report for a comprehensive view including DNSSEC status.

For continuous monitoring of your DNS security posture with real-time alerting, sign up at dnsassistant.com.

This article describes attack techniques for educational and defensive purposes, to help you understand and protect against them. The information reflects publicly documented security research on DNS rebinding and NXDOMAIN manipulation.

How to Read DNS Lookup Output (dig, nslookup, and What It All Means)

Kishore Bhavnanie — Fri, 19 Jun 2026 13:13:47 +0000

You run a DNS lookup, and a wall of text scrolls past: ANSWER SECTION, flags, TTLs, record types, a status code, some numbers you don't recognize. Most people glance at the IP address they were looking for and ignore the rest. But that "rest" is full of useful information: whether the answer is authoritative, how long it will be cached, whether DNSSEC validated, and clues about why something isn't resolving the way you expect.

Learning to read DNS lookup output turns these tools from black boxes into precise diagnostic instruments. Whether you use dig on the command line, nslookup, or a web-based lookup tool, the underlying information is the same, and once you can read it, troubleshooting DNS becomes far less mysterious.

This guide walks through what each part of DNS lookup output means, using dig as the primary example since it's the most detailed, then covering nslookup and what to look for when things go wrong.

A Complete dig Output, Annotated

Here's a typical dig command and its full output. We'll break down every section.

$ dig example.com A

; <<>> DiG 9.18.1 <<>> example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14823
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 19 10:15:42 UTC 2026
;; MSG SIZE  rcvd: 56

The Header Line

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14823

This is the most important line for diagnosing problems. The key field is status:

NOERROR means the query succeeded. (Note: NOERROR doesn't always mean you got the record you wanted, it can also mean "the name exists but has no record of this type.")
NXDOMAIN means the domain name does not exist. If you see this for a domain you expect to work, the name is wrong, the domain is unregistered or expired, or there's a delegation problem.
SERVFAIL means the server failed to complete the query. This often indicates a DNSSEC validation failure, a broken delegation, or a problem at the authoritative server. SERVFAIL is one of the most common symptoms of DNSSEC misconfiguration.
REFUSED means the server refused to answer, often a permissions or configuration issue.

The opcode: QUERY is the operation type (almost always QUERY), and id is a transaction identifier matching the query to its response.

The Flags

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

The flags tell you about the nature of the response:

qr (query response): this is a response, not a query.
aa (authoritative answer): the responding server is authoritative for this domain. If you query an authoritative nameserver directly, you'll see aa. If you query a recursive resolver that fetched the answer on your behalf, you won't, the answer came from cache or recursion, not from authority. This distinction matters, and we cover it fully in our authoritative vs recursive DNS guide.
rd (recursion desired): the query asked the server to recurse.
ra (recursion available): the server is willing to recurse.
ad (authenticated data): DNSSEC validation succeeded. If you see ad, the resolver cryptographically validated the answer. Its absence on a signed domain can indicate a validation problem.

The counts (QUERY: 1, ANSWER: 1, ...) tell you how many records are in each section of the response.

The Question Section

;; QUESTION SECTION:
;example.com.                   IN      A

This simply echoes back what you asked: the name (example.com.), the class (IN for Internet), and the record type (A). It confirms the server understood your query. The trailing dot on the name indicates it's fully qualified.

The Answer Section

;; ANSWER SECTION:
example.com.            3600    IN      A       93.184.216.34

This is what you came for. Reading left to right:

example.com. is the name that was queried.
3600 is the TTL in seconds, how long this record can be cached. If you query a recursive resolver repeatedly, you'll see this number counting down as the cached entry ages, which is a handy way to tell you're getting a cached answer. We explain TTL behavior in our TTL best practices guide.
IN is the class (Internet).
A is the record type.
93.184.216.34 is the actual data, the IP address.

If a domain has multiple A records (round-robin), you'll see multiple lines here. For other record types, the data column changes accordingly: an MX record shows a priority and mail server, a TXT record shows quoted text, a CNAME shows the alias target.

The Authority and Additional Sections

When present, the AUTHORITY SECTION lists the authoritative nameservers for the domain (NS records). The ADDITIONAL SECTION provides extra helpful records, often the IP addresses (glue records) of the nameservers mentioned in the authority section, saving an extra lookup.

The OPT PSEUDOSECTION you may see relates to EDNS (Extension Mechanisms for DNS), which enables features like larger UDP packet sizes and DNSSEC. It's not a real record, just protocol-level information.

The Footer: Timing and Server Info

;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 19 10:15:42 UTC 2026
;; MSG SIZE  rcvd: 56

Query time is how long the lookup took. A high value can indicate a slow resolver or a distant authoritative server.
SERVER is which resolver answered, and the port (53 is standard DNS). This tells you whether you queried your local resolver, a public one, or an authoritative server directly.
WHEN is the timestamp of the query.
MSG SIZE is the response size in bytes.

Useful dig Variations

A few common dig commands and what they're for:

dig example.com → defaults to an A record lookup.
dig example.com MX → look up mail servers. Swap MX for any type (TXT, NS, SOA, CAA, AAAA).
dig example.com ANY → request all record types (though many servers now limit ANY responses).
dig +short example.com → just the answer data, no surrounding detail. Good for scripts.
dig +trace example.com → trace the resolution from the root servers down, showing each delegation step. Excellent for diagnosing delegation problems.
dig @8.8.8.8 example.com → query a specific resolver (here, Google's), useful for comparing answers across resolvers.
dig +dnssec example.com → request DNSSEC records, showing RRSIG signatures and the ad flag if validation succeeds.

The +trace and @resolver variations are especially powerful for troubleshooting, which we cover more in our DNS troubleshooting guide.

Reading nslookup Output

nslookup is available on Windows, macOS, and Linux, and is often more familiar to Windows users. Its output is simpler but conveys similar core information:

$ nslookup example.com

Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

Key things to read:

Server / Address at the top is the resolver that answered.
Non-authoritative answer means the response came from a recursive resolver's cache or recursion, not directly from an authoritative server. (If it were authoritative, this line would be absent.) This is the nslookup equivalent of the missing aa flag in dig.
Name / Address is the result.

nslookup can also query specific types (nslookup -type=MX example.com) and specific servers (nslookup example.com 8.8.8.8), similar to dig. While dig gives more detail, nslookup is perfectly capable for everyday checks.

Diagnosing Common Problems From the Output

Here's how to read the output when something is wrong:

status: NXDOMAIN: the name doesn't exist. Check for typos, verify the domain is registered and not expired, and confirm the delegation is correct.
status: SERVFAIL: commonly a DNSSEC validation failure or a broken authoritative server. Try dig +cd (checking disabled) to bypass DNSSEC validation; if it works with +cd but fails without, you've found a DNSSEC problem.
NOERROR but empty ANSWER section: the name exists but has no record of the type you asked for. For example, querying an AAAA (IPv6) record for a domain that only has IPv4 returns NOERROR with no answer.
Missing aa flag when querying an authoritative server: you may not be querying the server you think you are, or the server isn't authoritative for that zone (possible lame delegation).
TTL counting down on repeated queries: you're hitting a cache. Query the authoritative server directly (find it via the NS records) to see the true current value.
Different answers from different resolvers: could indicate propagation in progress (a recent change still spreading) or, more concerningly, a problem. We explain propagation in our DNS propagation guide.

Using a Web-Based Lookup Tool

Command-line tools are powerful, but a web-based DNS lookup gives you the same core information without needing terminal access, and queries from a neutral external vantage point rather than your local network. This external perspective matters: your local resolver might have a cached or different answer than what the rest of the world sees.

The DNS lookup tool at dnsassistant.com/tools lets you query any record type for any domain and see the results clearly, including the values, types, and TTLs, without parsing raw dig output. It's an easy way to check what your domain is actually serving from outside your own network.

How DNS Assistant Helps

Reading lookup output is essential for one-off troubleshooting, but it's a manual snapshot. You only see what's happening at the moment you run the command. DNS Assistant performs these lookups continuously and interprets the results for you:

Continuous monitoring runs the equivalent of these lookups around the clock, so you don't have to manually check.
Change detection alerts you when any record's value changes, catching the things a one-time lookup would only reveal if you happened to run it at the right moment.
DNSSEC validation automatically checks the ad-flag equivalent and the full chain of trust, catching the SERVFAIL-causing problems before they affect users.
Multi-vantage perspective with alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Think of manual lookups as the diagnostic tool you reach for when investigating, and DNS Assistant as the continuous monitor that tells you when you need to investigate in the first place.

Try It Yourself

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and practice reading the results. Run a Free Domain Risk Report for a comprehensive interpreted view of your DNS configuration.

For continuous monitoring that reads your DNS for you and alerts on changes, sign up at dnsassistant.com.

Multi-Provider DNS: Why and How to Use Secondary DNS

Kishore Bhavnanie — Wed, 17 Jun 2026 22:52:25 +0000

In October 2016, a massive DDoS attack against the DNS provider Dyn took down a huge swath of the internet. Twitter, Reddit, Spotify, GitHub, Netflix, and countless other major sites became unreachable, not because their own infrastructure failed, but because the single DNS provider they all relied on was overwhelmed. Sites that used a second DNS provider stayed up. Sites that didn't went dark.

That event was a wake-up call for an uncomfortable truth: if all your DNS lives with one provider, that provider is a single point of failure for your entire online presence. No matter how resilient your own infrastructure is, a DNS provider outage takes you offline, and there's nothing you can do but wait for them to recover.

Multi-provider DNS, often implemented as secondary DNS, solves this. By serving your zone from two independent DNS providers, your domain stays resolvable even if one provider fails completely. This guide explains how it works, the different models, the tradeoffs, and how to set it up.

The Single-Provider Risk

When you use one DNS provider, your domain's resolution depends entirely on that provider's nameservers being available and answering correctly. This creates a dependency that sits above all your other infrastructure. Your servers can be perfectly healthy, your application flawless, your database replicated across regions, and none of it matters if the DNS that points to it stops resolving.

Single-provider failures happen for several reasons: large-scale DDoS attacks against the provider, provider infrastructure outages, BGP routing problems, or operational errors on the provider's side. These are outside your control, and when they happen, your only option with a single provider is to wait.

For many organizations, the risk is acceptable. Major providers are highly reliable, and occasional rare outages may be tolerable. But for businesses where downtime is costly, where DNS availability is mission-critical, multi-provider redundancy is the architectural answer.

How Multi-Provider DNS Works

The foundation of multi-provider DNS is that a domain can be served by nameservers from more than one provider simultaneously. Your nameserver delegation at the registrar lists nameservers from both providers. When a resolver looks up your domain, it can query any of the listed nameservers, and as long as one provider's nameservers respond correctly, resolution succeeds.

For this to work, both providers must serve the same records. If they disagree, resolvers get inconsistent answers depending on which provider they happen to query. Keeping the two providers synchronized is the central challenge of multi-provider DNS, and there are two main approaches.

Primary-Secondary (Zone Transfer) Model

This is the traditional model, and it's where the term "secondary DNS" comes from.

In this setup, one provider is the primary (also called the master / hidden primary), holding the authoritative copy of your zone where you make changes. The other provider is the secondary (or slave), which automatically pulls a copy of the zone from the primary.

The synchronization happens through zone transfers:

AXFR (full zone transfer) copies the entire zone from primary to secondary.
IXFR (incremental zone transfer) copies only the changes since the last transfer, which is more efficient.
NOTIFY messages let the primary tell the secondary "the zone changed, come get the update," so changes propagate quickly rather than waiting for the secondary's refresh interval.

You make all your changes at the primary. The secondary detects the change (via NOTIFY or its refresh schedule), pulls the updated zone via zone transfer, and begins serving the new records. Both providers then answer queries with identical data.

The SOA record's serial number drives this: the secondary compares its serial against the primary's, and when the primary's is higher, it knows to transfer. This is one of the practical reasons the SOA serial matters, as we covered in our zone file guide.

Hidden Primary

A common variation is the "hidden primary," where the primary nameserver isn't listed in your delegation at all. It exists only to feed the secondaries via zone transfer. The publicly visible nameservers are all secondaries pulling from the hidden primary. This keeps your authoritative source private and lets you treat the public-facing providers uniformly.

Multi-Primary (Dual Provider) Model

The newer model, increasingly common with modern managed DNS providers, is multi-primary, where both providers are independently authoritative and you push the same configuration to both.

Instead of one provider pulling from another via zone transfer, you manage both providers directly, typically through automation. A change is pushed to both providers' APIs simultaneously, keeping them in sync. Each provider operates independently as a primary, with no zone transfer dependency between them.

This model has advantages: there's no zone transfer link that can break, no dependency of one provider on another, and each provider can use its own advanced features. The challenge is that you're responsible for keeping the two in sync through your own tooling, since they don't talk to each other. Configuration management and infrastructure-as-code tools (like Terraform with DNS providers) are commonly used to push identical records to both.

A complication: provider-specific features don't always translate. If one provider offers a proprietary record type or routing feature the other doesn't, you can't keep them perfectly identical. Multi-primary works best when you stick to standard record types that both providers support.

Comparing the Models

Aspect	Primary-Secondary (AXFR)	Multi-Primary (Dual)
Sync method	Zone transfer (AXFR/IXFR)	Push to both via API/automation
Provider dependency	Secondary depends on primary	Fully independent
Where you make changes	Primary only	Both (via tooling)
Provider-specific features	Limited (standard records)	Limited (must support both)
Setup complexity	Moderate	Higher (needs automation)
Best for	Traditional redundancy	Modern IaC-driven setups

The DNSSEC Complication

DNSSEC and multi-provider DNS interact in tricky ways, and it's the most common stumbling block.

The problem: DNSSEC signing involves private keys. In a multi-provider setup, both providers need to serve validly signed records, but they each have their own signing keys. There are a few approaches:

One provider signs, transfers signed zone: In primary-secondary, the primary signs the zone and transfers the already-signed records to the secondary. The secondary serves the pre-signed data. This works but ties signing to the primary.
Both providers sign with coordinated keys: A more complex multi-signer setup (defined in RFC 8901) where both providers sign independently but their keys are cross-published so validation works regardless of which provider answers. This is powerful but operationally complex.
Disable DNSSEC: Some organizations forgo DNSSEC to simplify multi-provider setups, trading one security property for availability redundancy.

If you use both DNSSEC and multi-provider DNS, plan the signing strategy carefully. A misconfigured multi-provider DNSSEC setup can cause validation failures, the same fail-closed outage mode we've discussed. Both providers must present a coherent chain of trust.

How to Set Up Secondary DNS

Choose your providers. Select two independent DNS providers. Independence matters: two providers that share underlying infrastructure don't give you true redundancy. Pick providers with separate networks and operations.
Decide on a model. Primary-secondary (zone transfer) or multi-primary (dual push). Zone transfer is simpler if both providers support AXFR/IXFR; multi-primary suits automated, infrastructure-as-code environments.
Configure the zone on both. For primary-secondary, set up the primary with your zone and configure the secondary to transfer from it (with NOTIFY and appropriate access controls on the transfer). For multi-primary, create the identical zone on both and establish your sync tooling.
Secure zone transfers. If using AXFR/IXFR, restrict transfers to authorized secondaries (by IP and ideally TSIG authentication) so attackers can't pull your entire zone.
Update your delegation. At your registrar, list the nameservers from both providers in your NS delegation. This is what makes resolvers able to query either provider.
Verify both providers serve identical records. Query each provider's nameservers directly and confirm they return the same answers. Any discrepancy means inconsistent resolution.
Test failover. Confirm that resolution still works if one provider is unavailable. This is the whole point, so verify it actually functions.

The Synchronization Risk

Multi-provider DNS introduces its own failure mode: the two providers drifting out of sync. If a change is made at one provider but not the other (a failed zone transfer, a sync tool error, a manual change at one provider), the two start serving different records. Resolvers then get different answers depending on which provider they query, causing inconsistent and confusing behavior that can be harder to diagnose than a simple outage.

This is why monitoring is essential in a multi-provider setup. You need to verify not just that your DNS resolves, but that both providers are serving the same, correct records. Drift between providers is a silent problem that monitoring catches and manual checking usually misses.

How DNS Assistant Helps With Multi-Provider DNS

Multi-provider DNS adds resilience but also adds the complexity of keeping providers synchronized and correct. DNS Assistant supports multi-provider setups by monitoring what's actually being served:

Record monitoring verifies the records resolving for your domain are correct, catching drift or unexpected changes regardless of which provider serves them.
NS delegation monitoring confirms your delegation correctly lists both providers' nameservers and alerts if it changes.
DNSSEC validation checks that your chain of trust validates, which is especially important in multi-provider DNSSEC setups where signing coordination is complex and failure-prone.
Change detection alerts you to any modification, helping you confirm that changes propagated correctly to your DNS and catching the case where one provider updated but another didn't.
Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Multi-provider DNS is a powerful resilience measure, and pairing it with continuous monitoring ensures the redundancy actually delivers, both providers serving correct, consistent records, with any drift caught immediately. This complements the broader resilience strategy we outlined in our DNS disaster recovery guide.

Get Started

Check your current DNS setup with the DNS lookup tool at dnsassistant.com/tools to see your nameservers and records. Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring across all your DNS providers with real-time alerting, sign up at dnsassistant.com.

Anycast vs Unicast DNS: Why It Matters for Performance

Kishore Bhavnanie — Tue, 16 Jun 2026 12:48:05 +0000

When a user in Tokyo and a user in London both query the same domain, where does their request actually go? With unicast DNS, both queries travel to the same physical server, wherever it happens to be, even if that means crossing an ocean. With anycast DNS, each query is automatically routed to the nearest server out of many that share the same address. That difference shapes how fast your domain resolves, how well it survives traffic spikes, and how resilient it is against attacks.

Anycast is one of the main reasons major DNS providers can offer low latency worldwide and absorb massive denial-of-service attacks. Understanding how it differs from unicast explains a lot about why managed DNS performs the way it does, and why it matters for your domain.

This guide explains both routing methods, how anycast works, the advantages it provides, and where each fits.

Unicast: One Address, One Destination

Unicast is the standard, traditional model of network addressing. Each IP address corresponds to exactly one network interface on one server in one location. When traffic is sent to a unicast address, it travels to that specific server, wherever in the world it physically sits.

For DNS, this means a unicast nameserver has an IP address that maps to a single machine. A query from anywhere in the world is routed across the internet to that one machine. If your nameserver is in a data center in Virginia, a user in Australia querying it sends their request all the way to Virginia and waits for the response to travel all the way back.

Unicast is simple and predictable. You know exactly which server handles a request. But it has inherent limitations for global services: latency depends on distance, capacity depends on that single server (or a manually load-balanced set), and resilience depends on that one location staying online.

Anycast: One Address, Many Destinations

Anycast breaks the one-address-one-server assumption. With anycast, the same IP address is announced from multiple locations simultaneously. Many physically separate servers, potentially hundreds, all share the identical IP address.

When a user sends a query to that anycast address, the internet's routing system (BGP, the Border Gateway Protocol) directs the query to the topologically nearest instance, meaning the one with the shortest network path. A user in Tokyo reaches the Tokyo instance. A user in London reaches the London instance. Both used the exact same IP address, but the network delivered each to a different physical server based on proximity.

This is the key insight: with anycast, the network itself handles the routing to the closest server, transparently, without the user or the DNS query doing anything special. The same destination address yields different physical destinations depending on where the request originates.

How Anycast Actually Works

Anycast relies on BGP, the protocol that routers use to exchange information about how to reach different parts of the internet. Here's the mechanism:

Multiple servers announce the same IP prefix. An operator places servers in many locations (points of presence, or PoPs) around the world. Each location announces, via BGP, that it can reach the anycast IP address.
Routers learn multiple paths to the same address. Internet routers receive these announcements and see that the anycast address is reachable through several different paths.
Each router picks the best (shortest) path. Using BGP's path-selection logic, each router forwards traffic for the anycast address along the shortest path it knows, which leads to the nearest announcing server.
Queries naturally distribute to the closest PoP. The result is that queries from any given region are delivered to the nearest server, with no central coordination required. The routing fabric of the internet does the work.

If one PoP goes offline, it stops announcing the route, and routers automatically redirect traffic to the next-nearest PoP. This failover is automatic and fast, which is a major resilience benefit.

Why Anycast Matters for DNS

Lower Latency Worldwide

DNS resolution is latency-sensitive. Every web page load involves multiple DNS lookups, and each one adds to the time before content appears. With unicast, users far from your nameserver experience high DNS latency. With anycast, queries reach a nearby PoP, dramatically reducing resolution time for a global audience. A query that might take 200ms round-trip to a distant unicast server could take 10-20ms to a nearby anycast PoP.

DDoS Resilience

This is one of anycast's most important benefits. In a DNS-based DDoS attack, attack traffic floods your nameservers. With unicast, all that traffic converges on a single server, which is quickly overwhelmed. With anycast, attack traffic is distributed across all the PoPs based on where it originates. A botnet in Asia hits the Asian PoPs; a botnet in Europe hits the European PoPs. The attack is naturally spread across the entire anycast network rather than concentrated on one target, dramatically increasing the capacity available to absorb it.

Automatic Failover

If a PoP fails or is taken offline for maintenance, BGP automatically reroutes queries to the next-nearest PoP. There's no manual intervention, no DNS change, no waiting for TTLs to expire. The failover happens at the routing layer in seconds. This provides a level of resilience that's difficult to achieve with unicast.

Load Distribution

Query load is naturally spread across all PoPs by geography. No single server handles the entire world's queries. This distribution means each individual server handles a manageable portion of traffic, improving performance and reducing the risk of any one server being overwhelmed by legitimate load.

Anycast and the DNS Root Servers

The clearest real-world demonstration of anycast is the DNS root server system. There are 13 root server identities (named A through M), but there aren't just 13 physical machines. Through anycast, those 13 addresses are served by over 1,000 physical server instances distributed around the globe.

This is how the root of the entire DNS hierarchy stays fast and resilient despite handling enormous query volumes and being a constant target for attacks. When you query a root server, you reach the nearest instance via anycast, which is why root server queries are fast no matter where you are. The root system's use of anycast is a big part of why DNS as a whole is so robust.

Comparing the Two

Property	Unicast	Anycast
IP-to-server mapping	One address, one server	One address, many servers
Latency for global users	Depends on distance	Low (nearest PoP)
DDoS resilience	Traffic concentrates	Traffic distributes
Failover	Manual / DNS-based	Automatic (BGP)
Complexity to operate	Lower	Higher (BGP, multiple PoPs)
Typical use	Small / regional setups	Global DNS, CDNs, root servers

When Each Makes Sense

Anycast Is the Right Choice When

You serve a global audience and want low DNS latency everywhere
DDoS resilience matters (and for most public-facing domains, it does)
You want automatic failover without manual intervention
You're using a managed DNS provider (most major ones use anycast by default)

Unicast Can Be Sufficient When

Your audience is concentrated in one region near your server
You're running a small or internal DNS setup where global performance isn't a concern
You don't have the infrastructure or expertise to operate an anycast network (which requires multiple PoPs, BGP, and the ability to announce IP prefixes)

For most organizations, the practical path to anycast is simply using a managed DNS provider. Operating your own anycast network requires significant infrastructure: multiple points of presence, BGP peering arrangements, and provider-independent IP space. This is why anycast is a major advantage of managed DNS, as we discussed in our self-hosted vs managed DNS guide. Managed providers have already built global anycast networks, and you benefit from them automatically just by using the service.

Anycast Doesn't Replace Monitoring

Anycast improves performance and resilience, but it doesn't guarantee your DNS is correct or secure. An anycast network will faithfully serve whatever records it's configured with, including misconfigured or maliciously altered ones, to users worldwide, quickly. The speed and reach of anycast mean that a bad record propagates to your entire global audience just as efficiently as a good one.

This is where monitoring remains essential regardless of your routing model. DNS Assistant monitors what your nameservers actually return to queries, catching:

Unauthorized record changes that anycast would otherwise serve globally without question
DNSSEC validation issues across your domains
NS delegation problems including lame delegation
Resolution failures or unexpected answers, with real-time alerting via email, Slack, Microsoft Teams, webhooks, and SMS

Whether your DNS is served via unicast or a global anycast network, what matters for security is whether the right records are being served, and that requires continuous monitoring.

Check Your DNS

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and nameservers. Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring of your DNS regardless of how it's routed, with real-time alerting, sign up at dnsassistant.com.

DNS Disaster Recovery: Building a Resilient DNS Strategy

Kishore Bhavnanie — Tue, 16 Jun 2026 12:44:12 +0000

When DNS fails, everything fails. Your website becomes unreachable, email stops flowing, APIs go dark, and every service that depends on name resolution breaks at once. DNS is the single most critical dependency in your infrastructure, and yet it's often the least planned-for in disaster recovery strategies. Teams build elaborate failover for applications and databases while leaving the DNS that points to all of it as a single point of failure.

DNS disaster recovery is about ensuring that name resolution survives the failures that will eventually happen: a provider outage, a DDoS attack, an expired domain, a botched configuration change, or a registrar problem. A resilient DNS strategy anticipates these and builds in redundancy, monitoring, and recovery procedures before disaster strikes.

This guide covers the failure modes that take DNS down, the architectural patterns that make it resilient, and the operational practices that let you recover quickly when something goes wrong.

Why DNS Is the Ultimate Single Point of Failure

Most infrastructure components, if they fail, cause partial or degraded service. A failed application server might be one of many behind a load balancer. A database failure might trigger failover to a replica. But DNS sits above all of it. If users can't resolve your domain name, none of your redundant, highly available backend infrastructure matters, because nothing can reach it.

This makes DNS resilience disproportionately important. The blast radius of a DNS failure is total: it doesn't degrade service, it eliminates it. And because DNS failures often stem from configuration or provider issues rather than your own servers, they can happen even when all your infrastructure is perfectly healthy.

The Failure Modes

Effective DNS disaster recovery starts with understanding what actually goes wrong.

DNS Provider Outage

Your managed DNS provider experiences an outage, and your domain stops resolving. This has happened to every major provider at some point. If all your DNS is hosted with a single provider, their outage is your outage, with no way to fix it on your end except to wait.

DDoS Attack

Your nameservers are flooded with attack traffic and can't respond to legitimate queries. Without sufficient capacity or DDoS protection, your domain becomes unreachable for the duration of the attack.

Domain Expiration

The domain registration lapses, often due to an expired payment method or a missed renewal notice, and the domain stops resolving entirely. We covered this preventable disaster in depth in our domain expiration guide.

Misconfiguration

A well-intentioned change introduces an error: a typo in a record, a deleted entry, a broken DNSSEC configuration, or an incorrect nameserver delegation. Configuration mistakes are one of the most common causes of DNS outages, and they're entirely self-inflicted.

DNSSEC Failures

An expired DNSSEC signature or a botched key rollover causes validating resolvers to reject your domain entirely. This is a particularly nasty failure mode because the domain works for non-validating resolvers but fails for validating ones, making it hard to diagnose. The .de TLD DNSSEC outage showed how this can take down DNS at national scale.

Registrar or Account Compromise

An attacker gains access to your DNS provider account or registrar and alters your records or nameserver delegation, redirecting traffic. This is both a security incident and a disaster recovery scenario.

Building a Resilient DNS Architecture

1. Use Multiple DNS Providers (Secondary DNS)

The single most effective DNS resilience measure is using more than one DNS provider. With secondary DNS, your zone is served by nameservers from two independent providers. If one provider has an outage, the other continues answering queries, and your domain stays up.

This works because you can list nameservers from both providers in your delegation. Resolvers will try them, and as long as one set responds correctly, resolution succeeds. The providers stay synchronized either through zone transfers (AXFR/IXFR) or through both being fed from a common source.

Multi-provider DNS protects against the failure mode you can't otherwise control: your provider's infrastructure failing. It's the DNS equivalent of multi-region redundancy, and for critical domains, it's worth the added complexity.

2. Ensure Geographic and Network Diversity

Your nameservers should be distributed across multiple locations and network paths. Anycast (which we cover in our anycast vs unicast guide) provides this within a single provider, but combining anycast with multiple providers gives you both intra-provider and inter-provider diversity.

3. Use Appropriate TTLs

TTL strategy is a disaster recovery tool. Lower TTLs let you reroute traffic faster during an incident by reducing how long resolvers cache records. Higher TTLs provide a buffer during nameserver outages because resolvers keep serving cached records even if your nameservers are temporarily unreachable. Balancing these is a deliberate decision, covered in our TTL best practices guide. For disaster recovery, knowing your TTLs in advance tells you how quickly you can react and how much cache buffer you have.

4. Protect the Registrar Layer

Your domain registration and nameserver delegation live at the registrar, above your DNS provider. Protect this layer: enable registrar lock (client transfer prohibited), use strong authentication with MFA on the registrar account, register domains for multi-year terms to reduce expiration risk, and ensure renewal contact information is monitored. A registrar-level problem (expiration, unauthorized transfer, account compromise) bypasses all your DNS provider redundancy.

5. Maintain DNSSEC Carefully

If you use DNSSEC, treat key rollovers and signature refreshes as high-risk operations. Automate signature refresh so signatures never expire. Test key rollovers carefully. Monitor the chain of trust continuously. DNSSEC adds security but introduces a failure mode that can take your domain completely offline, so it requires disciplined operational practices.

Operational Practices for Recovery

Architecture reduces the chance of failure. Operational practices determine how fast you recover when failure happens anyway.

Maintain a Complete DNS Inventory

You can't recover what you haven't documented. Maintain a current record of every domain, every DNS record, every provider, and every registrar account. When disaster strikes, you need to know exactly what your DNS should look like to restore it. This inventory is also your reference for detecting unauthorized changes.

Keep Backups of Your Zone Data

Export and back up your zone files regularly. If a provider loses your configuration, an account is compromised and records are deleted, or a migration goes wrong, a recent zone backup lets you restore quickly rather than reconstructing records from memory. Store backups independently of the provider.

Document Recovery Procedures

Write down the steps to recover from each failure mode before you need them. Who has access to the registrar account? How do you fail over to the secondary provider? How do you roll back a bad change? How do you respond to a suspected compromise? Having these documented turns a panicked scramble into a calm procedure.

Monitor Continuously

The faster you detect a DNS problem, the faster you can respond, and with DNS, detection speed directly determines impact. A misconfiguration caught in seconds is a non-event; the same misconfiguration discovered an hour later when customers complain is an outage. Continuous monitoring is the foundation of fast recovery.

Test Your Recovery Plan

A recovery plan you've never tested is a hypothesis, not a plan. Periodically verify that your secondary DNS actually works, that your backups can be restored, that your team knows the procedures, and that your registrar access is current. Discover the gaps during a test, not during a real incident.

The Detection Gap

Most DNS disasters share a common characteristic: they're invisible until someone notices the symptoms. A DNSSEC signature expires, but nothing alerts you until validating resolvers start failing. A record is changed, but you don't know until traffic goes to the wrong place. A domain approaches expiration, but the only warning is a renewal email that went to an unmonitored inbox.

This detection gap is where most of the damage happens. The technical failure might last seconds, but the time to notice it can stretch to hours, and that's the duration your users actually experience as an outage. Closing the detection gap is the highest-leverage improvement most organizations can make to their DNS resilience.

How DNS Assistant Supports DNS Disaster Recovery

DNS Assistant is built to close the detection gap and provide the visibility that fast recovery depends on:

Continuous record monitoring: Every DNS record is checked continuously, and any change triggers an immediate alert. Unauthorized modifications, accidental deletions, and misconfigurations are caught in real time rather than discovered through user complaints.
DNSSEC validation: The chain of trust is validated continuously, catching expiring signatures and broken key rollovers before they take your domain offline for validating resolvers.
WHOIS and expiration monitoring: Domain expiration dates are tracked independently of registrar emails, providing a safety net against the preventable disaster of an expired domain.
NS delegation monitoring: Nameserver changes and delegation problems are detected, catching both unauthorized changes and lame delegation.
Multi-channel alerting with escalation: Alerts reach your team via email, Slack, Microsoft Teams, webhooks, and SMS, with escalation so critical issues don't get missed.
A baseline for recovery: Continuous monitoring maintains an accurate picture of your DNS, giving you the reference you need to detect deviations and restore correct configuration.

Monitoring doesn't replace architectural resilience like multi-provider DNS, but it's the layer that turns a potential disaster into a quickly-resolved incident. The combination of resilient architecture and continuous detection is what keeps DNS available through the failures that will inevitably come.

Get Started

Begin by understanding your current DNS posture. Run a Free Domain Risk Report to review your configuration, DNSSEC status, and email authentication, or use the DNS lookup tool to inspect specific records and nameservers.

For continuous monitoring that closes the detection gap and supports fast recovery, sign up at dnsassistant.com.

Wildcard DNS Records: Uses, Risks, and Best Practices

Kishore Bhavnanie — Mon, 15 Jun 2026 12:23:48 +0000

A single DNS record can answer for an unlimited number of subdomains. Add one wildcard entry, and suddenly anything.yourcompany.com, literally-anything.yourcompany.com, and every other name you never explicitly created all resolve to the same place. Wildcard DNS records are powerful, convenient, and genuinely necessary for certain architectures. They're also a frequent source of security problems and confusing misconfigurations.

Understanding when wildcards help, when they hurt, and how they interact with the rest of your DNS is essential for using them safely. This guide covers what wildcard records are, their legitimate uses, the real risks they introduce, and best practices for managing them.

What Is a Wildcard DNS Record?

A wildcard DNS record uses an asterisk (*) as the leftmost label to match any subdomain that doesn't have its own explicit record. It looks like this:

*.yourcompany.com.    3600    IN    A    203.0.113.50

With this record in place, any query for a subdomain of yourcompany.com that doesn't have a specific record returns 203.0.113.50. So foo.yourcompany.com, bar.yourcompany.com, and anything-at-all.yourcompany.com all resolve to that IP, even though you never created records for any of them.

Wildcards work with various record types, not just A records. You can have wildcard CNAME, MX, TXT, and other record types, though A and CNAME are the most common.

How Wildcards Actually Match (The Rules)

Wildcard matching is more nuanced than it first appears, and misunderstanding the rules leads to surprises.

Explicit Records Always Win

A wildcard only answers for names that don't have their own record. If you have both:

*.yourcompany.com.      IN  A  203.0.113.50
api.yourcompany.com.    IN  A  203.0.113.99

Then api.yourcompany.com resolves to 203.0.113.99 (the explicit record), while anything-else.yourcompany.com resolves to 203.0.113.50 (the wildcard). The explicit record takes precedence.

Wildcards Only Match One Level

A wildcard like *.yourcompany.com matches foo.yourcompany.com but does NOT match foo.bar.yourcompany.com (two levels deep). The asterisk represents exactly one label, not multiple. To match deeper levels, you'd need additional wildcards like *.bar.yourcompany.com.

The Subtle Trap: Wildcards and Existing Names

Here's a rule that catches people: a wildcard does not match a name if that name (or something below it) exists in the zone for any record type. If blog.yourcompany.com has an MX record but no A record, a query for the A record of blog.yourcompany.com will NOT fall through to the wildcard, because the name blog.yourcompany.com exists in the zone. This behavior, defined in the DNS specifications, surprises administrators who expect the wildcard to fill in any missing record type.

Legitimate Uses of Wildcard Records

Wildcards exist for good reasons. Here are the scenarios where they're the right tool.

Multi-Tenant SaaS Applications

The classic use case. A SaaS platform gives each customer their own subdomain: customer1.app.com, customer2.app.com, and so on. Creating an explicit DNS record for every customer would be impractical, especially with thousands of customers signing up dynamically. A wildcard (*.app.com) points all of them to the application, which then routes based on the hostname. This is the standard pattern for multi-tenant architectures.

Dynamic or Ephemeral Subdomains

Applications that generate subdomains on the fly, preview environments for pull requests, per-user spaces, dynamically provisioned services, benefit from wildcards so the DNS doesn't need updating every time a new subdomain is created.

Catch-All Behavior

Sometimes you want any subdomain to resolve somewhere sensible rather than returning an error, perhaps to a landing page or a catch-all handler. A wildcard provides this.

Wildcard TLS Certificate Pairing

Wildcard DNS often pairs with wildcard TLS certificates (*.yourcompany.com), allowing any subdomain to serve HTTPS without provisioning individual certificates. The DNS wildcard and certificate wildcard work together to support a flexible subdomain architecture.

The Risks of Wildcard Records

The same flexibility that makes wildcards useful also makes them risky. Here's what to watch for.

They Mask Missing Records and Errors

With a wildcard in place, every subdomain resolves to something, even typos and mistakes. If someone mistypes a subdomain in a configuration, instead of getting a clear "this doesn't exist" error, they get the wildcard's answer, which may route them somewhere unexpected. This masking makes troubleshooting harder because nothing ever appears to be "missing."

They Expand the Attack Surface

A wildcard means every possible subdomain resolves to your infrastructure. If that infrastructure has a vulnerability, or if the wildcard points to a service that can be manipulated, the entire infinite namespace of subdomains becomes a potential vector. This is exactly the dynamic that made the Borrowed Trust campaign so damaging: attackers who took over abandoned cloud DNS zones added a single wildcard record that exposed an unlimited subdomain namespace, each entry inheriting the victim's trusted domain authority.

They Complicate Dangling DNS Detection

Wildcards make it harder to detect dangling DNS and subdomain takeover risks. Normally, you can audit your explicit subdomain records and check each target. But a wildcard resolves everything, so a randomized nonsense hostname will return a result whether or not it's legitimately configured. As we noted in the Borrowed Trust analysis, security researchers specifically test wildcard resolution with random hostnames precisely because an unexpected resolution is a strong signal of a compromised or misconfigured zone.

They Can Enable Email and Phishing Abuse

If a wildcard covers MX or interacts with email authentication, it can create openings for abuse. More commonly, a wildcard A record combined with a permissive application can let attackers serve content under arbitrary subdomains of your trusted domain, useful for phishing that leverages your brand's reputation.

They Interact Unexpectedly with SPF and Subdomains

Wildcards and email authentication don't always combine cleanly. A wildcard doesn't automatically extend your SPF, DKIM, and DMARC protection to every subdomain, which can leave generated subdomains spoofable even though they resolve. Subdomain email security requires explicit DMARC subdomain policies (sp=), not wildcard coverage.

Best Practices for Wildcard Records

Use Explicit Records When You Can

If you know the specific subdomains you need, create explicit records for them rather than relying on a wildcard. Explicit records are auditable, each one represents a deliberate decision, and they don't mask errors. Reserve wildcards for cases where the set of subdomains is genuinely dynamic or unbounded.

Scope Wildcards as Narrowly as Possible

Instead of a broad wildcard at your apex (*.yourcompany.com), scope it to a specific subdomain branch where dynamic naming actually happens (*.apps.yourcompany.com or *.tenants.yourcompany.com). This limits the wildcard's reach to where it's needed and keeps the rest of your namespace explicit and auditable.

Pair Wildcards With Application-Level Validation

If a wildcard routes all subdomains to an application, that application should validate the hostname and reject ones it doesn't recognize, rather than serving content for any arbitrary name. The DNS wildcard resolves the name; the application decides whether to actually honor it. This prevents the wildcard from being abused to serve content under unrecognized subdomains.

Monitor for Unexpected Wildcard Behavior

Because wildcards resolve everything, you need monitoring that can detect when a wildcard appears that shouldn't exist, or when wildcard behavior changes. An unexpected wildcard is a strong indicator of compromise, as the Borrowed Trust campaign demonstrated at scale.

Audit Wildcards During Decommissioning

When you tear down a project or environment that used a wildcard, removing the wildcard record is critical. An orphaned wildcard pointing at decommissioned infrastructure is exactly the kind of dangling configuration attackers look for. Make wildcard cleanup an explicit step in your decommissioning checklist.

Don't Use Wildcards to Avoid DNS Management

Sometimes wildcards are used as a shortcut to avoid the work of managing individual records. That convenience comes at the cost of visibility and security. If you're using a wildcard purely to avoid creating records, reconsider, the explicit records are usually worth the small effort.

How to Check for Wildcards

Testing for a wildcard is simple: query a randomized, nonsense hostname that you've definitely never created. If it resolves, you have a wildcard (or, more concerningly, a compromised zone).

Use the DNS lookup tool at dnsassistant.com/tools to query a random subdomain like random-test-12345.yourcompany.com. If it returns an answer, a wildcard is in play. If you didn't intentionally configure one, that's a red flag worth investigating immediately.

How DNS Assistant Helps

Wildcards require careful monitoring precisely because they resolve everything and can mask both errors and compromise. DNS Assistant supports safe wildcard management:

Record change detection alerts you when a wildcard record is added, modified, or removed, so an unexpected wildcard (a strong compromise signal) doesn't go unnoticed.
Dangling DNS detection across 22+ cloud providers helps identify when records, including wildcards, point to decommissioned infrastructure vulnerable to takeover.
Continuous monitoring catches the moment a wildcard's behavior changes, which is exactly when problems and compromises surface.
Full record visibility across all your domains helps you maintain an accurate picture of where wildcards exist and what they point to.
Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

Given how central wildcard records were to the Borrowed Trust campaign and other subdomain takeover attacks, monitoring wildcard behavior is an important part of DNS security hygiene.

Get Started

Test whether your domains have unexpected wildcards using the DNS lookup tool, or run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring of wildcard records and all your DNS configuration with real-time alerting, sign up at dnsassistant.com.

What Is a Zone File? Understanding DNS Zone Structure

Kishore Bhavnanie — Mon, 15 Jun 2026 12:12:35 +0000

Every domain's DNS records have to live somewhere. That somewhere is a zone file: a text-based blueprint that defines how a domain resolves, where its email goes, which servers are authoritative, and dozens of other instructions that make the domain work. If you've ever managed DNS through a provider's dashboard, you've been editing a zone file without seeing it. The dashboard is just a friendly interface over the underlying structure.

Understanding the zone file demystifies a lot of DNS. It shows you how records relate to each other, why certain rules exist (like the constraints on CNAMEs), and what's actually happening when you add an A record or change a nameserver. For anyone running self-hosted DNS, the zone file is the thing you edit directly.

This guide explains what a zone file is, walks through its structure line by line, and covers the records and directives you'll find inside one.

What Is a Zone File?

A zone file is a plain-text file that contains all the DNS records for a particular zone, which is usually a domain and its subdomains. It lives on the authoritative nameserver for that domain and is the definitive source of truth for how the domain resolves.

The format is standardized (originally defined in RFC 1035) so that any DNS server software can read it. Whether you use BIND, PowerDNS, Knot, or NSD, the zone file format is broadly the same, which is part of why DNS is so interoperable.

A "zone" and a "domain" are closely related but not identical. A domain is the name (yourcompany.com). A zone is the administrative boundary that the nameserver is authoritative for. Usually they line up, but a zone can be split: you might delegate sub.yourcompany.com to a different nameserver, creating a separate child zone. The parent zone file then contains a delegation pointing to the child's nameservers rather than the child's records directly.

The Anatomy of a Zone File

Here's a representative zone file for example.com. We'll break down each part.

$TTL 3600
$ORIGIN example.com.

@   IN  SOA  ns1.example.com. admin.example.com. (
            2026061501  ; Serial
            7200        ; Refresh
            3600        ; Retry
            1209600     ; Expire
            3600 )      ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.

@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
@       IN  AAAA    2001:db8::10

@       IN  MX  10  mail.example.com.
mail    IN  A       203.0.113.20

@       IN  TXT     "v=spf1 include:_spf.example.com -all"

ftp     IN  CNAME   www.example.com.
ns1     IN  A       203.0.113.2
ns2     IN  A       203.0.113.3

Directives: $TTL and $ORIGIN

Lines starting with $ are directives that control how the rest of the file is interpreted.

$TTL 3600 sets the default Time to Live for records that don't specify their own. This is how long resolvers should cache the records, in seconds. Individual records can override it. We covered TTL strategy in depth in our TTL best practices guide.

$ORIGIN example.com. defines the base domain that gets appended to any name not ending in a dot. This is what makes the shorthand in zone files work. When you write www, it expands to www.example.com. because of the origin. The trailing dot matters enormously here, which we'll explain next.

The Critical Detail: Trailing Dots

This is the single most common source of zone file errors, and it trips up even experienced administrators.

In a zone file, a name that ends with a dot is fully qualified, meaning it's complete and absolute. A name that does NOT end with a dot is relative, and the $ORIGIN gets appended to it.

Consider these two lines:

www     IN  CNAME   example.com.      ← correct: points to example.com
www     IN  CNAME   example.com       ← WRONG: points to example.com.example.com

The second line is missing the trailing dot, so the origin (example.com.) gets appended, producing example.com.example.com., which is almost certainly not what you intended. This kind of mistake creates broken resolution that can be maddening to debug because the zone file "looks right" at a glance.

The rule: if you're writing a complete domain name as a record's target, end it with a dot. If you're writing a name relative to your own domain (like www or mail), leave the dot off.

The SOA Record

Every zone file begins with a Start of Authority (SOA) record. It defines the administrative parameters for the zone and is mandatory. There can be only one SOA record per zone.

@   IN  SOA  ns1.example.com. admin.example.com. (
            2026061501  ; Serial
            7200        ; Refresh
            3600        ; Retry
            1209600     ; Expire
            3600 )      ; Minimum TTL

Breaking it down:

@ is shorthand for the origin (example.com.). The @ symbol always means "the current origin."
ns1.example.com. is the primary nameserver for the zone.
admin.example.com. is the administrator's email address, with the @ replaced by a dot. So this represents admin@example.com. This substitution exists because @ already has a special meaning in zone files.
Serial (2026061501) is a version number for the zone. Every time you change the zone, you increment it. Secondary nameservers compare serials to know when to pull updates. A common convention is the date plus a counter (YYYYMMDDnn).
Refresh (7200) is how often secondary servers check the primary for changes, in seconds.
Retry (3600) is how long a secondary waits to retry if a refresh fails.
Expire (1209600) is how long a secondary keeps serving the zone if it can't reach the primary, before giving up.
Minimum TTL (3600) controls negative caching, which is how long resolvers cache "this record doesn't exist" (NXDOMAIN) responses.

The serial number is the field you'll interact with most. If you edit a zone file but forget to increment the serial, secondary nameservers won't realize there's an update and will keep serving the old records. Most managed DNS providers handle serial incrementing automatically, but in self-hosted setups it's a manual step that's easy to forget.

NS Records: Declaring the Nameservers

@   IN  NS  ns1.example.com.
@   IN  NS  ns2.example.com.

NS records declare which nameservers are authoritative for the zone. A zone should have at least two for redundancy. These records must match the nameserver delegation set at your registrar (the parent zone). A mismatch between the NS records in your zone file and the delegation at the registrar causes "lame delegation," a common DNS misconfiguration where resolvers are sent to nameservers that don't properly serve the zone.

The Resource Records

The bulk of a zone file is resource records, each defining one piece of DNS information. Every record follows the same general format:

NAME    TTL   CLASS   TYPE   DATA

In practice, TTL is often omitted (inheriting the $TTL default), and CLASS is almost always IN (Internet). So most records read as NAME IN TYPE DATA.

Common Record Types in a Zone File

A maps a name to an IPv4 address: www IN A 203.0.113.10
AAAA maps a name to an IPv6 address: www IN AAAA 2001:db8::10
CNAME creates an alias to another name: ftp IN CNAME www.example.com.
MX defines mail servers, with a priority value: @ IN MX 10 mail.example.com.
TXT holds arbitrary text, used for SPF, DKIM, DMARC, and verification: @ IN TXT "v=spf1 ..."
NS declares authoritative nameservers (covered above)
SRV defines services with port and priority information
CAA restricts which certificate authorities can issue certificates for the domain
PTR maps an IP back to a name (used in reverse DNS zones, covered in our reverse DNS guide)

The @ Symbol and Bare Records

The @ in records like @ IN A 203.0.113.10 refers to the zone apex, the bare domain itself (example.com with no subdomain). This is why the apex can have A records but, as we explained in our A record vs CNAME guide, cannot have a CNAME: the apex must hold the SOA and NS records, and a CNAME can't coexist with other records at the same name.

Reverse Zone Files

The zone file we've discussed is a forward zone, mapping names to IPs. There are also reverse zone files that map IPs back to names using PTR records. These live under the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) hierarchy and are typically managed by whoever controls the IP address block, often your hosting provider rather than you. Reverse zones are essential for email deliverability, which we cover in detail in the reverse DNS article linked above.

How Zone Files Relate to Managed DNS

If you use a managed DNS provider (Cloudflare, Route 53, Google Cloud DNS, etc.), you probably never see a raw zone file. The provider's dashboard presents records as form fields and tables. Behind the scenes, though, the provider maintains the equivalent of a zone file and serves it from their authoritative nameservers.

This abstraction is convenient, it handles serial incrementing, validates syntax, and prevents trailing-dot errors, but understanding the underlying zone file structure helps you reason about what the dashboard is actually doing. When a provider offers "zone export" or "import via zone file," they're giving you the raw text representation, which is useful for migrations and backups.

For self-hosted DNS, the zone file is the real, editable artifact. You edit it directly, increment the serial, and reload the zone. This gives maximum control but also means you're responsible for the syntax, the serial, and the correctness that managed providers handle automatically. We compare these approaches in our self-hosted vs managed DNS guide.

Common Zone File Mistakes

Forgetting the trailing dot on fully qualified names, causing the origin to be appended incorrectly. The number one zone file error.
Not incrementing the serial after changes, so secondary nameservers never pick up the update.
Multiple records that conflict, like a CNAME coexisting with other records at the same name, which violates DNS rules.
NS records not matching the registrar delegation, causing lame delegation.
Syntax errors (missing parentheses in the SOA, malformed records) that prevent the zone from loading at all.

In self-hosted environments, DNS server software usually validates the zone file when it loads and refuses to serve a zone with syntax errors, which is a useful safety net but can also cause an outage if a bad edit is deployed without testing.

How DNS Assistant Helps

Whether your records live in a hand-edited zone file or a managed provider's system, what matters is what resolvers actually receive when they query your domain. DNS Assistant monitors that, the live, authoritative answers, rather than the configuration source.

Record monitoring across all the record types found in a zone file (A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, and more), with alerts when any value changes.
SOA serial tracking so you can see when your zone has been updated, useful for confirming changes propagated or detecting unexpected modifications.
NS delegation validation to catch lame delegation where your zone's NS records don't match the registrar.
DNSSEC validation of the chain of trust that protects your zone's authenticity.
Multi-channel alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

This is especially valuable for self-hosted DNS, where a zone file edit that introduces an error, forgets a serial increment, or breaks a delegation can cause problems that are hard to spot from the configuration alone.

Check Your Zone

Use the DNS lookup tool at dnsassistant.com/tools to query your domain's records and see what your zone is actually serving, including your SOA and NS records. Run a Free Domain Risk Report for a comprehensive view of your DNS configuration.

For continuous monitoring of everything your zone serves, with real-time alerting, sign up at dnsassistant.com.

163 Brands Hijacked Through Abandoned DNS Delegations: Inside the Borrowed Trust Campaign

Kishore Bhavnanie — Fri, 12 Jun 2026 18:04:29 +0000

163 organizations across more than 30 countries had gambling content served under their own trusted domain names, with valid TLS certificates, clean browser padlocks, and no security alert firing anywhere. Federal government agencies, national healthcare systems, financial institutions, critical infrastructure operators, and major universities were all affected. Some of them had been exposed for over six years.

The attackers didn't breach a single firewall. They didn't exploit an application vulnerability. They didn't phish anyone. They simply claimed DNS infrastructure that these organizations had abandoned and forgotten to clean up.

This is the "Borrowed Trust" campaign, documented by Cyble Research and Intelligence Labs in June 2026. It's one of the clearest, largest-scale demonstrations to date of how abandoned DNS delegations turn into a systematic attack surface. And it's a textbook example of exactly the risk we've written about before: dangling DNS records, exploited at industrial scale.

What Happened

The campaign was an SEO poisoning operation. The attackers wanted to rank Thai-language online gambling sites in search results, and to do it, they needed domains with strong reputation and authority. Rather than building that reputation themselves, they borrowed it from legitimate enterprises by hijacking abandoned subdomains.

The discovery started with a single anomaly. During a vulnerability assessment, Cyble researchers noticed strange DNS resolution on a Verizon subdomain environment. What looked like one misconfigured endpoint turned out to be over 1,000 individually named subdomains, each serving Thai-language gambling content under Verizon's trusted domain authority. Following that thread exposed 162 other compromised organizations.

Each compromised subdomain served a fully rendered gambling application with a valid Let's Encrypt certificate matching the victim's domain. To a browser, a search engine, or a Thai user clicking a search result, the page looked like a legitimate property of the enterprise whose domain it ran under.

The Core Vulnerability: Abandoned DNS Delegations

The primary mechanism behind the campaign was Azure DNS zone takeover, which accounted for more than 150 of the 163 victims. Understanding it requires understanding how cloud DNS delegation works.

When an enterprise provisions cloud infrastructure for a project, a common step is to delegate a subdomain to a cloud DNS zone. For Azure, this means adding NS (nameserver) records in the parent domain's DNS that point to Microsoft's Azure nameservers for that environment. The cloud DNS zone then handles all records for that subdomain. The project runs normally.

The problem is what happens at decommissioning. According to Cyble's analysis, when the project ends and the cloud resources are deleted, the NS delegation in the parent DNS zone is routinely left in place. It keeps pointing to cloud nameservers that no longer hold authoritative records for the subdomain.

This dangling delegation becomes exploitable because of how cloud DNS zone creation works. Cloud providers have historically allowed any subscriber to claim a DNS zone by name. An attacker who finds an abandoned delegation can create a new subscription, claim the orphaned zone under that subscription, and instantly inherit the DNS authority that the enterprise's parent zone never revoked.

Once the attacker controls the zone, they add a single wildcard A record pointing every possible subdomain to their server, then use the now-controlled DNS to pass ACME validation and obtain a wildcard TLS certificate. One wildcard record exposes the entire subdomain namespace of the environment, every entry carrying the victim's TLS-verified brand authority.

Four Mechanisms, One Root Cause

Cyble identified four distinct compromise mechanisms, but they all stem from the same root cause: a DNS configuration that outlived the infrastructure it was created to serve.

Azure DNS zone takeover (150+ organizations). Abandoned NS delegations to Azure nameservers, with the underlying subscription canceled. The attacker claimed the orphaned zones and added wildcard records. Cyble confirmed this with direct evidence: querying Microsoft's own nameservers returned the attacker's wildcard record, and zone SOA serials of 1 proved the zones had been created fresh by the attacker rather than modified from an existing state.

DigitalOcean DNS zone takeover (2 organizations). The same structural weakness on a different cloud provider. Abandoned DNS zones in canceled accounts became available for re-registration. The attacker's tooling targeted multiple cloud DNS providers, not just Azure.

Direct wildcard misconfiguration (2 organizations). An orphaned wildcard A record left directly in the organization's own DNS console when a project was decommissioned, or a compromised DNS management credential.

Per-subdomain A records (1 organization). The Verizon case, where over 1,000 individually named A records were created rather than a single wildcard, implying automated DNS API access or a compromised DNS management credential.

Why Nothing Detected It

The most unsettling part of this campaign is how completely invisible it was to conventional security tooling. As Cyble notes, the campaign produces no signal in standard security controls. Here's why:

Valid TLS certificates. The attacker obtained legitimate Let's Encrypt certificates for the victim subdomains. Browsers showed a clean padlock with no warnings.
Clean IP reputation. The delivery nodes were standard hosting with no prior threat association. Threat intelligence feeds returned nothing.
Trusted domain names. The content was served under the victims' own legitimate domains, which carry years of accumulated reputation and trust.
No exploit delivery. Nothing was hacked in the traditional sense. There was no malware, no exploit payload, no perimeter breach to detect.
Geographic filtering. The backend validated request origin server-side and only served gambling content to traffic from Thailand, keeping the operation focused and limiting scanner exposure.

Every layer of the operation lived inside legitimate infrastructure: real cloud DNS, real TLS certificates, victim-owned domains, and organic search rankings. That's precisely why traditional controls produced no signal. The only place the attack was visible was at the DNS layer.

The Detection That Would Have Worked

Cyble's analysis is clear that detection required operating at the DNS layer, and identifies the controls that would have caught this campaign. Every one of them is about DNS visibility.

DNS Delegation Auditing

The structural prevention control is auditing your NS delegation records. Organizations should enumerate every NS delegation in their parent DNS zones and verify that each corresponding cloud DNS zone actually exists in a subscription they own and actively manage. An NS delegation pointing to a cloud provider where you no longer have a matching, managed zone is a dangling delegation waiting to be claimed.

Wildcard DNS Testing

A randomized, nonsense hostname query against a delegated subdomain that returns a resolution is a strong signal of compromise. If random-nonsense-12345.dev.yourcompany.com resolves to an IP, but you never created a wildcard record, someone else did. Cyble recommends treating any such resolution as a compromised zone until proven otherwise.

Certificate Transparency Monitoring

Every TLS certificate issued by a public CA is logged in public Certificate Transparency logs. An unexpected Let's Encrypt wildcard certificate appearing on a corporate subdomain, especially one that historically used a corporate or premium CA, or had no recent certificate activity, is an anomaly no legitimate provisioning produces. Cyble notes that CT log monitoring would have detected every Azure takeover victim at the moment the attacker's certificate was issued.

How DNS Assistant Addresses This

This campaign is a direct, large-scale validation of why continuous DNS monitoring matters. DNS Assistant is built around exactly the kind of visibility that would have surfaced these compromises.

Dangling DNS Detection

DNS Assistant checks for dangling DNS records, the exact vulnerability class this campaign exploited, across 22+ cloud provider fingerprints. Records and delegations pointing to decommissioned cloud infrastructure are flagged before an attacker can claim them. This is the core defensive control against the abandoned-delegation problem at the heart of Borrowed Trust.

Record and Delegation Change Detection

DNS Assistant continuously monitors your DNS records, including NS records, and alerts when they change or when resolution behavior shifts. A subdomain that suddenly begins resolving to an unfamiliar IP, or a wildcard that starts answering queries it never did before, is exactly the kind of change DNS Assistant is designed to surface.

Continuous Monitoring, Not Point-in-Time

Several victims in this campaign had abandoned delegations sitting exploitable for over six years. A one-time audit conducted before the delegation was abandoned would have shown nothing wrong. The exposure appeared later, when the cloud subscription was canceled but the delegation remained. Only continuous monitoring catches the moment a record becomes dangerous, which can be long after it was created.

Full Subdomain and Record Visibility

You cannot protect infrastructure you've forgotten you have. DNS Assistant helps you maintain visibility into your DNS records and subdomains, including the forgotten dev, staging, uat, pilot, and lab environments that are the most common source of abandoned delegations.

What Organizations Should Do Now

Drawing on Cyble's remediation guidance, here are the steps every organization should take:

Enumerate your NS delegations. List every NS delegation record in your parent DNS zones. For each one pointing to a cloud provider, verify that a corresponding zone exists in an account or subscription you own and actively manage. Remove any delegation that no longer has a matching, managed zone.
Audit environment-style subdomains. Pay special attention to subdomains with names like dev, uat, staging, preprod, pilot, lab, test, and sandbox. These project environments are the most likely to have been decommissioned while leaving delegations behind.
Test for unexpected wildcard resolution. Query randomized nonsense hostnames against your delegated subdomains. Any resolution you didn't configure is a red flag.
Monitor Certificate Transparency logs. Watch for unexpected certificates issued against your subdomains, especially wildcard certificates from a CA you don't normally use.
Build DNS cleanup into decommissioning. The root cause is that DNS delegations outlive the infrastructure they serve. Make removing DNS records and delegations a mandatory, verified step whenever a project or cloud resource is retired.
Monitor continuously. Abandoned delegations can become exploitable years after they're created. Continuous DNS monitoring is the only way to catch the transition from dormant to dangerous.

The Takeaway

The Borrowed Trust campaign is a reminder that DNS is not static infrastructure you configure once and forget. It's a living attack surface, and the most dangerous parts of it are often the parts you've stopped thinking about: the project that ended, the environment that was torn down, the delegation that was never cleaned up.

The attackers in this campaign didn't need sophistication. They needed an automated scanner and a list of organizations that had left DNS delegations pointing at cloud zones they no longer owned. One abandoned delegation, beneath one wildcard record, exposed an unlimited subdomain namespace carrying the full authority of a trusted brand. Multiply that by 163 organizations, and you have one of the largest DNS-based reputation-hijacking campaigns documented to date.

The remediation is simple. The detection is well understood. The gap is visibility, and that gap is exactly what continuous DNS monitoring closes.

Check your DNS estate now. Run a Free Domain Risk Report to review your DNS configuration, or use the DNS lookup tool to inspect specific records and delegations.

For continuous dangling DNS detection and delegation monitoring across your entire domain portfolio, sign up at dnsassistant.com.

How to Migrate DNS to a New Provider Without Downtime

Kishore Bhavnanie — Fri, 12 Jun 2026 16:44:52 +0000

Migrating your DNS from one provider to another sounds risky. Your entire online presence, your website, your email, your APIs, depends on DNS resolving correctly. A mistake during migration can take everything offline. But with the right process, DNS migration can be done with zero downtime, and it's far less dangerous than it seems.

The key is understanding that DNS migration isn't a single switch you flip. It's a careful sequence where you prepare the new provider completely, verify it works, and only then redirect traffic, with the old provider standing by as a fallback throughout. Done correctly, users never notice anything changed.

This guide walks through the complete process: preparation, the actual migration, verification, and the common mistakes that cause the downtime you're trying to avoid.

Why Migrate DNS Providers?

Organizations move DNS providers for many reasons: better performance through a larger anycast network, lower costs, advanced features (traffic management, better APIs, DNSSEC support), consolidation of services, improved security and DDoS protection, or moving away from a provider that's being deprecated. Whatever the reason, the migration process is the same.

Understanding What Actually Changes

Before migrating, it's important to understand the two distinct things that can change:

1. The Authoritative DNS Provider (Your Records' Host)

This is where your DNS records (A, MX, TXT, etc.) are hosted and served. Moving this means recreating your records at the new provider and updating your domain's nameserver delegation to point to them.

2. The Nameserver Delegation (at the Registrar)

Your domain registrar holds the NS records that tell the world which nameservers are authoritative for your domain. Changing DNS providers means updating this delegation at the registrar to point to the new provider's nameservers.

The migration is essentially: replicate everything at the new provider, then change the delegation to point to it. The delegation change is the moment of cutover, and it's where careful timing matters.

Phase 1: Preparation (Before Touching Anything)

Step 1: Inventory Your Current DNS Records

You cannot migrate what you don't know about. Export or document every single DNS record at your current provider. This includes obvious records (A, AAAA, CNAME, MX) and easily forgotten ones (TXT records for SPF, DKIM, DMARC, domain verification; SRV records; CAA records; any subdomains).

Use the DNS lookup tool at dnsassistant.com/tools to query each record type and confirm your inventory is complete. Many providers also offer a zone file export that captures everything at once. Missing a record during migration is the most common cause of post-migration problems.

Step 2: Note Your Current TTL Values

Record the TTL for each record. You'll need these to plan timing, and you'll restore them after migration. Pay special attention to your NS record TTLs and your SOA settings.

Step 3: Lower TTLs in Advance

This is the single most important step for a zero-downtime migration. Several days before the migration, lower the TTLs on your records at the current provider to a short value (300 seconds or lower).

Why: when you make the cutover, resolvers that have cached your old records will keep serving them until the TTL expires. If your TTL is 86400 seconds (24 hours), some users could be pointed at the old provider for a full day after you switch. By lowering the TTL in advance, you ensure that when you cut over, the old cached entries expire within minutes.

Lower the TTL at least as far in advance as the current TTL value. If your records currently have a 24-hour TTL, lower them to 300 seconds at least 24 hours (ideally 48) before the migration, so the old high-TTL entries have fully expired from caches by migration time. We cover this in depth in our TTL best practices guide.

Phase 2: Set Up the New Provider

Step 4: Recreate All Records at the New Provider

At the new DNS provider, create every record from your inventory exactly as it exists at the old provider. Match record types, names, values, and TTLs (using the lowered TTLs). Take your time and double-check each one against your inventory. This is where completeness matters most.

Step 5: Verify Records at the New Provider Directly

Before changing any delegation, verify that the new provider is serving your records correctly. You can query the new provider's nameservers directly to confirm they return the right answers, even though the delegation hasn't changed yet. Most providers show you the nameserver hostnames assigned to your zone. Confirm each record resolves correctly when querying those nameservers specifically.

This step is critical: you're confirming the new provider works before you send any real traffic to it. If something is wrong, you find out now, with zero impact, rather than after cutover.

Step 6: Configure DNSSEC (If Used)

If your domain uses DNSSEC, this requires special care. DNSSEC migration involves coordinating the signing keys and DS records between providers. The safest approach is often to temporarily disable DNSSEC before migration (remove the DS record at the registrar, wait for it to expire), complete the migration, then re-enable DNSSEC at the new provider. Disabling DNSSEC briefly reduces security during the migration window but prevents the chain-of-trust breakage that causes SERVFAIL outages. Plan this carefully and consult both providers' DNSSEC migration documentation.

Phase 3: The Cutover

Step 7: Update Nameserver Delegation at the Registrar

This is the actual migration moment. At your domain registrar, update the nameserver (NS) records to point to the new provider's nameservers instead of the old provider's.

Important: do not delete anything at the old provider yet. Both providers should be serving identical records during the transition. As the delegation change propagates, some resolvers will query the old nameservers and some the new ones. Because both have identical records, users get correct answers regardless of which they hit.

Step 8: Understand the Propagation Window

The nameserver delegation change is governed by the TTL of the NS records at the TLD level, which is set by the registry (typically 24-48 hours) and is outside your control. During this window, resolution is split between old and new providers. This is why keeping both providers active with identical records is essential. There's no downtime because both answer correctly.

Phase 4: Verification and Cleanup

Step 9: Verify the Migration

After the delegation change, verify that your domain resolves correctly through the new provider. Use the DNS lookup tool to confirm your records return the expected values and that your NS records now show the new provider's nameservers. Run a Free Domain Risk Report to confirm your full configuration, including email authentication and TLS, is intact.

Step 10: Wait Before Decommissioning the Old Provider

Do not cancel or delete your zone at the old provider immediately. Wait at least 48-72 hours after the delegation change (longer if the TLD NS TTL is high) to ensure all resolvers worldwide have picked up the new delegation. Deleting the old provider's records while some resolvers are still querying them would cause resolution failures for those users.

Step 11: Restore Normal TTLs

Once the migration is confirmed stable, raise the TTLs at the new provider back to their normal operating values (3600 seconds for most records, 86400 for NS records). This reduces query load and improves caching efficiency now that you're no longer in a rapid-change window.

Step 12: Re-enable DNSSEC (If Applicable)

If you disabled DNSSEC for the migration, re-enable it at the new provider and add the new DS record at your registrar. Verify the chain of trust validates correctly.

Migration Checklist

Phase	Step	Timing
Prep	Inventory all records	1 week before
Prep	Lower TTLs to 300s	48 hours before
Setup	Recreate records at new provider	Day before
Setup	Verify new provider directly	Day before
Cutover	Update NS at registrar	Migration time
Verify	Confirm resolution via new provider	After cutover
Cleanup	Decommission old provider	48-72 hours after
Cleanup	Restore normal TTLs	After stable

Common Migration Mistakes

Forgetting Records

The most common mistake. An overlooked TXT record breaks email authentication. A missed subdomain breaks a service. A forgotten CAA record blocks certificate renewal. Thorough inventory and verification prevent this. Cross-check the new provider against your documented inventory before and after cutover.

Not Lowering TTLs in Advance

If you skip the TTL-lowering step, the cutover still works, but resolvers serve cached old records for up to the original TTL duration. With a 24-hour TTL, you get a 24-hour window where some users hit the old provider. If you've already started decommissioning the old provider, those users experience an outage.

Deleting the Old Provider Too Soon

Decommissioning the old provider before the delegation change has fully propagated causes resolution failures for resolvers still using the old nameservers. Always wait 48-72 hours minimum.

Mishandling DNSSEC

DNSSEC migration done incorrectly causes SERVFAIL outages, the same failure mode as the .de TLD outage. If your domain uses DNSSEC, handle it deliberately: disable before migration, re-enable after, and verify the chain at each step.

Not Monitoring During and After

Migration is exactly when you want maximum visibility. If something goes wrong, you want to know immediately, not when users complain.

How DNS Assistant Helps With Migration

DNS Assistant is valuable throughout the migration process:

Pre-migration inventory: Before migrating, DNS Assistant gives you a clear record of your current DNS configuration, so you know exactly what needs to be replicated at the new provider.
Verification: After cutover, DNS Assistant confirms your records resolve correctly and that nothing was missed in the migration.
Change detection during migration: DNS Assistant tracks every record change, giving you a clear log of what changed and when, which is invaluable for troubleshooting.
NS delegation monitoring: DNS Assistant confirms your nameserver delegation updated correctly and that the new nameservers respond authoritatively.
DNSSEC validation: If you use DNSSEC, DNS Assistant validates the chain of trust before, during, and after migration, catching the chain-breakage that causes outages.
Real-time alerting: If anything goes wrong during or after migration, you're notified immediately via email, Slack, Microsoft Teams, webhooks, or SMS.

Having monitoring in place before you migrate means you have a baseline to compare against and immediate visibility into any issues the migration introduces.

Get Started

Before your next DNS migration, establish a baseline. Run a Free Domain Risk Report to document your current configuration, and use the DNS lookup tool to inventory your records.

For continuous monitoring that gives you confidence before, during, and after migration, sign up at dnsassistant.com.

DNS Cache Poisoning Explained (and How DNSSEC Stops It)

Kishore Bhavnanie — Fri, 12 Jun 2026 16:41:37 +0000

Imagine asking a trusted librarian for directions to a specific address, and an imposter slips in to give you a fake answer before the librarian can respond. You follow the directions, confident they came from a reliable source, and end up somewhere completely different. That's DNS cache poisoning: an attacker injects false information into a DNS resolver's cache, causing everyone who uses that resolver to be sent to the wrong place.

Cache poisoning (also called DNS spoofing) is one of the most dangerous DNS attacks because it's invisible to the victim. The domain name in the browser looks correct. There's no obvious sign of compromise. But the IP address behind that name has been silently replaced, redirecting users to a malicious server that could harvest credentials, serve malware, or intercept communications.

This guide explains how cache poisoning works, the famous vulnerability that made it a serious threat, real-world consequences, and how DNSSEC and proper monitoring defend against it.

How DNS Caching Creates the Opportunity

To understand cache poisoning, you first need to understand DNS caching. When a recursive resolver looks up a domain name, it caches the answer for a period defined by the record's TTL (Time to Live). This caching makes DNS fast and reduces load on authoritative servers, as we explained in our authoritative vs recursive DNS guide.

The vulnerability is this: if an attacker can trick a resolver into caching a false answer, that poisoned entry is served to every user of that resolver until the TTL expires. One successful poisoning can affect thousands or millions of users, and it persists in the cache without requiring any further action from the attacker.

How Cache Poisoning Works

DNS over UDP was designed without strong authentication. When a recursive resolver sends a query to an authoritative server, it expects a response that matches two things:

The query name and type (e.g., the A record for yourbank.com)
A 16-bit transaction ID that the resolver included in its query

If a response arrives matching the query and the transaction ID, the resolver accepts it as legitimate and caches it. The attack exploits this:

The attacker triggers a query by getting the resolver to look up a domain (for example, by causing the victim to load a page that references the target domain).
The attacker floods the resolver with forged responses, each guessing the transaction ID and claiming to be from the authoritative server, but containing the attacker's malicious IP address.
If a forged response arrives before the legitimate one and correctly guesses the transaction ID, the resolver accepts it and caches the malicious record.
The poisoned entry is now served to all users of that resolver until the TTL expires.

The 16-bit transaction ID has only 65,536 possible values, which is a small enough number that an attacker flooding responses has a reasonable chance of guessing correctly before the real answer arrives.

The Kaminsky Vulnerability

In 2008, security researcher Dan Kaminsky disclosed a vulnerability that made cache poisoning dramatically more practical than previously believed. Before Kaminsky's discovery, the conventional wisdom was that cache poisoning was difficult because an attacker had a limited window: once the resolver cached the legitimate answer, the attacker had to wait for the TTL to expire before trying again.

Kaminsky's insight was that an attacker didn't need to wait. By querying for random, non-existent subdomains (random123.yourbank.com, random456.yourbank.com, and so on), the attacker could trigger endless fresh queries that weren't cached. For each query, the attacker could attempt to inject a forged response that not only answered the random subdomain but also included malicious authority records redirecting the entire domain.

This removed the timing limitation and made cache poisoning a practical, fast attack. The disclosure triggered a coordinated, industry-wide patching effort. The primary mitigation was source port randomization.

Source Port Randomization: A Partial Fix

The immediate response to Kaminsky's vulnerability was to add another piece of randomness that an attacker has to guess: the source port.

Before the fix, resolvers often used a predictable source port for their queries, so an attacker only had to guess the 16-bit transaction ID. After the fix, resolvers randomized the source port as well, adding another 16 bits of entropy. Now an attacker has to guess both the transaction ID and the source port correctly, expanding the space from about 65,000 possibilities to billions.

This made cache poisoning much harder, but not impossible. Source port randomization is a mitigation, not a cure. Attacks like SAD DNS (disclosed in 2020 and 2021) found ways to infer the source port through side channels, demonstrating that the underlying weakness still exists. The only complete solution is cryptographic authentication of DNS responses, which is what DNSSEC provides.

What Attackers Achieve With Cache Poisoning

A successful cache poisoning attack lets the attacker redirect traffic for a domain to a server they control. The consequences include:

Credential Harvesting

The attacker redirects yourbank.com to a pixel-perfect phishing clone. Users see the correct domain name in their browser, have no reason to suspect anything, and enter their credentials, which the attacker captures.

Malware Distribution

The attacker redirects a software update server or download site to a malicious server that serves malware instead of legitimate files. Users and systems that trust the domain download and execute the malicious payload.

Man-in-the-Middle Interception

The attacker redirects traffic through their own server, intercepting and potentially modifying communications before forwarding them to the real destination. This can capture sensitive data in transit.

Email Interception

By poisoning MX record lookups, an attacker can redirect email delivery to their own mail server, capturing messages intended for the target domain.

Widespread Impact

Because the poisoned entry lives in a shared recursive resolver, a single successful attack affects every user of that resolver. Poisoning a major ISP's resolver or a popular public resolver could affect millions of users simultaneously.

How DNSSEC Stops Cache Poisoning

DNSSEC (DNS Security Extensions) is the definitive defense against cache poisoning. It adds cryptographic signatures to DNS records, allowing resolvers to verify that a response genuinely came from the authoritative server and hasn't been tampered with.

With DNSSEC, even if an attacker successfully injects a forged response that matches the transaction ID and source port, the resolver checks the cryptographic signature. A forged response won't have a valid signature, because the attacker doesn't have the domain's private signing key. The resolver rejects the forged response and the poisoning fails.

The chain of trust works like this:

The root zone vouches for the TLD (.com, .org, etc.) via DS records
The TLD vouches for your domain via DS records
Your domain's DNSKEY records validate the RRSIG signatures on your individual records
A validating resolver checks this entire chain before accepting any answer

If any signature is invalid or missing, the validating resolver rejects the response. This makes injected forgeries cryptographically detectable. We cover the full mechanism in our guide to DNSSEC.

The Catch: DNSSEC Adoption

DNSSEC only protects domains that have it enabled, and only when resolvers validate it. Global DNSSEC adoption remains incomplete. Many domains aren't signed, and not all resolvers validate signatures. For domains without DNSSEC, cache poisoning remains a viable threat mitigated only by source port randomization and other partial defenses.

Enabling DNSSEC on your domains is the single most effective step you can take to protect them against cache poisoning.

Other Defenses

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

These protocols encrypt the connection between a client and its recursive resolver, preventing attackers on the network path from injecting forged responses at that stage. They protect the client-to-resolver link, while DNSSEC protects the resolver-to-authoritative link. They're complementary, addressing different parts of the resolution path.

Source Port and Transaction ID Randomization

Standard in modern resolvers. This raises the bar for attackers but doesn't eliminate the threat entirely, as side-channel attacks have shown.

Reducing TTLs Cautiously

Shorter TTLs limit how long a poisoned entry persists, but they don't prevent poisoning and they increase query load. This is a minor mitigation, not a primary defense.

Monitoring Your Authoritative Records

While cache poisoning happens at the resolver level (outside your direct control), monitoring your authoritative DNS lets you detect related attacks and verify your DNSSEC chain is intact and valid.

How DNS Assistant Helps

Cache poisoning exploits the gap between your authoritative records and what resolvers cache. DNS Assistant helps you maintain the defenses that close that gap:

DNSSEC validation: DNS Assistant continuously validates your DNSSEC chain of trust, confirming that the cryptographic protection against cache poisoning is intact. If your DNSSEC breaks (expired signatures, broken chain), you lose your primary defense against poisoning, and DNS Assistant alerts you immediately.
Record monitoring: DNS Assistant tracks your authoritative records and alerts on changes. By querying your records the way resolvers do, it confirms that resolution returns the values you expect.
SOA serial tracking: Changes to your zone are reflected in the SOA serial. DNS Assistant tracks this, helping you detect unexpected zone modifications.
Multi-channel alerting: Get notified of DNS issues via email, Slack, Microsoft Teams, webhooks, or SMS.

Ensuring DNSSEC is enabled and continuously validated is the most important defense against cache poisoning, and monitoring that protection is exactly what DNS Assistant provides.

Check Your Protection

Use the DNS lookup tool at dnsassistant.com/tools to query your DNSKEY and DS records and confirm DNSSEC is enabled. Run a Free Domain Risk Report to check your DNSSEC status alongside your full DNS configuration.

For continuous DNSSEC validation and DNS monitoring with real-time alerting, sign up at dnsassistant.com.

This article explains DNS cache poisoning for educational and defensive purposes. Understanding how these attacks work is essential for defending against them.

DNS for Microsoft 365: Every Record You Need and Why

Kishore Bhavnanie — Thu, 11 Jun 2026 12:20:58 +0000

Setting up Microsoft 365 for your domain requires 6 to 8 DNS records configured correctly. Miss one and Outlook autoconfiguration breaks. Get the SPF record wrong and your email lands in spam. Forget DKIM and forwarded messages fail authentication. Leave DMARC at p=none and your domain is open to spoofing.

This guide covers every DNS record Microsoft 365 requires, what each one does, the exact values to use, common mistakes that cause outages, and how to verify your configuration.

The Complete Record Set

Here's every DNS record a standard Microsoft 365 deployment needs, organized by function. Replace yourcompany and yourcompany-com with your actual domain values, which you'll find in the Microsoft 365 Admin Center under Settings, then Domains.

1. Domain Verification (TXT Record)

Before Microsoft 365 will accept your domain, you need to prove you own it by adding a verification TXT record.

yourcompany.com.  3600  IN  TXT  "MS=ms12345678"

The MS=ms######## value is unique to your tenant. Find it in the Admin Center when you add your domain. This record can be removed after verification is complete, but there's no harm in leaving it.

2. Mail Routing (MX Record)

The MX record tells the internet where to deliver email for your domain.

yourcompany.com.  3600  IN  MX  0 yourcompany-com.mail.protection.outlook.com.

The priority should be 0 (highest priority). The target hostname follows the pattern yourdomain-tld.mail.protection.outlook.com, where dots in your domain name are replaced with hyphens.

Important update for 2026: Microsoft is migrating MX records to a new endpoint format under mx.microsoft with DNSSEC and DANE support. New domains provisioned after July 2026 will use the new MX format automatically. Existing domains can opt in via PowerShell. The mail.protection.outlook.com endpoint continues to work, but the new endpoint provides stronger transport security. Check Microsoft's documentation for the latest guidance.

Common MX Mistakes

Leaving old MX records in place. If you're migrating from another email provider, remove their MX records. Having two sets of MX records means email is split between providers based on priority values, causing inconsistent delivery.
Wrong priority. The Microsoft MX record should have the lowest priority number (highest priority). If another MX record has a lower number, some email will route there instead.

3. Autodiscover (CNAME Record)

Autodiscover enables Outlook and other email clients to automatically configure connection settings (server addresses, ports, protocols) without the user manually entering them.

autodiscover.yourcompany.com.  3600  IN  CNAME  autodiscover.outlook.com.

This is one of the most frequently forgotten records, and the symptoms are frustrating: Outlook prompts users for server settings, mobile devices fail to set up email, and the "Repair account" option in Outlook doesn't work.

Migration Warning

If you're migrating from on-premises Exchange, check for an existing autodiscover A record or internal Service Connection Point (SCP) that might take priority over the CNAME. Outlook checks multiple autodiscover locations in a specific order, and an old on-premises record can override the Microsoft 365 CNAME, causing Outlook to attempt connecting to the old server after migration.

4. SPF Record (TXT Record)

SPF tells receiving mail servers that Microsoft 365 is authorized to send email on behalf of your domain.

yourcompany.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

If you also send email through other services (marketing platforms, CRM, transactional email providers), add their includes too:

"v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com -all"

Critical SPF Rules

Only one SPF record per domain. If you have two TXT records starting with v=spf1, SPF evaluation returns a permanent error. Combine all includes into a single record.
Stay under 10 DNS lookups. Each include counts as a lookup, and nested includes compound the count. Microsoft's include:spf.protection.outlook.com alone uses several lookups. Monitor your total count as you add services.
Use -all in production. Start with ~all (soft fail) during initial setup, then switch to -all (hard fail) once you've confirmed all legitimate senders are covered.

Check your current SPF record with the DNS lookup tool at dnsassistant.com/tools by querying TXT records for your domain.

5. DKIM (CNAME Records)

DKIM adds cryptographic signatures to outgoing email, proving messages haven't been modified in transit. Microsoft 365 requires two CNAME records for DKIM:

selector1._domainkey.yourcompany.com.  3600  IN  CNAME  selector1-yourcompany-com._domainkey.yourcompany.onmicrosoft.com.
selector2._domainkey.yourcompany.com.  3600  IN  CNAME  selector2-yourcompany-com._domainkey.yourcompany.onmicrosoft.com.

The exact CNAME targets are unique to your tenant. Find them in the Microsoft 365 Defender portal under Email and Collaboration, then Policies, then DKIM.

Enabling DKIM

Adding the CNAME records alone doesn't enable DKIM signing. After the DNS records are in place and propagated, you must enable DKIM in the Defender portal by toggling the "Sign messages for this domain with DKIM signatures" switch. Microsoft will verify that the CNAME records resolve correctly before allowing activation.

This two-step process (DNS first, then portal activation) trips up many admins who add the records and assume DKIM is working. Always verify in the portal that signing is active.

6. DMARC (TXT Record)

DMARC ties SPF and DKIM together and defines what happens when messages fail authentication.

_dmarc.yourcompany.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100"

Start with p=none to collect reports without affecting delivery, then progress to p=quarantine and finally p=reject once you're confident all legitimate sending sources are authenticated.

Consider adding sp=reject to protect subdomains:

"v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100"

For a detailed walkthrough of the DMARC deployment process, see our SPF, DKIM, and DMARC guide.

7. SRV Records (Skype for Business / Teams)

If your organization uses Skype for Business Online or is in a hybrid configuration with Teams, two SRV records are required:

_sip._tls.yourcompany.com.        3600  IN  SRV  100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp.yourcompany.com.  3600  IN  SRV  100 1 5061 sipfed.online.lync.com.

The first enables SIP connectivity for presence and instant messaging. The second enables SIP federation, allowing communication with external organizations.

For organizations fully on Microsoft Teams with no Skype for Business, Microsoft's current guidance is that these SRV records are optional but recommended for backward compatibility and federation scenarios.

8. Additional CNAME Records (Optional)

Depending on your Microsoft 365 services, you may need additional CNAME records for Exchange Online Protection and Mobile Device Management:

enterpriseregistration.yourcompany.com.   3600  IN  CNAME  enterpriseregistration.windows.net.
enterpriseenrollment.yourcompany.com.     3600  IN  CNAME  enterpriseenrollment.manage.microsoft.com.

These are used for Azure Active Directory device registration and Intune MDM enrollment. They're required if you use Azure AD Join or Intune for device management.

Complete Record Summary

Record	Type	Name	Value
Verification	TXT	@	MS=ms########
Mail routing	MX	@	0 yourcompany-com.mail.protection.outlook.com
Autodiscover	CNAME	autodiscover	autodiscover.outlook.com
SPF	TXT	@	v=spf1 include:spf.protection.outlook.com -all
DKIM (key 1)	CNAME	selector1._domainkey	selector1-yourco-com._domainkey.yourco.onmicrosoft.com
DKIM (key 2)	CNAME	selector2._domainkey	selector2-yourco-com._domainkey.yourco.onmicrosoft.com
DMARC	TXT	_dmarc	v=DMARC1; p=reject; rua=mailto:reports@yourco.com
SIP	SRV	_sip._tls	100 1 443 sipdir.online.lync.com
SIP Federation	SRV	_sipfederationtls._tcp	100 1 5061 sipfed.online.lync.com

Verification Checklist

After configuring all records, verify each one before considering the deployment complete:

MX record: Use the DNS lookup tool to query MX records for your domain. You should see only the Microsoft 365 endpoint with the lowest priority number.
SPF record: Query TXT records and verify a single SPF record exists with include:spf.protection.outlook.com.
DKIM CNAMEs: Query CNAME records for selector1._domainkey.yourcompany.com and selector2._domainkey.yourcompany.com. Both should resolve to your onmicrosoft.com targets.
DKIM activation: Confirm in the Microsoft 365 Defender portal that DKIM signing is enabled (not just that the DNS records exist).
DMARC: Query TXT records for _dmarc.yourcompany.com. Verify the policy and reporting address.
Autodiscover: Query CNAME for autodiscover.yourcompany.com. Should resolve to autodiscover.outlook.com.
Send test email: Send a message to a Gmail address and inspect the email headers for spf=pass, dkim=pass, and dmarc=pass.

For a comprehensive scan of your DNS and email authentication configuration, run a Free Domain Risk Report.

Common Problems After Setup

Outlook Keeps Prompting for Credentials

Usually caused by a missing or incorrect autodiscover CNAME. Can also occur if an on-premises autodiscover record is taking priority over the Microsoft 365 CNAME.

Email Going to Spam at External Recipients

Check SPF (is Microsoft's include present?), DKIM (is signing enabled in the portal, not just DNS?), and DMARC (is the policy set?). All three must pass for optimal deliverability. Also verify your sending IP has a valid PTR record (see our reverse DNS guide).

Email From Third-Party Services Failing SPF

If you send email through services beyond Microsoft 365 (marketing tools, CRM, ticketing systems), each one needs to be included in your SPF record. Adding a new service without updating SPF means messages from that service fail SPF checks.

DKIM Showing as "Not Enabled" Despite DNS Records

The CNAME records are necessary but not sufficient. You must also enable DKIM signing in the Microsoft 365 Defender portal. The portal verifies the CNAME records resolve before allowing activation. If activation fails, the CNAME targets are likely incorrect or haven't propagated yet.

Ongoing Monitoring

Microsoft 365 DNS records are configured once but can break over time. Common causes include well-intentioned changes that accidentally modify SPF, DKIM key rotations that require CNAME updates, domain transfers that drop existing records, and security incidents that modify MX routing.

DNS Assistant monitors all Microsoft 365 DNS records continuously and alerts your team when anything changes. Whether it's an MX record modification that reroutes email, an SPF change that breaks authentication, a missing DKIM CNAME after a domain migration, or a DMARC policy downgrade, you'll know immediately rather than discovering it when users report email problems.

For continuous monitoring of your Microsoft 365 DNS configuration, sign up at dnsassistant.com.

Self-Hosted vs. Managed DNS: Pros, Cons, and Security Implications

Kishore Bhavnanie — Thu, 11 Jun 2026 12:18:25 +0000

When you register a domain, one of the first decisions you make is where your DNS lives. Most organizations default to their registrar's DNS service (GoDaddy, Namecheap, Squarespace) or a managed provider (Cloudflare, AWS Route 53, Azure DNS). Some, particularly those with strict compliance requirements or complex internal architectures, run their own authoritative nameservers using BIND, PowerDNS, Knot, or NSD.

The choice between self-hosted and managed DNS isn't just a technical preference. It affects your uptime, your security posture, your operational burden, and your ability to respond to incidents. Each approach has legitimate strengths and real tradeoffs.

This guide breaks down both options across the dimensions that matter: reliability, security, performance, control, cost, and operational complexity.

What "Self-Hosted" and "Managed" Actually Mean

Self-hosted DNS means you operate your own authoritative nameservers. You install DNS server software (BIND, PowerDNS, Knot DNS, NSD) on infrastructure you control, configure zones, manage records, handle replication between primary and secondary servers, and maintain the servers themselves. Your nameservers are listed at the registrar as the authoritative source for your domain.

Managed DNS means a third-party provider operates the authoritative nameservers on your behalf. You configure records through their dashboard or API, and they handle server infrastructure, global distribution, DDoS protection, and availability. Providers include Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, NS1 (now IBM), Dyn (now Oracle), and dozens of others.

A hybrid approach is also common: using a managed provider for public-facing domains while running self-hosted DNS for internal zones (split-horizon DNS), or using a managed provider as a secondary alongside self-hosted primaries for redundancy.

Reliability

Managed DNS

Major managed DNS providers operate globally distributed anycast networks with hundreds of points of presence. Cloudflare's DNS runs on over 300 data centers worldwide. AWS Route 53's SLA guarantees 100% availability. These providers handle billions of queries per day and have dedicated teams managing capacity, failover, and DDoS mitigation around the clock.

The result is that managed DNS achieves availability levels that are extremely difficult to replicate in-house. DNS resolution latency is also lower because anycast routing directs queries to the nearest point of presence.

The tradeoff: you're dependent on the provider. If Cloudflare has an outage (and they have, including notable incidents in 2022 and 2023), every domain using their DNS is affected simultaneously. You have no ability to fix or work around the problem. You wait.

Self-Hosted DNS

Self-hosted DNS gives you direct control over availability, but achieving it is your responsibility. You need at least two geographically separated nameservers (most registries require a minimum of two) with independent network paths. You need to handle capacity planning, server maintenance, OS patching, DNS software updates, and DDoS mitigation yourself.

Most organizations running self-hosted DNS don't have the infrastructure to match a managed provider's global distribution. A typical setup is two servers in two data centers, which provides basic redundancy but not the global coverage or DDoS resilience that managed providers offer.

The advantage: your DNS availability is decoupled from any third party. A Cloudflare outage doesn't affect you. A Route 53 incident doesn't affect you. Your uptime depends on your own infrastructure and your own team.

Security

Managed DNS

Managed providers handle DDoS protection, rate limiting, and infrastructure security as part of the service. Cloudflare, for example, absorbs DNS DDoS attacks across their global network without any action required from you. Most providers also offer DNSSEC signing with automated key rotation and signature refresh.

The security concern with managed DNS is account security. If an attacker compromises your DNS provider account (through phished credentials, a weak password, or a missing MFA configuration), they can modify any record on any domain in your account. DNS provider account compromise is one of the most common vectors for DNS hijacking. The provider's security becomes your security.

Additionally, you're trusting the provider's employees and systems with the ability to modify your DNS. Insider threats, software bugs, and operational errors at the provider level can affect your domains.

Self-Hosted DNS

Self-hosted DNS eliminates the third-party trust surface. No provider account can be compromised to modify your records. No provider employee has access to your zone data. Your attack surface is limited to your own infrastructure and your own team.

The challenge: you're now responsible for all security aspects that managed providers handle for you. This includes DDoS mitigation (DNS amplification attacks can generate massive traffic volumes), DNSSEC key management (key generation, rotation, signature refresh, DS record coordination with the registrar), software vulnerability patching (BIND has had numerous critical CVEs over its history), and access control to the DNS server itself.

DNSSEC is particularly demanding in a self-hosted environment. Managed providers handle DNSSEC automatically. Self-hosted DNSSEC requires you to manage Zone Signing Keys (ZSK), Key Signing Keys (KSK), RRSIG signature refresh schedules, and DS record updates at the registrar during key rollovers. A missed signature refresh or a botched key rollover can take your domain offline for every validating resolver, as the .de TLD DNSSEC outage demonstrated at national scale.

Performance

Managed DNS

Managed providers with global anycast networks deliver the lowest resolution latency for users worldwide. A query from Tokyo hits a local point of presence rather than crossing the Pacific to reach your server in Virginia. This latency difference (typically 5-50ms vs. 100-300ms) compounds across the multiple DNS lookups involved in a typical web page load.

Some managed providers also offer advanced traffic management: GeoDNS (returning different IPs based on the querier's location), weighted routing, latency-based routing, and health-checked failover. These capabilities require global infrastructure that self-hosted DNS can't easily replicate.

Self-Hosted DNS

Self-hosted DNS performance depends on your server locations and network connectivity. With two servers in US data centers, resolution latency for European or Asian users will be higher than with a managed provider. You can improve this by adding more servers in more locations, but each additional server adds operational overhead.

For organizations with a regional user base (all users in one country or continent), the performance difference may be negligible. For global audiences, managed DNS has a significant edge.

Control and Flexibility

Self-Hosted DNS

This is where self-hosted DNS excels. You have complete control over your configuration: custom record types, non-standard TTLs, complex zone delegation structures, split-horizon views, response rate limiting policies, dynamic DNS updates, and integration with internal systems. If your DNS software supports it, you can configure it.

Self-hosted DNS also integrates naturally with configuration management tools (Ansible, Terraform, Puppet) and version control systems. Your zone files can be stored in Git, reviewed in pull requests, and deployed through CI/CD pipelines.

Managed DNS

Managed providers offer the features that most organizations need: all standard record types, API access, programmatic management, and integration with their broader cloud ecosystem (Route 53 integrates with AWS services, Azure DNS with Azure services, Cloudflare DNS with Cloudflare's CDN and security products).

The limitation is that you're constrained to the provider's feature set and API. If you need a capability the provider doesn't offer (a specific EDNS option, an unusual record type, or a custom response policy), you can't add it. Provider-specific restrictions also apply: some providers don't support all record types, have limits on the number of records per zone, or restrict TTL values to specific ranges.

Cost

Managed DNS

Many managed DNS providers offer free tiers that cover basic needs. Cloudflare's free plan includes DNS with no query limits. Route 53 charges $0.50 per hosted zone per month plus $0.40 per million queries. Google Cloud DNS charges $0.20 per zone per month plus $0.40 per million queries. For most organizations, managed DNS costs are negligible.

Enterprise plans with advanced features (DNSSEC management, traffic management, dedicated support, SLA guarantees) cost more, typically $50-500+/month depending on the provider and feature set.

Self-Hosted DNS

The DNS software itself (BIND, PowerDNS, Knot, NSD) is open source and free. The costs are in the infrastructure and operations: at minimum two servers (or VMs) in separate locations, bandwidth, monitoring, DDoS mitigation, and the engineering time to manage it all.

A basic self-hosted setup (two VPS instances) might cost $20-50/month in infrastructure. But the operational cost, measured in engineer hours for maintenance, patching, DNSSEC management, troubleshooting, and incident response, is significantly higher than the subscription cost of a managed provider.

When to Use Each Approach

Choose Managed DNS When

You need global performance with low resolution latency worldwide
You want DDoS protection without building your own mitigation infrastructure
You want automated DNSSEC with hands-off key rotation
Your team doesn't have dedicated DNS engineering expertise
You want to minimize operational overhead for commodity infrastructure
You need advanced traffic management (GeoDNS, failover, weighted routing)

Choose Self-Hosted DNS When

Compliance or regulatory requirements mandate that DNS data stays on infrastructure you control
You need complete configuration flexibility that managed providers can't offer
You want zero dependency on third-party providers for critical infrastructure
You have a dedicated DNS or infrastructure engineering team
You operate complex internal DNS architectures (split-horizon, dynamic updates, custom plugins)
You need to integrate DNS with internal systems that don't have managed provider API support

Consider a Hybrid Approach When

You need both internal and external DNS with different requirements
You want managed DNS for public-facing domains but self-hosted for internal zones
You want a managed provider as a secondary for redundancy alongside self-hosted primaries
You're migrating from self-hosted to managed and need a transition period

Monitoring Matters Regardless of Approach

Whether you use managed DNS, self-hosted DNS, or a hybrid, monitoring is not optional. Each approach has its own failure modes:

Managed DNS risks: Provider outages, account compromise, unauthorized changes through the provider's dashboard, misconfiguration via API automation, provider-side bugs that affect your records.

Self-hosted DNS risks: Server outages, DNSSEC signature expiration, software vulnerabilities, misconfigurations in zone files, DDoS attacks overwhelming your infrastructure, lame delegation after server changes.

DNS Assistant monitors your DNS records regardless of where they're hosted. The platform checks what resolvers actually see, not what your provider's dashboard shows. This means you catch issues whether they originate from your managed provider, your self-hosted infrastructure, your registrar, or the TLD registry.

Record change detection catches unauthorized modifications regardless of how they were made
DNSSEC validation verifies the chain of trust end-to-end, catching signing failures in both managed and self-hosted environments
NS delegation monitoring detects lame delegation, nameserver changes, and delegation mismatches
WHOIS monitoring tracks registration changes that could indicate unauthorized domain transfers
Multi-channel alerting ensures your team knows about issues via email, Slack, Microsoft Teams, webhooks, or SMS

Check your current DNS configuration with the DNS lookup tool at dnsassistant.com/tools, or run a Free Domain Risk Report for a comprehensive scan.

For continuous monitoring with real-time alerting, sign up at dnsassistant.com.