DEV Community: Kishore Bhavnanie

What Is DNS Posture Management (DNSPM)? The Complete Guide

Kishore Bhavnanie — Fri, 10 Jul 2026 20:35:00 +0000

DNS Posture Management (DNSPM) is an emerging security discipline focused on continuously monitoring, assessing, and improving the security posture of an organization's entire DNS and domain footprint. Where traditional DNS monitoring asks only "is my domain resolving," DNS Posture Management asks a far more important question: "is my DNS configured securely, and is it staying secure over time?" It treats DNS not as a utility that either works or does not, but as a critical, continuously changing attack surface that requires the same ongoing security attention as endpoints, cloud infrastructure, and applications.

This guide explains what DNS Posture Management is, why it has emerged as a distinct discipline, what it covers, and how to implement it. If you have heard the term DNSPM and want to understand what it actually means in practice, this is the complete picture.

Why DNS Needs Its Own Posture Discipline

Over the past decade, security has increasingly organized itself around the idea of "posture management." Cloud Security Posture Management (CSPM) emerged because cloud environments were too dynamic and sprawling to secure with occasional manual audits. The same logic now applies to DNS.

DNS has quietly become one of the most security-critical and least-governed parts of most organizations' infrastructure. It controls where your traffic goes, whether your email can be trusted, which authorities can issue your certificates, and, increasingly, how automated systems discover and connect to your services. Yet DNS is often managed by whoever has access, changed by multiple teams and tools, and monitored, if at all, only for uptime.

The result is a widening gap between how important DNS is and how carefully it is watched. DNS Posture Management exists to close that gap. It applies the continuous, posture-oriented approach that transformed cloud security to the domain name system, treating every record, every subdomain, and every configuration as something to be continuously assessed for risk.

DNS Posture Management vs. Traditional DNS Monitoring

The distinction is fundamental, and understanding it is the key to understanding DNSPM.

Traditional DNS monitoring is availability-focused. It periodically checks whether your domain resolves and how quickly. Its core question is "is it up?" This is useful, but it is a narrow slice of DNS health. A domain can resolve flawlessly while a subdomain is hijacked, email authentication is broken, a certificate misconfiguration festers, or an unauthorized record change quietly redirects traffic.

DNS Posture Management is security-focused and continuous. Its core question is "is it secure, and is it staying secure?" It watches the configuration and security state of your entire DNS footprint, not just whether individual domains respond. It is the difference between a smoke detector that only goes off when the building is already ablaze and a system that continuously monitors for the conditions that cause fires.

We explore this specific distinction in depth in our guide on DNS monitoring versus uptime monitoring.

The Core Components of DNS Posture Management

A complete DNS Posture Management practice covers several distinct areas, each addressing a different class of DNS risk. Together they form the full picture of what it means to manage DNS posture.

1. Asset Discovery and Inventory

You cannot secure what you do not know you have. The foundation of DNSPM is a complete, continuously updated inventory of every domain and subdomain your organization controls, including the forgotten ones. Most organizations cannot list all their subdomains, a symptom of the shadow DNS problem, where subdomains created by marketing, development, and other teams accumulate outside central visibility. Subdomain discovery, often using Certificate Transparency logs, surfaces this hidden footprint so it can be secured.

2. Dangling Record and Subdomain Takeover Detection

When a DNS record points at a third-party service or cloud resource that has been deprovisioned, it becomes "dangling," and an attacker can claim the abandoned resource to serve malicious content under your trusted domain. Subdomain takeover is one of the most exploited and overlooked DNS risks, and detecting these dangling records across cloud providers is a central DNSPM capability.

3. Record Change Detection

DNS records can be changed by many parties: multiple team members, automated systems, third-party integrations, and attackers who gain access. DNSPM continuously watches every record type (A, AAAA, MX, TXT, NS, SOA, CNAME, CAA) and alerts on any change, so unauthorized or accidental modifications are caught immediately rather than discovered after they cause harm.

4. Email Authentication Posture

SPF, DKIM, and DMARC records live in DNS and determine whether your email can be trusted and whether attackers can spoof your domain. DNSPM assesses the health of these records, not merely their existence, catching the misconfigurations and drift that leave organizations spoofable. Our SPF, DKIM, and DMARC guide covers this area in detail.

5. Certificate and TLS Posture

DNS controls certificate issuance through CAA records, which specify which certificate authorities may issue certificates for your domains. Combined with TLS configuration assessment, this ensures the trust layer of your web presence is sound and that unauthorized certificate issuance is prevented.

6. DNSSEC Validation

DNSSEC cryptographically protects DNS data from tampering, but a broken signature or a botched key rollover can take a domain offline for validating resolvers, as a major national outage demonstrated when a routine key rollover went wrong. DNSPM continuously validates the DNSSEC chain of trust, catching problems before they become outages. Our guide to what DNSSEC is and why it matters explains the fundamentals.

7. WHOIS and Domain Expiration Monitoring

Domain registration details and expiration dates are part of your DNS posture. Unauthorized registrar changes can signal a hijacking attempt, and a lapsed domain can cause outages or be claimed by someone else. DNSPM tracks these independently of registrar notifications, providing a safety net for one of the most preventable disasters in the category.

Why DNS Posture Management Matters Now

Several trends have converged to make DNSPM a discipline whose time has come.

The attack surface has exploded. Cloud adoption, SaaS proliferation, and distributed teams mean organizations now have far more domains and subdomains than ever, created and abandoned faster than manual processes can track. Each is a potential entry point.

DNS-layer attacks are increasing. Subdomain takeover, DNS hijacking, and domain impersonation are common and effective. Attackers understand that DNS is under-monitored and exploit that gap. Large-scale campaigns built on abandoned DNS records and domain impersonation appear regularly in security research.

Compliance expectations are rising. Frameworks like SOC 2, ISO 27001, NIS2, DORA, and PCI-DSS increasingly expect continuous evidence of control over your infrastructure, including DNS. Point-in-time snapshots no longer satisfy auditors. We cover this in our guide to building a continuous DNS compliance program.

DNS is taking on new roles. Emerging standards are extending DNS into new territory, such as using DNS as the discovery layer for AI agents, which raises the stakes of DNS security even further. As DNS controls more, securing its posture matters more.

How to Implement DNS Posture Management

Adopting DNSPM is a practical progression, not a massive undertaking.

Start with discovery. Build a complete inventory of your domains and subdomains, including the ones you have lost track of. This is the foundation everything else rests on, and it almost always surfaces assets the organization had forgotten.

Assess your current posture. Evaluate what you have found: dangling records, missing or weak email authentication, DNSSEC status, certificate configuration, and any obvious misconfigurations. This baseline tells you where the immediate risks are.

Remediate the priorities. Address the highest-risk findings first, typically dangling records that create takeover exposure, followed by email authentication gaps and certificate issues.

Enable continuous monitoring. Move from a one-time assessment to ongoing monitoring, with real-time alerting so that new risks are caught as they emerge rather than discovered at the next manual audit. This is the shift that turns a point-in-time cleanup into genuine posture management.

Establish ownership and review. Assign clear responsibility for DNS posture and layer periodic reviews on top of continuous automation. DNS that is nobody's job is DNS that accumulates risk unseen.

DNS Assistant: DNS Posture Management in Practice

DNS Assistant is a purpose-built DNS Posture Management platform. Rather than treating DNS as one small feature within a broader monitoring tool, it is designed specifically to deliver the full DNSPM discipline described above, and to make it accessible to organizations of any size, not just large enterprises.

With DNS Assistant, the components of DNS Posture Management become concrete capabilities:

Subdomain discovery surfaces your full domain footprint, including forgotten subdomains.
Dangling DNS and subdomain takeover detection across more than 22 cloud providers identifies takeover-vulnerable records.
Continuous record change detection across all record types, with real-time alerts.
Email authentication health for SPF, DKIM, and DMARC.
TLS grading and certificate posture, including CAA assessment.
DNSSEC validation of the full chain of trust.
WHOIS change and domain expiration monitoring.
Real-time alerting across email, Slack, Microsoft Teams, SMS, and webhooks, with SIEM integration via API and webhooks.
Multi-tenant, role-based access suited to teams and agencies managing many domains.
Data export in CSV, Excel, and PDF, and a viewable change-history audit trail for compliance evidence.

Delivered through self-serve onboarding with a free tier and free public tools, DNS Assistant brings DNS Posture Management within reach of small and mid-sized teams, not just organizations with enterprise security budgets. You can see how this approach compares to traditional tools on our how we are different page.

Getting Started with DNS Posture Management

The best way to understand your DNS posture is to see it. Run a Free Domain Risk Report to assess a domain's configuration, email authentication, and TLS posture, or inspect specific records with the DNS lookup tool. Both are free and require no signup.

To adopt continuous DNS Posture Management across your domains, with discovery, monitoring, alerting, and exportable evidence, start free at dnsassistant.com. DNS is too important to watch for uptime alone. Managing its posture is how you turn one of your largest attack surfaces into a continuously verified strength.

Building a Continuous DNS Compliance Program (SOC 2, ISO 27001, NIS2 & PCI-DSS Ready)

Kishore Bhavnanie — Tue, 07 Jul 2026 13:20:52 +0000

Every year, thousands of companies scramble during audit season trying to prove they have control over their DNS. Auditors ask deceptively simple questions: Can you show us every subdomain you own? How do you know no one created an unauthorized record? What happens if a DNS change introduces a compliance violation? Most teams answer with manual exports, screenshots, and crossed fingers.

In 2026, that approach no longer holds up. Regulations like NIS2 and DORA, updated SOC 2 criteria, and PCI-DSS v4.0 increasingly expect continuous evidence of control, not a point-in-time snapshot assembled the week before the auditor arrives. DNS, one of the largest and least-governed parts of most organizations' attack surface, is exactly where this gap shows.

This article shows how to build a continuous DNS compliance program: one that turns DNS from an audit liability into a documented, continuously validated strength. It is a framework and a set of practices, not a product pitch, though we will be honest at the end about where continuous monitoring fits and where it does not.

Why DNS Is a Major Compliance Blind Spot

DNS quietly governs several areas that compliance frameworks care about deeply:

Email authentication through SPF, DKIM, and DMARC records, which affect both security and deliverability.
Certificate issuance control through CAA records, which determine who can issue certificates for your domains.
Asset inventory, since every domain and subdomain is an internet-facing asset that frameworks expect you to know about and account for.
Third-party and supply-chain exposure through delegations and records pointing at external providers.
Segmentation and configuration integrity, where a single record change can alter where traffic and trust flow.

Yet most compliance tooling either ignores DNS entirely or checks only basic uptime. The result is a control surface that is genuinely in scope for audits but rarely monitored with the rigor auditors increasingly expect.

DNS Requirements Across Major Frameworks

Different frameworks touch DNS from different angles, but they converge on the same underlying expectations: know your assets, control and monitor changes, and be able to produce evidence.

Framework	DNS-Relevant Expectations	Common Audit Weak Point
SOC 2	Change monitoring and logical access (CC6.1, CC7.2)	Undetected or unlogged DNS changes
ISO 27001:2022	Asset management and information handling (A.5.9, A.8.1)	Shadow IT subdomains outside inventory
NIS2 / DORA	Supply-chain security and incident reporting	Unmonitored third-party DNS delegations
PCI-DSS v4.0	Secure configurations (Req 1, 2, 4)	Weak CAA records, missing DMARC

This mapping is informational and reflects common interpretations of how DNS touches each framework. It is not a substitute for guidance from your own auditor or compliance advisor, who should confirm how these controls apply to your specific environment.

How to Build a Continuous DNS Compliance Program

A practical program comes down to six steps, moving from one-time discovery to ongoing validation.

1. Full DNS Discovery

Map every domain, subdomain, and DNS provider under your organization's control, including domains inherited through acquisitions and subdomains created outside central IT (the shadow DNS problem). You cannot govern or produce evidence for assets you have not discovered, so this is the foundation everything else rests on.

2. Establish Baselines

Define what a compliant configuration looks like for each environment (production, staging, marketing microsites, and so on). Baselines turn vague expectations into concrete, checkable states: which records should exist, what email authentication should be in place, whether DNSSEC is required.

3. Enable Continuous Monitoring

Track changes to records, the appearance of new subdomains, approaching expirations, dangling delegations, and security misconfigurations, continuously rather than in periodic manual sweeps. This is the shift from point-in-time snapshots to the continuous evidence that modern frameworks increasingly expect.

4. Real-Time Alerting

Get notified the moment a risky or unexpected change occurs, an unauthorized record modification, a new subdomain, a dangling record, a DNSSEC problem, so your team can investigate and respond quickly. Fast detection is what keeps a misconfiguration from becoming an incident, and timely response is itself evidence of a functioning control.

5. Maintain an Audit Trail and Exportable Evidence

Keep a continuous record of what changed and when, so that when an auditor asks "how do you know no one created an unauthorized record," you can show the history rather than reconstruct it. Being able to export your current domain and record data on demand, with timestamps, turns evidence-gathering from a multi-week scramble into a routine task.

6. Schedule Regular Reviews

Layer periodic human review on top of continuous automation: monthly hygiene checks and quarterly deep-dive governance reviews. Automation catches changes in real time; scheduled reviews catch drift, reassess baselines, and demonstrate the ongoing oversight auditors look for. For the mechanics of a structured review, our enterprise DNS monitoring strategy guide goes deeper.

Where DNS Assistant Fits

DNS Assistant is a continuous DNS monitoring and visibility layer. It is honest to describe it as the part of a compliance program that watches your DNS and produces evidence, not as a system that manages your DNS assets or runs your compliance program for you. Here is specifically what it does, and where the boundaries are:

Discovery and monitoring of your domains and subdomains, including subdomain discovery via Certificate Transparency, so your asset inventory reflects reality rather than documentation.
Continuous change detection across record types, with real-time alerts on additions, modifications, removals, expirations, dangling records, and DNSSEC issues.
A viewable audit trail of DNS changes over time, with historical change records that a site administrator can review to see what changed and when.
Data export of your monitored domain and record data as CSV, Excel, or PDF, with timestamps and either summary or full raw-field detail, useful as evidence you attach to your own audit documentation.
SIEM integration via API and webhooks: alerts can be pushed to your systems or pulled from the API, so DNS change data flows into Splunk, Elastic, Microsoft Sentinel, or your ticketing tools alongside your other security telemetry.
Multi-tenant, role-based access suited to organizations and teams managing DNS across multiple entities.

Two honest boundaries worth stating plainly. DNS Assistant detects and alerts on changes; it does not gate or approve them, your change-approval process lives in your own workflow, and DNS Assistant provides the detection and evidence layer around it. And its exports are data exports you use as evidence, not auto-generated audit reports pre-mapped to specific SOC 2 or ISO controls. The value is that the continuous visibility and change history feed your compliance program; the program itself is still yours to run.

Framed correctly, that is exactly what the six-step model needs at its core: continuous discovery, monitoring, alerting, and exportable history, so the evidence exists continuously instead of being assembled under deadline pressure.

A 30-Day Implementation Path

Standing up the monitoring layer of this program is a matter of weeks, not months:

Week 1: Add your domains and run the initial discovery scan to establish your real asset inventory.
Week 2: Review and remediate the initial findings (dangling records, missing email authentication, weak CAA), and define your compliance baselines.
Week 3: Configure alerting and connect it to Slack, Teams, or your SIEM via API and webhooks.
Week 4: Export your first evidence set, establish your review cadence, and share the picture with your team.

Free Download: DNS Compliance & Governance Framework

To help you put this into practice, we have published a DNS Compliance & Governance Framework as a free, shareable PDF. It includes the roles and responsibilities matrix, a detailed control checklist with recommended frequencies, a risk-scoring matrix with remediation SLAs, and a summary mapping to SOC 2, ISO 27001, NIS2, DORA, and PCI-DSS. It is free to circulate within your organization and across your industry, no signup required.

Download the DNS Compliance & Governance Framework (PDF)

Final Thoughts

DNS compliance does not have to mean a last-minute scramble before every audit. Moving from periodic manual checks to continuous DNS posture management reduces risk, simplifies audits, and strengthens your security program, and it does so by making the evidence a byproduct of good monitoring rather than a project unto itself.

The frameworks are converging on the same expectation: show continuous control, not an annual snapshot. DNS is one of the easier places to meet that expectation, once you have continuous discovery, monitoring, and exportable history in place.

See where your DNS stands today with a Free Domain Risk Report, or inspect specific records with the DNS lookup tool. For continuous monitoring, change history, and exportable evidence across your domain estate, sign up at dnsassistant.com.

Shadow DNS: The Subdomains Your Team Forgot Exist

Kishore Bhavnanie — Thu, 02 Jul 2026 16:29:25 +0000

Your marketing team launches a product campaign. They need a landing page fast, so they spin up launch.yourbrand.com and point it at a third-party campaign tool. The campaign runs, it succeeds, everyone moves on. Six months later, the marketing tool subscription lapses and the hosted resource is deprovisioned. But the DNS record still exists, still pointing at infrastructure your company no longer controls. Nobody in IT ever knew the subdomain existed, and nobody remembers to remove it. That is shadow DNS, and it is one of the most common and overlooked risks in modern domain management.

Shadow DNS is the DNS equivalent of shadow IT: DNS records, subdomains, and configurations created outside the visibility and governance of the team responsible for the domain. It accumulates quietly, spreads across teams and vendors, and becomes an attack surface that no one is watching precisely because no one knows it is there.

This article explains what shadow DNS is, how it forms, why it is dangerous, and how to bring it back under control.

First, a Note on the Term

"Shadow DNS" is used in a few different ways, so it is worth being clear. Recently, security researchers have used the term to describe a specific malware operation where compromised routers redirect devices to rogue DNS resolvers for ad fraud and traffic manipulation. That is a real and serious threat, but it is a different thing from what we are discussing here.

In this article, shadow DNS means the governance problem: the DNS records and subdomains within your own domains that exist outside your central oversight. This is the more common, more preventable, and for most organizations more relevant issue. It is the DNS you own but have lost track of.

How Shadow DNS Forms

Shadow DNS rarely comes from bad intent. It comes from the normal, distributed way modern organizations operate, where many teams and tools can influence DNS without a central checkpoint.

Marketing and Campaign Subdomains

This is the classic source. Marketing teams create subdomains for campaigns, events, product launches, and promotions, often pointing them at third-party platforms: landing page builders, email marketing tools, event registration systems, or webinar platforms. Each of these requires a DNS record (usually a CNAME) pointing at the vendor's infrastructure. These get created quickly, under deadline pressure, frequently without IT involvement, and rarely get cleaned up when the campaign ends.

SaaS and Third-Party Integrations

Every SaaS tool that wants a branded subdomain (help.yourbrand.com for a support platform, status.yourbrand.com for a status page, mail.yourbrand.com for an email service) needs a DNS record pointing at its infrastructure. As organizations adopt more tools, these records multiply. When a tool is replaced or abandoned, the DNS record often outlives the subscription.

Developer and Testing Environments

Engineering teams create subdomains for staging, testing, demos, and preview environments. These proliferate naturally in fast-moving development, and temporary environments have a way of leaving permanent DNS records behind.

Decentralized DNS Management

In many organizations, more than one person or team can edit DNS, or DNS is managed across multiple providers and registrars. Without a single source of truth, records get added in one place and forgotten in another. The larger the organization, the more fragmented this becomes.

Mergers, Acquisitions, and Reorganizations

When companies merge or acquire, they inherit each other's entire DNS footprint, often poorly documented. Domains and subdomains created by the acquired organization become shadow DNS for the acquiring one, since no one on the new team has visibility into what exists or why.

Why Shadow DNS Is Dangerous

Shadow DNS is not just untidy. It is a genuine security risk, and the danger scales with how much of it accumulates.

Subdomain Takeover

This is the headline risk. When a subdomain points at a third-party service (via CNAME) and that service is later deprovisioned, the DNS record becomes "dangling," it points at infrastructure that no longer belongs to you. An attacker who claims that abandoned resource on the third-party platform can then serve their own content from your subdomain, inheriting your domain's trust and reputation. We cover this attack in depth in our subdomain takeover guide, and it was the mechanism behind the large-scale Borrowed Trust campaign. Shadow DNS is where takeover-vulnerable records come from: subdomains created outside governance are exactly the ones nobody remembers to decommission.

Expanded Attack Surface

Every subdomain is a potential entry point. Shadow subdomains may run outdated software, expose forgotten admin panels, or host applications that never received security review. Because IT does not know they exist, they never get patched, monitored, or included in security assessments.

Phishing and Brand Abuse

A subdomain of your legitimate domain carries your brand's trust. If an attacker takes over a shadow subdomain, they can host convincing phishing pages under your real domain name, far more credible than a lookalike domain because it genuinely is your domain.

Certificate and Email Exposure

Shadow DNS can include forgotten email-related records or subdomains that affect your security posture. A subdomain without proper email authentication can be exploited for spoofing, and forgotten records can undermine the email authentication you have carefully configured elsewhere.

Compliance and Audit Gaps

Security frameworks and audits increasingly expect a complete inventory of your internet-facing assets. Shadow DNS means your actual attack surface is larger than your documented one, a gap that undermines compliance and leaves you unable to answer a basic question: what does our organization actually expose to the internet?

Bringing Shadow DNS Under Control

Eliminating shadow DNS is not a one-time cleanup. It is an ongoing discipline of visibility and governance. Here is how to approach it.

1. Build a Complete DNS Inventory

You cannot govern what you cannot see. Start by discovering every domain and subdomain your organization actually has, not the list you think you have, but the real one. This means going beyond your documented records to actively discover subdomains that exist in the wild. Certificate Transparency logs, which record every TLS certificate issued, are one powerful discovery source, since most live subdomains have certificates. Subdomain discovery tools surface names you had forgotten or never knew about.

2. Audit What Each Record Points At

For every subdomain, determine what it points at and whether that target is still valid. Records pointing at third-party services are the priority: verify the service is still active and still yours. Dangling records pointing at deprovisioned cloud resources or lapsed SaaS accounts are your immediate takeover risk and should be removed or reclaimed.

3. Establish DNS Governance

Create a process for how DNS records get created and, critically, retired. This might include a central request process, a single source of truth for DNS across the organization, and clear ownership for each subdomain. The goal is to prevent new shadow DNS from forming while you clean up the old.

4. Make Decommissioning a Required Step

The root cause of shadow DNS is that records get created but never removed. Build DNS cleanup into your offboarding processes: when a campaign ends, a tool is retired, or a project is decommissioned, removing the associated DNS records should be a required checklist item, not an afterthought.

5. Monitor Continuously

Because shadow DNS forms continuously through normal operations, a one-time audit is not enough. New subdomains will appear, records will change, and services will be deprovisioned. Continuous monitoring is what keeps your inventory accurate over time and catches the moment a record becomes dangling or a new subdomain appears.

How DNS Assistant Helps

Shadow DNS is fundamentally a visibility problem, and visibility is exactly what DNS Assistant provides for the domains you monitor:

Subdomain discovery uses Certificate Transparency logs and other techniques to surface subdomains of your monitored domains, helping you find the shadow subdomains you had lost track of and build an accurate inventory.
Dangling DNS and subdomain takeover detection across 22+ cloud providers identifies the records that point at deprovisioned infrastructure, the takeover-vulnerable records that shadow DNS tends to produce.
Continuous record monitoring detects when records on your monitored domains change or when a subdomain's target shifts, so your inventory stays current and dangling records are caught as they form.
Email authentication and TLS posture checks surface subdomains and records with weak configurations that expand your exposure.
Real-time alerting via email, Slack, Microsoft Teams, webhooks, and SMS, so changes are caught when they happen.

The core value is turning the invisible visible. Shadow DNS is dangerous specifically because no one is watching it; continuous discovery and monitoring is how you start watching, and keep watching, the parts of your DNS footprint that would otherwise slip out of view.

Find Your Shadow DNS

The free DNS lookup tool at dnsassistant.com/tools and the Free Domain Risk Report let you inspect the records, DNSSEC status, email authentication, and TLS posture of a domain you already know about, a useful starting point for understanding your configuration.

Uncovering shadow DNS goes a step further: continuous subdomain discovery and dangling DNS detection across 22+ cloud providers surface the subdomains you had lost track of and the records pointing at deprovisioned infrastructure. These are part of the full monitoring platform. To bring your shadow DNS into the light, sign up at dnsassistant.com.

DNS Governance During Mergers and Acquisitions

Kishore Bhavnanie — Thu, 02 Jul 2026 16:25:43 +0000

When one company acquires another, the due diligence teams pore over financials, contracts, intellectual property, and liabilities. What almost never gets the same scrutiny is DNS. Yet the moment an acquisition closes, the acquiring organization inherits the target's entire domain and DNS footprint: every domain they registered, every subdomain they created, every nameserver delegation, every email authentication record, and every forgotten, dangling, or misconfigured entry accumulated over years of operation. Most of it is undocumented, and much of it is now your responsibility and your risk.

Mergers and acquisitions are a moment of maximum DNS chaos. Two organizations with different DNS practices, providers, and conventions suddenly become one. Domains need to be transferred, consolidated, or retired. Email has to keep flowing through the transition. Brand redirects need to be set up. And attackers know that M&A periods are moments of distraction and disorganization, making them prime opportunities to exploit the confusion.

This article covers the DNS risks that surface during mergers and acquisitions, and how to govern DNS through the transition without leaving gaps that turn into incidents.

Why M&A Is a DNS Risk Event

DNS is rarely part of M&A due diligence, which is precisely why it becomes a problem. The acquiring organization inherits assets it cannot fully see, cannot fully document, and does not fully understand, and it inherits them all at once.

The core issues are inheritance without visibility, integration under pressure, and heightened attacker attention. You take on a DNS footprint you did not build, you have to integrate it quickly to keep business running, and you do it during a period when the attention of both organizations is elsewhere. Each of these amplifies the others.

The DNS Risks Hidden in an Acquisition

Undocumented Domains and Subdomains

The acquired company almost certainly has domains and subdomains that are not fully documented: defensive registrations, old campaign domains, regional variants, acquired brands from their own past acquisitions, and subdomains created by teams over the years. You are inheriting all of it, including the parts nobody remembers. This is shadow DNS at acquisition scale, and it is often the largest hidden risk in the deal.

Dangling Records and Takeover Exposure

Years of operation leave behind dangling DNS records: subdomains pointing at deprovisioned cloud resources or lapsed third-party services. Each is a subdomain takeover risk, and now it is your risk, under a brand you just paid to acquire. An attacker taking over a subdomain of a newly acquired company can exploit the transition confusion, when it is unclear who is responsible for what, to operate undetected.

Domain Expiration During Transition

Amid the chaos of integration, domain renewals can fall through the cracks. The acquired company's domains may be registered to accounts, email addresses, or payment methods that are being decommissioned as part of the merger. If a critical domain expires because its renewal notice went to an inbox no one monitors anymore, the consequences range from outages to the domain being registered by someone else. We cover this risk in our domain expiration guide.

Email Authentication Disruption

Merging email infrastructure is one of the hardest parts of M&A integration, and DNS is central to it. SPF, DKIM, and DMARC records have to be carefully managed as email systems combine. Mistakes here cause legitimate email to fail authentication and land in spam, or leave domains spoofable during the transition. Getting email authentication wrong during a merger can disrupt business communication at exactly the moment continuity matters most.

Nameserver and Registrar Fragmentation

The two organizations likely use different DNS providers and registrars. You inherit a fragmented setup that needs consolidation, and consolidation is risky: migrating zones, changing nameserver delegations, and transferring domains between registrars are all operations where mistakes cause outages. Doing this across an unfamiliar, undocumented footprint multiplies the risk.

Credential and Access Gaps

Who has access to the acquired company's DNS provider and registrar accounts? During a transition, access may run through people who are leaving, accounts that are being closed, or credentials that are poorly documented. Losing access to a registrar account, or leaving old access open, are both serious risks.

A DNS Governance Framework for M&A

Managing DNS through an acquisition requires treating it as a deliberate workstream, not an afterthought. Here is a structured approach.

1. Discover and Inventory Before You Integrate

Before making any changes, build a complete picture of what you are inheriting. Discover every domain and subdomain the acquired organization has, going beyond their documentation to actively find what exists. Certificate Transparency logs and subdomain discovery surface the undocumented footprint. You cannot govern or secure what you have not found, and the inventory is the foundation for every decision that follows.

2. Assess the Security Posture of What You Inherited

Once you know what exists, evaluate its posture. Identify dangling records and takeover risks as the immediate priority. Check DNSSEC status, email authentication configuration, TLS posture, and any obviously misconfigured or outdated records. This assessment tells you what needs urgent remediation versus what can be addressed during orderly integration.

3. Secure the Registrar and Provider Accounts

Establish control over the acquired organization's DNS and registrar accounts early. Confirm who has access, transfer ownership to appropriate people on the combined team, enable strong authentication, and ensure critical domains are locked against unauthorized transfer. This prevents both loss of access and unauthorized changes during the vulnerable transition period.

4. Protect Against Expiration

Immediately identify the expiration dates and renewal arrangements for all inherited domains. Ensure critical domains will not lapse because their renewal was tied to a decommissioned account or an unmonitored inbox. Independent expiration monitoring, separate from the registrar's own notifications, provides a safety net during the period when accounts and contacts are in flux.

5. Plan Email and Consolidation Carefully

Treat email authentication and DNS consolidation as high-risk operations requiring careful planning. Map out SPF, DKIM, and DMARC changes before making them. Sequence nameserver and registrar migrations deliberately, with appropriate TTL management to enable quick rollback. Do not rush these under integration pressure; a methodical approach prevents the outages that hasty changes cause.

6. Monitor Continuously Through the Transition

The transition period is exactly when you most need visibility. Continuous monitoring across the combined DNS footprint catches unauthorized changes, dangling records, expiration risks, and misconfigurations as they arise, during the window when attention is divided and attackers are most interested. Monitoring turns the chaotic transition period from a blind spot into a watched, controlled process.

The Long Tail: After Integration

DNS governance in M&A does not end when integration is declared complete. The acquired footprint becomes part of your permanent DNS estate, and the domains, subdomains, and records you inherited need ongoing management like everything else. Many organizations find that acquired DNS assets become long-term shadow DNS, technically integrated but never fully understood or actively managed. Establishing continuous monitoring during the acquisition ensures these inherited assets remain visible and governed long after the deal closes, rather than fading into the same obscurity they may have had at the acquired company.

How DNS Assistant Helps

DNS Assistant provides the visibility and continuous monitoring that DNS governance during M&A requires:

Subdomain discovery surfaces the undocumented subdomains of acquired domains, helping you build the complete inventory that integration decisions depend on.
Dangling DNS and subdomain takeover detection across 22+ cloud providers identifies the inherited takeover risks that years of the acquired company's operation left behind.
WHOIS and expiration monitoring tracks the registration status and expiration dates of inherited domains, providing a safety net independent of registrar accounts that may be in transition.
Record and DNSSEC monitoring assesses the posture of what you inherited and detects changes across the combined footprint during the vulnerable integration window.
Multi-tenant architecture with organizations and teams, which is well suited to managing the DNS of multiple entities, useful when integrating two organizations or maintaining separation between acquired brands.
Real-time alerting via email, Slack, Microsoft Teams, webhooks, and SMS.

An acquisition means inheriting DNS risk you did not create and cannot initially see. Establishing discovery and monitoring early in the process turns that inherited unknown into a managed, visible part of your estate, both during the high-risk transition and for the long term after.

Get Started

Whether you are preparing for an acquisition, in the middle of integration, or cleaning up an estate you inherited long ago, start with visibility. Run a Free Domain Risk Report to assess a domain's configuration and posture, or use the DNS lookup tool at dnsassistant.com/tools to inspect specific records.

For continuous discovery and monitoring across your entire DNS estate, including inherited and acquired assets, sign up at dnsassistant.com.

GHOST STADIUM: How 4,300 Fake Domains Targeted the FIFA World Cup 2026

Kishore Bhavnanie — Thu, 25 Jun 2026 16:08:09 +0000

The 2026 FIFA World Cup is the largest sporting event in history: 104 matches across the United States, Canada, and Mexico, more than six million fans expected in stadiums, and a ticket demand so extreme that the first sales window was oversubscribed roughly thirty times over. That combination of massive audience, high prices, and desperate urgency is exactly what fraudsters look for. And months before the opening match, they were ready.

In late May 2026, security researchers at Group-IB published an investigation into a sprawling fraud ecosystem built around the tournament. At its center sits a threat actor they named GHOST STADIUM, running a sophisticated phishing operation across more than 300 domains. But GHOST STADIUM is only one part of a landscape that includes over 4,300 fraudulent domains impersonating FIFA, four independent threat actors, six parallel fraud schemes, and thousands of pre-positioned domains waiting to activate.

What makes this campaign worth studying is not just its scale. It is that nearly every element of it is built on the DNS layer: domain impersonation, typosquatting, shared certificates, and the quiet registration of attack infrastructure long before anyone was watching. This is a case study in why domain and DNS monitoring matters, and what the warning signs look like when you know where to look.

The Scale of the Operation

The numbers from the Group-IB investigation are striking. More than 4,300 domains impersonating FIFA's web presence had been registered since August 2025. Of those, over 300 were confirmed running active fraudulent infrastructure, around 140 were flagged as suspicious, and roughly 3,800 were parked or dormant, pre-positioned for activation as the tournament approached.

That last figure is the one defenders should sit with. Nearly four thousand domains registered and held in reserve, ready to be switched on when traffic peaks during the June 11 to July 19 match window. This is not opportunistic, last-minute fraud. It is infrastructure built methodically, in advance, with the patience of an operation that knows exactly when its targets will be most vulnerable.

The GHOST STADIUM cluster alone spanned more than 300 domains, all tied together by shared technical fingerprints: identical SSL certificates, the same embedded tracking pixel IDs, byte-for-byte identical HTML pages, and a common live-chat property ID reused across dozens of sites. Each of these shared artifacts is a thread that, once pulled, unravels the whole network. That is also precisely how monitoring catches operations like this.

How GHOST STADIUM Worked

GHOST STADIUM built what researchers described as a pixel-perfect clone of the official FIFA website. The phishing kit was a custom single-page application that reproduced the real site so faithfully that the login experience was functionally indistinguishable from the legitimate one.

The most technically notable detail: the kit cloned FIFA's actual single sign-on authentication flow, even reusing the genuine client identifier lifted from the real FIFA SSO provider. When a victim logged in, the fake page captured their credentials, then silently redirected them to the real FIFA authentication page so the experience appeared to be a normal, successful login. The victim often had no idea anything was wrong.

Worse, the phishing flow requested password-reset authorization, meaning the attacker could lock legitimate users out of their own accounts immediately after stealing their credentials. For a fan with real tickets already linked to their FIFA account, this meant the attacker could change the credentials, lock them out, and resell their tickets.

To appear legitimate, the fake pages loaded all their imagery and branding directly from FIFA's official content delivery network. This is a clever evasion: it made the pages visually authentic at zero infrastructure cost, while also helping bypass detection tools that compare image fingerprints of hosted content. The footer carried real links to FIFA's actual social media accounts. Everything was engineered to build trust.

The DNS Fingerprints That Tied It Together

Here is where the campaign becomes a DNS and domain-monitoring story rather than just a phishing story. Despite spanning hundreds of domains, the GHOST STADIUM operation was bound together by infrastructure signals that monitoring is designed to surface.

Shared SSL certificates. The same certificates appeared across the cluster, cryptographically linking domains that otherwise looked independent. Certificate Transparency logs, which publicly record every certificate issued, are a powerful way to discover this kind of connected infrastructure. When a wave of certificates is issued for lookalike domains of a brand, that is a signal worth catching.

Reused tracking and chat IDs. Three advertising pixel IDs and a single live-chat property ID were embedded identically across the 300+ domains, tying them all to the same operator. One detection became the thread that revealed the entire network.

Typosquatting clusters. Analysis of the domain indicators revealed tight typosquatting groups, families of domains like fifa-com followed by a rotating set of TLDs (fifa-com.site, fifa-com.co, fifa-com.com, fifa-com.store, fifa-com.vip, fifa-com.website, fifa-com.xyz), bulk-registered together. The pattern of one brand string permuted across many TLDs is a classic impersonation fingerprint. We explored a related dynamic in our coverage of domain impersonation and lookalike registration.

Long pre-positioning windows. Some domains had been quietly held for a very long time before being weaponized. One domain in the indicator set was registered well over two years before it was reported as part of the campaign. This is the dormant-infrastructure pattern: register early, sit quiet, activate when it counts. Only continuous monitoring catches the moment a long-dormant lookalike domain suddenly comes alive.

It Was Not Just One Attacker

One of the more sobering findings is that GHOST STADIUM was not operating alone. The investigation identified four independent threat actors exploiting the same event in parallel, not a single coordinated group, but a convergence of separate operators all drawn to the same target.

Alongside GHOST STADIUM's credential phishing and fake ticket sales, researchers documented a bulk domain squatter pre-positioning typosquat domains, mass infostealer campaigns harvesting FIFA credentials as incidental collateral (with roughly 2,500 FIFA credential pairs already circulating in dark-web markets), and an underground Phishing-as-a-Service supply chain selling ready-made fraud kits to anyone willing to pay.

That last actor matters most for the long term. A Phishing-as-a-Service supply chain means taking down one operator does not end the threat. The same kit gets redeployed by new entrants who simply bought it. The barrier to entry collapses, and the fraud surface keeps expanding. This is the industrialization of brand-impersonation fraud, and it is why defense has to focus on infrastructure patterns rather than individual takedowns.

Six Fraud Schemes, One Event

The broader ecosystem ran six distinct fraud schemes simultaneously, each targeting football fans in a different way:

Credential phishing through the cloned FIFA single sign-on, capturing account logins and session data.
Fake ticket sales targeting premium and hospitality tiers priced from $1,500 to over $10,000, with estimated losses for that tier alone reaching into the hundreds of millions.
Counterfeit merchandise storefronts selling fake branded gear, localized heavily for Latin American markets, harvesting card and shipping data in the process.
Fake streaming platforms promising free or premium match streams, charging subscription fees and in some cases delivering malware instead of content.
Fraudulent betting and casino sites misusing FIFA branding to appear authorized, stealing deposits and harvesting identity-verification documents for later fraud.
Infostealer-driven credential theft from mass malware campaigns that swept up FIFA credentials alongside everything else on infected machines.

Every one of these schemes needed domains to operate. Every domain needed DNS. The fraud was diverse, but its foundation was uniform: impersonation infrastructure built on the domain name system.

How Fraud Reached Victims

The campaign drove traffic through multiple channels, and a few are worth noting because they show why brand monitoring has to extend beyond your own perimeter.

Paid social media advertising was the primary engine. The operators bought ads that pushed phishing pages directly to targeted users, using classic urgency tactics: prices dramatically lower than official tickets, countdown timers, and "first come, first served" pressure messaging. Search engines were also abused, with fraudulent domains impersonating FIFA's name and favicon, copying content to rank organically in search results for FIFA-related queries. Some victims never saw an ad at all; they simply searched and clicked what looked like an official result.

There were also dedicated redirector domains, a set of football-themed domains sharing a single origin IP and a common registration date, that funneled victims toward the fraudulent sites. Redirectors like these act as resilient entry points: even if a primary phishing domain is taken down, the redirector can be quietly pointed at a replacement. From a monitoring standpoint, several domains sharing one IP and one registration date is itself a strong infrastructure signal.

What Organizations Should Learn From This

GHOST STADIUM targeted FIFA, but the playbook applies to any recognizable brand, especially around a major event, product launch, sale, or moment of heightened public attention. The lessons generalize.

Impersonation infrastructure is built early. The 3,800 parked domains and the multi-year pre-positioning windows show that attackers register their infrastructure long before they use it. Monitoring for lookalike domain registrations gives you warning during that quiet window, not after the damage is done.

Certificate Transparency is an early-warning system. When attackers stand up hundreds of phishing domains, they need TLS certificates, and those certificates land in public CT logs. Watching CT logs for certificates issued against lookalikes of your brand can surface an impersonation campaign as it is being built.

Shared infrastructure is the unraveling point. The whole GHOST STADIUM network was tied together by reused certificates, pixel IDs, and IPs. Defenders who map infrastructure relationships, rather than chasing one domain at a time, can identify an entire campaign from a single detection.

Typosquatting follows predictable patterns. One brand string permuted across many TLDs and small misspellings is the signature of organized impersonation. These patterns are detectable precisely because they are systematic.

Takedown alone is not enough. With a Phishing-as-a-Service supply chain feeding new operators and thousands of domains in reserve, individual takedowns are necessary but insufficient. Continuous monitoring across your brand's domain footprint is what keeps pace with an adversary operating at this scale.

How DNS Assistant Helps

The GHOST STADIUM campaign is a reminder of how much attacker activity happens at the DNS and domain layer. Defending against an external impersonation ecosystem this large draws on several disciplines, including brand-focused domain discovery services that hunt for lookalikes across the namespace. DNS Assistant's role is the complementary one: keeping continuous watch over the domains you own and track, so the integrity of your own DNS, certificates, and registration details is never the thing that fails you. Here is where it fits:

WHOIS monitoring tracks the registration details of the domains you monitor, including registrar, nameserver, and status changes, so unauthorized or unexpected modifications to your own domains are caught as they happen.
Subdomain discovery uses Certificate Transparency logs to find subdomains of the domains you monitor, helping you maintain an accurate inventory of your own footprint and catch forgotten or dangling subdomains.
DNS record monitoring detects when the records on domains you monitor change or when a dormant domain you track begins resolving to live infrastructure, catching the moment a configuration shifts.
Continuous visibility across your domain footprint, with real-time alerting via email, Slack, Microsoft Teams, webhooks, and SMS, so a change is caught when it happens rather than after victims report it.

The defining feature of this campaign was time: attackers built their infrastructure months ahead and waited. That same window is the defender's opportunity. Continuous monitoring of your domain and DNS posture turns that lead time from the attacker's advantage into yours.

Check Your Domain Posture

Start by understanding your own domain footprint. Use the DNS lookup tool at dnsassistant.com/tools to inspect your records, or run a Free Domain Risk Report for a comprehensive view of your DNS configuration, certificates, and email authentication.

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

This analysis is based on original research published by Group-IB in May 2026. The campaign details, threat actor attribution, and scale figures are drawn from their published investigation. This article examines the campaign through a DNS and domain-monitoring lens for defensive and educational purposes. If you believe you have encountered a fraudulent FIFA ticketing site, purchase tickets only through the official FIFA portal, and never trust ticket offers requiring cryptocurrency payment.

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.