DEV Community: Kishore Bhavnanie

Building DNS Runbooks and On-Call Playbooks

Kishore Bhavnanie — Mon, 03 Aug 2026 17:14:51 +0000

It is 2 a.m. Alerts are firing. Something is wrong with DNS, and the person on call, who may not be your DNS expert, has to figure out what is happening and what to do about it, quickly, under pressure, half awake. This is exactly the moment when tribal knowledge fails and improvisation causes second outages. It is also the moment a good runbook earns back every minute spent writing it.

DNS incidents are particularly unforgiving because DNS sits beneath everything else. A mistake made while responding, a wrong record, a hasty change with a long TTL, can extend an outage for hours after the original problem is fixed. Runbooks and on-call playbooks turn a high-pressure judgment call into a checklist, so the responder follows a known-good path instead of guessing.

This guide covers what makes a DNS runbook effective, then provides adaptable playbook structures for the most common DNS incidents. Treat these as starting templates to fill in with your own environment's specifics.

What Makes a DNS Runbook Actually Useful

A runbook that gets used at 2 a.m. has a few properties that a document written to tick a compliance box does not.

It assumes the reader is not the expert. The person on call may know little about DNS. Good runbooks spell out commands, name the systems to check, and avoid assuming context. If a step says "verify the record," it also says how and where.

It leads with triage, not theory. The first section should help the responder confirm what is happening and gauge severity, before any fix. Wrong diagnosis leads to wrong action.

It names people and places. Who owns DNS. Which registrar and DNS provider. Where credentials live. Who to escalate to and how to reach them. Generic advice is useless without these specifics filled in.

It includes rollback. Every action that changes something should say how to undo it. Under pressure, the ability to revert cleanly is worth more than the ability to fix perfectly.

It is tested. A runbook nobody has walked through is a guess. Tabletop the common scenarios so the gaps surface in calm conditions, not during an incident.

A Standard Runbook Structure

A consistent template makes every playbook faster to follow because responders know where to look. A workable structure:

INCIDENT: [name of the scenario]
SEVERITY: [how to judge how bad this is]

1. DETECT & CONFIRM
   - What signals indicate this incident
   - Commands / tools to confirm it is real

2. ASSESS IMPACT
   - What is affected, how widely
   - How to gauge scope

3. CONTAIN / MITIGATE
   - Immediate steps to stop the bleeding
   - What NOT to do

4. RESOLVE
   - Steps to fix the root cause
   - Rollback for each change

5. VERIFY
   - How to confirm recovery
   - Accounting for propagation / TTL

6. ESCALATE
   - When to escalate and to whom
   - Contact details

7. POST-INCIDENT
   - What to record, review, and follow up

The playbooks below follow this shape. Fill the bracketed specifics with your own environment.

Playbook 1: Suspected DNS Hijacking or Unauthorized Change

Detect and confirm. Triggered by an alert on a record or nameserver change nobody authorized, or reports of traffic going to the wrong place. Confirm by checking the current records against your known-good baseline and comparing what authoritative nameservers return. Verify whether the change is at the record level or the nameserver level, since that determines everything downstream.

Assess impact. Identify which records changed and what they affect, web, email, or other services. A changed MX or nameserver is higher severity than a single peripheral record.

Contain. If this looks like a registrar account compromise (nameserver change, unexpected transfer notice), treat it as one: begin the registrar account takeover response, secure the account and its associated email, and contact the registrar urgently. Do not simply revert the record and move on if the account itself may be compromised, or the attacker will change it back.

Resolve and verify. Restore records from your baseline. Because propagation and caching mean changes are not instant, account for TTL when judging recovery, and consider that a long TTL on the malicious record may keep serving it to some resolvers for a while. Detecting and reacting to the broader pattern is covered in our guide to detecting DNS hijacking.

Playbook 2: DNSSEC Validation Failure

Detect and confirm. Triggered by reports that a domain is unreachable for some users but fine for others, a classic DNSSEC-failure signature, or by a validation alert. Confirm by checking DNSSEC validation status and whether the chain of trust is intact.

Assess impact. A DNSSEC failure can make a domain unreachable for everyone using validating resolvers, which is a large and growing share. Treat it as high severity by default.

Contain and resolve. Identify the cause, commonly an expired signature, a key rollover that went wrong, or a mismatch between the DS record at the parent and the keys in the zone. The fix depends on the cause: correct the DS record, complete or roll back the key change, or re-sign as needed. This is a place where a wrong move makes things worse, so follow the specific sub-steps for your provider carefully. The mechanics are explained in our DNSSEC guide.

Verify. Confirm validation succeeds from an external validating resolver, not just your own, and account for TTL on the affected records.

Playbook 3: Propagation or Stale-Record Issues

Detect and confirm. Triggered by "the change I made is not showing up" or inconsistent behavior across regions. Confirm by querying multiple resolvers and comparing answers, and by checking the authoritative record against what resolvers are returning.

Assess. Determine whether this is normal propagation delay (expected, driven by TTL) or a genuine problem such as a record set incorrectly or a secondary that has not updated. Most propagation "incidents" are simply TTL playing out and need patience, not action.

Resolve. If it is a real error, correct the record. If it is propagation, the fix is usually to wait out the TTL, and the lesson for next time is to lower TTLs before planned changes, per our TTL best practices. Resist the urge to make more changes, which often compounds confusion.

Playbook 4: Domain or Certificate Expiry Emergency

Detect and confirm. Triggered by a domain that has stopped resolving, or an expiry alert. Confirm the registration status and expiration date.

Contain and resolve. For an expired domain, renew immediately through the registrar; most offer a grace period, but act fast because that window is finite and the alternative is losing the domain. For a related certificate expiry, reissue and deploy the certificate. The broader prevention is tracked expiration monitoring, which we cover in domain expiration as a silent risk.

Post-incident. An expiry emergency is nearly always a monitoring and contact-hygiene failure. The follow-up is to ensure renewal notices reach a monitored inbox and expirations are tracked independently.

Wiring Detection Into the Runbooks

Every playbook above starts with "detect and confirm," and a runbook is only as good as the alert that triggers it. If the first anyone hears of a DNS hijack or a DNSSEC failure is a customer complaint, the runbook starts late. Continuous monitoring is what fires the initial signal that sends the on-call person to the right playbook in the first place.

This is where DNS Assistant fits into your incident process. It watches for the conditions these playbooks respond to, unauthorized record and nameserver changes, DNSSEC problems, approaching expirations, WHOIS changes, and alerts in real time across email, Slack, Microsoft Teams, SMS, and webhooks. Routed into your on-call channel, those alerts become the trigger that starts the right runbook early. DNS Assistant does not execute the runbook or make changes for you; it provides the early, specific detection that makes a calm, on-time response possible instead of a scramble that begins only once damage is visible.

Start Building

Before an incident, it helps to know your current baseline, what your records, DNSSEC status, and registration details look like when everything is healthy. Capture that with the free DNS lookup tool or a Free Domain Risk Report, so your runbooks have a known-good state to compare against.

To get the real-time alerts that trigger these playbooks early, start free at dnsassistant.com.

SVCB and HTTPS Records: A Practical Adoption Guide

Kishore Bhavnanie — Thu, 30 Jul 2026 11:22:54 +0000

For most of DNS history, pointing a client at a service meant a simple chain: an A or AAAA record gave an address, and everything else, which port, which protocol, whether encryption was available, was either assumed, hardcoded, or discovered through extra round trips. Two newer record types, SVCB and HTTPS, change that. They let a domain publish how a service should be reached, not just where, in a single DNS lookup. The result is faster connections, cleaner configuration, and a foundation for privacy features that were previously awkward to deliver.

These records are still unfamiliar to many teams, partly because they arrived recently and partly because their parameter syntax looks more intimidating than it is. This guide explains what SVCB and HTTPS records are, shows what they actually look like, walks through how to add one, and covers what to watch for when monitoring them.

What SVCB and HTTPS Records Are

SVCB, short for Service Binding, is a general-purpose DNS record type for describing how to connect to a service. HTTPS is a specialized form of SVCB built specifically for web services, and it carries DNS record type number 65. They are close siblings: HTTPS is essentially SVCB with web conventions baked in, which is why they are almost always discussed together and share the same structure.

Both records have three parts, in this order: a priority, a target name, and an optional set of service parameters (called SvcParams). A minimal HTTPS record in standard zone-file format looks like this:

example.com.   3600   IN   HTTPS   1   .   alpn="h3,h2"   ipv4hint=203.0.113.1

Reading that left to right: the owner name (example.com.), the TTL (3600), the class and type (IN HTTPS), then the three parts, priority 1, target . (a dot meaning "the same name as the owner"), and two service parameters. The alpn parameter advertises that the service supports HTTP/3 and HTTP/2, and ipv4hint supplies an address so the client can skip a separate A lookup.

The Two Modes: Alias and Service

The priority value determines which of two modes the record is in, and this is the most important concept to grasp.

AliasMode (priority 0) makes the record behave like a CNAME, redirecting resolution to another name, but with one crucial advantage: unlike CNAME, it is allowed at the zone apex (the bare domain). This finally solves the long-standing problem of pointing a bare domain at a provider. It looks like this:

example.com.   3600   IN   HTTPS   0   cdn.provider.net.

Here priority 0 signals AliasMode, and the target cdn.provider.net. is where resolution is delegated. No service parameters are used in this mode.

ServiceMode (priority greater than 0) describes an actual endpoint and its connection parameters. You can publish multiple ServiceMode records, and clients prefer the lowest priority number first, which lets you express primary and backup endpoints:

example.com.   3600   IN   HTTPS   1   .                    alpn="h3,h2"   ipv4hint=192.0.2.1
example.com.   3600   IN   HTTPS   2   backup.example.net.   alpn="h2"

A client tries priority 1 first, falling back to the backup endpoint at priority 2 if needed.

The Service Parameters Worth Knowing

The SvcParams are where the useful configuration lives. The ones you will encounter most:

alpn: the application protocols the endpoint supports, such as h3 (HTTP/3) and h2 (HTTP/2). This lets a client skip protocol negotiation and connect using the best available protocol immediately.
port: an alternative port, if the service does not use the default.
ipv4hint and ipv6hint: address hints that let a client avoid a separate A or AAAA lookup, saving a round trip.
ech: Encrypted ClientHello configuration, which supports encrypting the server name during the TLS handshake. This is one of the privacy features these records were designed to enable.
mandatory: marks other parameters that a client must understand, or else ignore the record.

One syntax rule that catches people out: service parameters must appear in ascending order by their key number, not in an arbitrary order. The key numbers include mandatory=0, alpn=1, port=3, ipv4hint=4, and ipv6hint=6. Ordering strictly by that numeric key value keeps the record valid:

; CORRECT: ascending by key number (alpn=1, ipv4hint=4, port=3 would be wrong order)
example.com.   IN   HTTPS   1   .   alpn="h3"   port=443   ipv4hint=203.0.113.1

; WRONG: keys out of numeric order, may cause parse errors
example.com.   IN   HTTPS   1   .   ipv4hint=203.0.113.1   alpn="h3"

Most provider editors sort the parameters for you, which is one good reason to use them rather than hand-authoring raw records.

How to Add One

There are two realistic paths, and for most teams the first is both easier and safer.

Through your DNS provider, which most now support. Cloudflare, AWS Route 53, Google Cloud DNS, Akamai, and others support SVCB and HTTPS records. In a typical provider UI the steps are:

Open your domain's DNS management page and choose to add a record.
Select HTTPS (or SVCB) from the record type list.
For the name, leave it blank or use @ for the zone apex on the standard HTTPS port.
Set the priority: 0 for AliasMode, or 1 (or higher) for ServiceMode.
Set the target: the alias target for AliasMode, or . to mean the owner name itself in ServiceMode.
Add the service parameters (alpn, ipv4hint, and so on) in the parameter fields. A good editor validates these and previews the result as you type.

Through infrastructure-as-code, if you manage DNS that way. Tools such as DNSControl express the same record compactly, for example an apex HTTPS record advertising HTTP/3 and HTTP/2 with an address hint on port 443. The three parts, priority, target, and parameters, map directly onto whatever your tool's syntax is.

Whichever path you use, keep your existing A and AAAA records in place. Which brings us to the reassuring part of adoption.

Adoption Is Additive and Low-Risk

SVCB and HTTPS records are designed to be backward compatible. You do not remove your address records to adopt them. Clients that understand the new records use them; clients that do not simply fall back to the A and AAAA records they already know. Nothing is taken away from older clients, so the risk of adoption is low.

The main caution is correctness. Because a malformed record can be ignored or, worse, cause SVCB-aware clients to attempt connections that fail, test before rolling out widely, and use a low TTL during initial deployment so you can correct mistakes quickly. This is a good moment to apply the general principles in our guide to DNS TTL best practices. One DNSSEC interaction is worth knowing: for a signed zone, an invalid record is not silently skipped the way it might be otherwise, so getting the syntax right matters more when DNSSEC is in play.

Monitoring Considerations

Once these records are live, they become part of your DNS surface that deserves the same attention as any other record.

Track changes to them. An HTTPS or SVCB record that changes unexpectedly matters for the same reason any record change does: it affects how clients reach your service, and an unexpected change can indicate a misconfiguration or tampering. Change monitoring should cover these record types, not only the traditional ones.

Validate that published records are well-formed. Because these records influence connection behavior, a malformed or stale record can degrade performance or cause failures for clients that honor it. Confirming records are valid and current is worth building into your review process.

Keep them consistent with your other configuration. HTTPS records can carry information that overlaps with your TLS and CDN setup. Keeping them aligned avoids the situation where DNS advertises one thing and the service delivers another.

Where This Sits in the Bigger Picture

SVCB and HTTPS records are part of a broader trend of DNS taking on a richer role, carrying not just addresses but service and security parameters. That expanded role is exactly why keeping DNS continuously monitored matters more than it used to, a theme at the center of DNS posture management. As DNS carries more meaning, more can go wrong in it quietly.

DNS Assistant treats these newer record types as part of the DNS surface it monitors: it detects changes across record types and surfaces them in real time, so a change to an HTTPS or SVCB record is visible the same way any other record change would be. That is the accurate scope here: these records are one more part of the configuration worth keeping under continuous watch, alongside the dangling-record, email-authentication, and DNSSEC checks that make up a fuller posture picture.

Getting Started

To see what records a domain currently publishes, including whether HTTPS records are already present, inspect it with the free DNS lookup tool or a Free Domain Risk Report.

To keep your full set of DNS records, newer types included, continuously monitored for change, start free at dnsassistant.com.

DNS Inventory as a Living Asset: Building a Complete Domain Catalog

Kishore Bhavnanie — Wed, 29 Jul 2026 12:52:27 +0000

Ask most organizations for a complete list of the domains and subdomains they own, and you will get a spreadsheet that is confidently wrong. It will be missing the campaign subdomain marketing spun up last year, the staging environment a developer created and forgot, the domain acquired through a company you bought, and the third-party service someone connected with a CNAME that no longer resolves anywhere useful. The list describes what the organization thinks it owns. Reality is larger, messier, and changing constantly.

This gap is not a documentation failure to be fixed once. It is a structural condition of how DNS gets used. Domains and subdomains are created by many people, through many tools, for many reasons, and almost never deliberately retired. Treating your DNS inventory as a static list you compile occasionally guarantees it will be out of date within weeks. The alternative is to treat it as a living asset: continuously discovered, continuously reconciled, and owned.

This guide covers why DNS inventory drifts, what a complete catalog actually includes, and how to build and maintain one that reflects reality rather than intention.

Why Your Inventory Is Always Incomplete

The reasons an inventory drifts out of date are worth naming, because each points to a category of asset that manual documentation tends to miss.

Decentralized creation. DNS records get created by whoever needs one: developers, marketers, IT, external agencies, SaaS onboarding flows. Each addition is reasonable in isolation, and almost none of them update a central record. This is the root of the shadow DNS problem, assets that exist and resolve but were never centrally tracked.

Acquisitions and reorganizations. When one company absorbs another, it inherits a domain portfolio that is often poorly documented and sometimes actively unknown. These inherited assets are frequently the least monitored and the most likely to contain forgotten exposures, a risk we explore in the context of DNS governance during mergers and acquisitions.

Abandonment without removal. Projects end and services are decommissioned, but the DNS records pointing at them usually remain. The record outlives the thing it pointed to, which is exactly how dangling records and takeover exposure accumulate.

Defensive and parked domains. Organizations register variants, misspellings, and regional versions defensively, then lose track of them. They are owned, they are rarely monitored, and they still carry the organization's name.

What a Complete Catalog Actually Contains

A living inventory is broader than a list of primary domains. To be useful for security and operations, it needs to capture several layers.

All registered domains, including defensive registrations, regional and country-code variants, and brand-protection domains that redirect or sit parked.
All subdomains, including the transient ones created for campaigns, testing, and one-off integrations, which are the hardest to enumerate and the most likely to be forgotten.
The records under each, and where they point, so that third-party dependencies (CNAMEs to SaaS platforms, delegations to external nameservers) are visible as the dependencies they are.
Ownership, a named person or team responsible for each domain and subdomain, so that anything unowned can be questioned.
Provider and account, which registrar and DNS provider each domain lives with, since portfolios spread across multiple providers are common and easy to lose track of.

An inventory that captures only the first layer, the primary domains everyone already knows about, misses precisely the assets where risk concentrates.

How to Discover What You Actually Own

Building the catalog means discovering assets rather than transcribing what you already believe. Several complementary techniques get you there.

Start from your registrar and DNS provider accounts. Pull the authoritative list of registered domains from every registrar you use. This is the reliable core, though it only covers domains, not subdomains, and only the providers you remember to check.

Enumerate subdomains actively. Certificate Transparency logs are a powerful source here: every publicly trusted certificate issued for your domains is logged, which surfaces subdomains that were never documented. Combined with other discovery methods, this reveals the subdomain footprint your documentation does not have.

Cross-reference with the teams that create records. Marketing, development, and any group that stands up services will each know about assets central IT does not. A periodic reconciliation with them surfaces the human knowledge that no automated scan captures.

Reconcile and assign ownership. Every discovered asset should be matched to an owner. Anything that cannot be explained or owned is a finding: a candidate for removal, or at least for investigation.

Why It Has to Be Continuous

The single most important shift is from inventory-as-event to inventory-as-process. A catalog built in a one-time project is accurate on the day it is finished and decaying by the next. New subdomains appear, services are decommissioned, domains approach expiry, and records change, continuously.

A living inventory is one that updates itself: continuously discovering new subdomains as they appear, flagging records that have gone dangling, tracking approaching expirations, and surfacing changes as they happen. The human work shifts from compiling the list to reviewing what the continuous process surfaces, which is a far smaller and more sustainable task. This is the same principle that turns a quarterly audit from a scramble into a review, which we cover in our quarterly DNS audit checklist.

The Inventory Is the Foundation for Everything Else

A complete, current DNS inventory is not an end in itself. It is the prerequisite for every other DNS security and governance activity. You cannot detect subdomain takeover on subdomains you have not discovered. You cannot assess email authentication on domains you do not know you own. You cannot produce compliance evidence for an estate you cannot fully enumerate. Inventory is the base layer of DNS posture management, and its completeness sets the ceiling on how good everything above it can be.

How DNS Assistant Helps

Maintaining a living inventory by hand is the part that defeats most teams, and it is precisely where continuous tooling earns its place. DNS Assistant builds and maintains this catalog as an ongoing process rather than a manual exercise:

Subdomain discovery surfaces the subdomains your documentation lacks, including forgotten and transient ones, using Certificate Transparency and other discovery methods.
Continuous monitoring keeps the catalog current as new subdomains appear and records change, rather than letting it decay after an initial scan.
Dangling record detection across 22+ cloud providers flags the abandoned-but-not-removed records that inventory drift produces.
WHOIS and expiration tracking keeps registration and expiry visible across your portfolio.
A viewable change history and data export in CSV, Excel, or PDF turn the living inventory into something you can review and hand to an auditor.
Multi-tenant, role-based access suits organizations and agencies maintaining inventories across many entities.

The catalog stays current because the discovery and monitoring are continuous; the ownership decisions and cleanup remain yours to make.

Build Your Catalog

You can start by inspecting a domain you already know about with the free DNS lookup tool or a Free Domain Risk Report. For the discovery that turns a partial list into a living inventory, finding the subdomains and dangling records you do not yet know about, start free at dnsassistant.com.

Hotel Wi-Fi DNS Poisoning: How APT28-Style Tradecraft Steals Microsoft 365 Logins

Kishore Bhavnanie — Mon, 27 Jul 2026 12:31:35 +0000

A traveling employee checks into a hotel, connects to the guest Wi-Fi, and opens their laptop to catch up on email. Microsoft 365 asks them to sign in again, nothing unusual about that. They enter their credentials. Except the login page was never Microsoft's, and the network they trusted quietly sent them somewhere else. No phishing email arrived. No malicious attachment was opened. Their device was never touched. The compromise happened entirely in the space between their laptop and the internet, at the hotel's Wi-Fi gateway.

In July 2026, the ReliaQuest Threat Research team documented exactly this campaign: attackers compromising public Wi-Fi gateways at hotels and conference centers to poison DNS and harvest Microsoft 365 credentials from traveling corporate employees. It is a clear illustration of a principle worth understanding, that whoever controls DNS controls where your traffic goes, and it is worth walking through how the attack works and why several common defenses do not stop it.

This analysis is based on the original research published by ReliaQuest. The campaign details, attribution, and indicators are drawn from their report.

The Attack in Brief

According to ReliaQuest, adversaries have been compromising the captive-portal appliances that run guest Wi-Fi at hotels and similar venues, and using that control to redirect users to attacker infrastructure. The activity has been ongoing since at least June 2026, with compromised gateways identified across multiple US cities and internationally in India and Saudi Arabia.

ReliaQuest assesses the tradecraft as similar to APT28 (also known as Fancy Bear or Forest Blizzard), a Russian military intelligence group previously linked to a comparable router-based campaign. They are careful to note this is a similarity in tactics rather than a direct attribution, the assessment rests on overlapping techniques rather than shared infrastructure or code.

Notably, the targeting was not sector-specific. ReliaQuest observed traffic to the compromised gateways from organizations across financial services, professional services, legal, healthcare, energy, and retail, consistent with a campaign that goes after traveling employees wherever they connect, rather than any single industry.

How the Attack Works

Step 1: Compromise the Gateway

The attack begins with the attacker gaining administrative access to an internet-facing Wi-Fi gateway. ReliaQuest assesses with low-to-medium confidence that initial access came through exposed management interfaces, internet-facing SSH, SNMP, or web administration consoles, combined with weak or reused administrative credentials.

The significance of this device class is the environment it controls. A captive-portal appliance sits at the network perimeter for every guest on that network. Compromising one does not compromise one victim; it positions the attacker to redirect traffic for everyone who connects that day, without touching a single endpoint.

Step 2: Poison DNS for Every Client

Once in control of the gateway, the attacker controls DNS resolution for every device that joins the network. This works because of a trust assumption built into how networks function: when your device joins a network, it accepts that network's DNS resolver and trusts the answers it returns. DNS translates a name like the Microsoft login domain into an IP address, and whoever answers those queries decides where you actually go.

Because the compromised gateway is the resolver handed to every connecting client, queries for legitimate domains can be silently answered with attacker-controlled IP addresses. In the cases ReliaQuest investigated, forged responses redirected users to Microsoft-impersonating pages. This is DNS poisoning at the gateway level, and it is conceptually related to the broader class of attacks we cover in our explainer on DNS cache poisoning.

Step 3: Harvest Credentials and Tokens

The attackers registered four lookalike domains impersonating Microsoft: m365-owa, owa-ms365, ms365-device, and ms365-live (each a .com). ReliaQuest assesses with high confidence these were operated by a single actor, based on shared registration details and their appearance together within single browsing sessions.

ReliaQuest also observed the redirect paired with abuse of Microsoft's device-code authentication flow, a path to account compromise that does not require intercepting a password at all. In that flow, approving what looks like a routine sign-in prompt can authorize a session the attacker initiated, causing Microsoft to issue valid, MFA-satisfied OAuth tokens to the attacker. The lesson is sobering: multi-factor authentication does not help if the user is tricked into authorizing the attacker's own session.

Why Common DNS Protections Do Not Stop This

The most counterintuitive part of ReliaQuest's findings is that several defenses people assume would protect them do not. This is worth understanding, because it corrects a widespread misconception.

Hard-coding a public resolver does not help. Setting your device to use a public DNS server such as Google's does not protect you here. The request still leaves your device as unencrypted traffic that the gateway can read, forge, and redirect before it ever reaches that resolver.

Opportunistic encrypted DNS does not help. Many DNS-encryption tools default to opportunistic mode, which allows plaintext fallback when encrypted resolution fails. A malicious gateway can force that fallback and then redirect the plaintext request. Only strict-mode encrypted DNS, where plaintext fallback is disabled, closes the gap.

ReliaQuest identifies two configurations that do stop the attack: an always-on, full-tunnel VPN that routes all DNS through the corporate network before the gateway can touch it, and strict-mode encrypted DNS (DNS over HTTPS or DNS over TLS with fallback disabled). The distinction between opportunistic and strict mode is exactly the kind of detail that matters, and we cover these protocols in our guide to DoH versus DoT.

Defending Against Gateway DNS Poisoning

ReliaQuest's recommendations center on preventing poisoned DNS from reaching endpoints in the first place. In summary:

Enforce always-on, full-tunnel VPN on corporate devices, so all DNS routes through trusted corporate resolvers before reaching any public gateway. Eliminate split-tunneling exceptions that would let DNS bypass the tunnel.
Use strict-mode encrypted DNS where a VPN is not in play, ensuring a gateway cannot forge responses through plaintext fallback.
Disable Web Proxy Auto-Discovery (WPAD) where it is not required, since ReliaQuest observed WPAD abuse as a secondary redirection channel in roughly a third of cases.
Block the device-code authentication flow at the identity provider for users who do not need it, removing the token-theft path the campaign depended on.
Train employees to verify the URL and certificate of any page requesting credentials, especially on hotel, airport, and conference Wi-Fi.

The through-line is that this is primarily an endpoint and network-configuration problem for the traveling user, solved with VPN, strict encrypted DNS, and identity-provider hardening. For the full technical detail, indicators of compromise, and detection guidance, read ReliaQuest's original report.

The Broader Lesson: DNS Trust Is Assumed Everywhere

What makes this campaign instructive is not any single technique but the assumption it exploits. Every device that joins a network trusts that network to resolve DNS honestly. That trust is almost never verified, which is precisely why controlling DNS is such a powerful position for an attacker, whether at a hotel gateway, a home router, or anywhere else in the resolution path.

The same principle applies on the other side of DNS, to the domains an organization owns. Just as a traveling user cannot assume a network resolves DNS honestly, an organization cannot assume its own DNS records, delegations, and configurations remain correct and untampered without checking. That is the idea behind applying Zero Trust principles to DNS: never assume, always verify.

It is worth being clear about scope. This particular attack happens on the client-resolution side, at a network the victim does not control, and the defenses are endpoint and network controls rather than domain monitoring. DNS Assistant operates on a different part of the DNS picture, continuously verifying the security posture of the domains you own, so their records, email authentication, and configuration stay correct and any change is surfaced quickly. Different layer, same underlying lesson: DNS is too important to leave on unverified trust.

Assess Your Own DNS Posture

While the defenses against gateway poisoning are endpoint-side, keeping your own domains verified is its own discipline. Inspect a domain's records, DNSSEC status, email authentication, and TLS posture with the free DNS lookup tool or a Free Domain Risk Report.

For continuous monitoring of the domains you own, start free at dnsassistant.com.

This analysis is based on original research published by the ReliaQuest Threat Research team in July 2026. The campaign details, attribution assessments, indicators of compromise, and defensive recommendations are drawn from their published report, linked above. This article summarizes and contextualizes that research for educational purposes. If you may be affected, consult ReliaQuest's original report for the full indicators of compromise and detection guidance.

Preparing Your DNS for NIS2 and DORA

Kishore Bhavnanie — Fri, 24 Jul 2026 13:05:57 +0000

Two European regulations have changed what organizations are expected to prove about their security. NIS2 broadens the scope of cybersecurity obligations across a wide range of sectors and supply chains. DORA sets operational resilience requirements for financial entities and the technology providers they depend on. Both share a common theme: it is no longer enough to have security controls. You have to be able to evidence that they work, continuously, and to report when they fail.

DNS sits awkwardly inside these requirements. It is rarely named explicitly, which leads many teams to assume it falls outside scope. In practice, DNS underpins several things both regulations care about a great deal: asset inventory, supply chain dependencies, incident detection, and service continuity. If your DNS is unmonitored, you have a gap in exactly the areas an assessor will probe.

This article covers what NIS2 and DORA expect in general terms, where DNS intersects those expectations, and how to prepare. It is a practical guide rather than a legal one, and the note at the end explains why you should treat it that way.

What the Two Regulations Are Asking For

The two frameworks differ in scope and detail, but for the purposes of DNS preparation their demands converge.

NIS2 extends EU cybersecurity requirements to a far wider set of sectors than its predecessor, and places significant emphasis on risk management, supply chain security, and incident reporting. A recurring theme is accountability: organizations are expected to understand their own attack surface, manage the risk introduced by third parties, and detect and report significant incidents within tight timeframes.

DORA focuses on digital operational resilience in the financial sector, covering financial entities and critical technology providers serving them. Its emphasis falls on ICT risk management, third party dependency management, incident classification and reporting, and the ability to keep operating through disruption.

Strip both back and four expectations emerge that DNS touches directly:

Know your assets. You cannot manage risk on infrastructure you have not inventoried.
Manage third party dependency. Understand and monitor what you rely on outside your own perimeter.
Detect and report incidents. Identify problems quickly enough to meet reporting timeframes.
Maintain continuity. Keep critical services available and recover when they fail.

Where DNS Intersects Each Expectation

Asset Inventory Includes Your Domains

Every domain and subdomain you own is an internet facing asset. Most organizations cannot produce a complete list of theirs, because subdomains accumulate through marketing campaigns, development environments, retired SaaS tools, and acquisitions. That gap is the shadow DNS problem, and under a regime that expects you to understand your attack surface, an incomplete inventory is a finding waiting to happen.

Preparation means moving from a documented list of what you think you own to an actively discovered picture of what actually exists and resolves.

DNS Is a Supply Chain Surface

Supply chain risk is central to NIS2 and to DORA's third party provisions, and DNS is where a surprising amount of that dependency lives. Every CNAME pointing at a SaaS platform, every delegation to an external nameserver, every record aimed at a cloud provider is a third party dependency expressed in DNS.

When one of those services is decommissioned and the record remains, the dependency becomes an exposure: a dangling record vulnerable to subdomain takeover, where an attacker serves content from a subdomain of your own trusted domain. That is a supply chain failure with a direct security consequence, and it is invisible to anything that only checks whether your site is up.

Incident Detection Depends on Noticing Changes

Both regulations expect prompt detection and reporting of significant incidents. Reporting clocks generally start when you become aware of something, which makes the speed of detection a compliance concern rather than only an operational one.

DNS changes can be the earliest visible sign of compromise. An unauthorized record change, a nameserver switch, a registrar modification, or a sudden alteration to email authentication can each indicate an attacker with access. If nobody is watching, you might not become aware for days, and everything downstream of awareness is delayed with it.

Continuity Runs Through DNS

Resilience requirements assume your services stay available. DNS failure takes everything with it. The classic causes are mundane rather than exotic: a domain lapses because a renewal notice reached an unmonitored inbox, or a DNSSEC signature expires and the domain stops resolving for validating resolvers. We cover the first in our piece on domain expiration as a silent risk, and the mechanics of the second in our DNSSEC guide.

A Practical Preparation Path

Five steps take you from an unmonitored DNS estate to one you can evidence.

1. Establish a real inventory. Discover every domain and subdomain rather than relying on documentation. Include assets inherited through acquisitions, which are often the least documented part of an estate. Assign an owner to each, and treat anything without one as a candidate for removal.

2. Map your DNS dependencies. Identify every record pointing at a third party. This is both a supply chain inventory and the working list for finding dangling records. Confirm each target is still a service you use and still under your control.

3. Turn on continuous detection. Move from periodic checks to real time monitoring for record changes, new subdomains, dangling records, expiry, DNSSEC validity, and email authentication drift. Detection speed is what makes reporting timeframes achievable.

4. Route DNS events into your incident process. Detection only counts if it reaches the people who respond. Feed DNS alerts into the channels and systems your security team already uses, so a DNS event enters the same triage flow as any other signal rather than sitting in an isolated console.

5. Keep evidence as a byproduct. Maintain a record of what changed and when, and be able to export the current state of your estate on demand. Evidence gathered continuously is far cheaper than evidence reconstructed under deadline, which is the core argument in our guide to building a continuous DNS compliance program. For the periodic human review that sits on top, our quarterly DNS audit checklist gives you a repeatable structure.

Free Template: DNS Compliance and Governance Framework

To structure this work, we publish a free DNS Compliance and Governance Framework as a shareable PDF. It includes a roles and responsibilities matrix, a control checklist with recommended frequencies, a risk scoring matrix with remediation targets, and a summary mapping to SOC 2, ISO 27001, NIS2, DORA, and PCI-DSS. No signup required, and it is free to circulate inside your organization.

Download the DNS Compliance and Governance Framework (PDF)

Where DNS Assistant Fits

DNS Assistant is a continuous monitoring and visibility layer for DNS. It supplies the detection and evidence that these preparations depend on, while the governance decisions and the compliance program itself remain yours to run.

Subdomain discovery builds the inventory your documentation does not have, surfacing subdomains you had lost track of.
Dangling DNS and subdomain takeover detection across 22+ cloud providers turns your third party DNS dependencies into a monitored list rather than an assumption.
Continuous change detection across record types, with real time alerts by email, Slack, Microsoft Teams, SMS, and webhooks, so detection is fast enough to matter for reporting.
SIEM integration via API and webhooks, push and pull, so DNS events reach the systems your responders already work in.
DNSSEC validation, TLS posture, and email authentication checks, covering the configuration failures that break continuity and trust.
WHOIS and expiration monitoring, independent of registrar notifications.
A viewable change history and data export in CSV, Excel, or PDF, giving you records to attach to your own documentation.
Multi-tenant, role based access for organizations managing DNS across teams or entities.

Two boundaries worth stating plainly. DNS Assistant detects and alerts on changes rather than gating them, so change approval remains part of your own workflow. And its exports are data you use as evidence, not reports pre-mapped to specific NIS2 or DORA articles. What it removes is the manual effort of discovery and watching; the judgment stays with you.

Start With Visibility

You can inspect a domain you already know about, its records, DNSSEC status, email authentication, and TLS posture, using the free DNS lookup tool or a Free Domain Risk Report. That is a reasonable way to begin assessing a single domain today.

For the parts that require discovery and continuous coverage across an estate, finding forgotten subdomains and catching dangling records as they appear, start free at dnsassistant.com.

This article is general information about how DNS relates to common themes in NIS2 and DORA. It is not legal or regulatory advice, and it does not attempt to interpret specific obligations. Scope, applicability, and requirements vary by sector, entity type, and national implementation. Confirm how these regulations apply to your organization with qualified legal or compliance advisors.

Zero Trust DNS: Applying "Never Trust, Always Verify" to Your Domains

Kishore Bhavnanie — Mon, 20 Jul 2026 13:36:56 +0000

Zero Trust has become the dominant model for modern security. Its core principle, "never trust, always verify," has reshaped how organizations think about network access, identity, and devices. Yet in most Zero Trust conversations, one of the most fundamental layers of infrastructure goes almost unmentioned: DNS. This is a significant gap, because DNS is where trust is quietly assumed at massive scale, and where a Zero Trust mindset has a great deal to offer.

Applying Zero Trust thinking to DNS means questioning the assumptions we make about our own domains and records: that they are configured the way we think, that they have not changed without authorization, that every subdomain is accounted for, and that the trust chains DNS underpins are actually intact. This article explains what Zero Trust means for DNS, why DNS belongs in any serious Zero Trust strategy, and how to put the principles into practice.

A Quick Refresher on Zero Trust

Zero Trust is a security model built on the assumption that no user, device, or system should be trusted by default, even inside your own perimeter. Instead of trusting anything based on its location on the network, Zero Trust requires continuous verification of every request. Its guiding principles include verifying explicitly, assuming breach, enforcing least privilege, and monitoring continuously.

The model emerged because the old perimeter-based approach, where anything inside the network was trusted, failed against modern threats. Attackers who breached the perimeter moved freely. Zero Trust removes that implicit trust and replaces it with constant verification. The question is how those same principles apply to DNS, and the answer turns out to be: directly and usefully.

Why DNS Belongs in a Zero Trust Strategy

DNS is built on trust assumptions, and Zero Trust exists precisely to challenge trust assumptions. Consider how much implicit trust DNS carries:

We trust that our DNS records are configured correctly, that they have not been changed without authorization, that every subdomain resolves to infrastructure we control, that our email authentication records still protect us, and that the certificates and DNSSEC signatures underpinning our domains are valid. Most organizations verify none of these continuously. They set DNS up, assume it stays correct, and only discover otherwise when something breaks or is exploited.

That is exactly the kind of implicit, unverified trust Zero Trust is designed to eliminate. A domain that resolves is not necessarily a domain that is secure, and "it is working" is not the same as "it is verified." DNS is a control surface where the gap between assumed and actual state can be enormous, and where the consequences of that gap, subdomain takeover, email spoofing, traffic redirection, are severe.

Applying Zero Trust Principles to DNS

Here is how each core Zero Trust principle translates into concrete DNS practice.

Verify Explicitly: Do Not Assume Your DNS Is Correct

Zero Trust says verify every claim rather than trusting it. Applied to DNS, this means continuously validating the actual state of your records rather than assuming they match your intent. Is your SPF record still within lookup limits? Is DNSSEC actually validating? Does every subdomain still point where it should? Explicit verification replaces the assumption that because you configured something once, it remains correct today.

Assume Breach: Treat Your DNS as a Target

Zero Trust assumes attackers are already present and designs accordingly. For DNS, this means assuming your domains are being probed for weaknesses: forgotten subdomains that can be hijacked, dangling records pointing at claimable infrastructure, misconfigurations that enable spoofing. Assuming breach means actively hunting for these exposures, particularly dangling records and subdomain takeover risk, rather than waiting to be told something is wrong.

Least Privilege: Minimize and Control DNS Change Access

Least privilege limits who can do what. In DNS, this means tightly controlling who can modify records, enforcing strong authentication on registrar and DNS provider accounts, using registrar locks on critical domains, and removing access for anyone who no longer needs it. The fewer people and systems that can change DNS, the smaller the attack surface for unauthorized changes.

Monitor Continuously: Watch DNS in Real Time

Continuous monitoring is the operational heart of Zero Trust, and it is where DNS most often falls short. A point-in-time check tells you nothing about what happens between checks. Zero Trust DNS means continuously watching for record changes, new subdomains, dangling records, expiration risks, and authentication failures, so that any deviation from the verified-good state is caught the moment it occurs, not at the next quarterly review.

What Zero Trust DNS Looks Like in Practice

Putting these principles together, a Zero Trust approach to DNS has several concrete characteristics:

A complete, continuously verified inventory of every domain and subdomain, because you cannot apply Zero Trust to assets you do not know exist. This directly addresses the shadow DNS problem.
Continuous validation of record integrity, email authentication, TLS, and DNSSEC, rather than one-time setup and indefinite trust.
Active detection of the exposures an attacker would target: dangling records, takeover-vulnerable subdomains, and misconfigurations.
Immediate alerting on any change or deviation, so unverified changes are surfaced in real time.
Tight access control and change visibility, so every modification is authorized and recorded.

The through-line is the elimination of assumed trust. Every element of your DNS posture is continuously verified rather than taken on faith, which is precisely what makes it Zero Trust.

Zero Trust DNS and the Broader Security Program

DNS Zero Trust does not exist in isolation. It reinforces the rest of your Zero Trust architecture. If your identity and access controls are rigorous but an attacker can take over a subdomain to host a convincing phishing page under your trusted domain, they can undermine those controls by exploiting the trust your domain carries. If your network is segmented but your email authentication has silently drifted, attackers can still spoof your domain. DNS is the layer beneath much of what Zero Trust protects, and leaving it on implicit trust weakens the whole model.

This connects to the broader discipline of DNS Posture Management, which is essentially the operational practice of Zero Trust applied to DNS: continuous verification of your entire DNS security posture rather than assumed correctness.

How DNS Assistant Enables Zero Trust DNS

DNS Assistant provides the continuous verification layer that a Zero Trust approach to DNS requires. It is important to be precise about the role it plays: it is a monitoring, verification, and alerting platform, the "always verify" and "monitor continuously" part of Zero Trust, rather than a policy-enforcement engine that gates changes. Access control and change enforcement live in your own DNS provider and processes; DNS Assistant continuously verifies that the resulting state is what it should be.

In practice, it delivers the verification and monitoring principles directly:

Continuous verification of record integrity, email authentication, TLS posture, and DNSSEC validity, replacing assumed correctness with ongoing checks.
Assume-breach detection of dangling records and subdomain takeover risk across 22+ cloud providers, plus subdomain discovery to surface the assets you did not know you had.
Real-time alerting on any record change or deviation, across email, Slack, Microsoft Teams, SMS, and webhooks, with SIEM integration via API and webhooks so DNS signals feed your broader Zero Trust monitoring.
A viewable change-history audit trail and data export, so every deviation is recorded and reviewable.
Multi-tenant, role-based access for managing verification across teams and domains.

By continuously verifying the state of your DNS and alerting on any deviation, DNS Assistant operationalizes the core Zero Trust instruction for the DNS layer: never trust that your DNS is correct, always verify that it is.

Start Verifying Your DNS

A Zero Trust approach starts with seeing the actual state of your DNS rather than assuming it. Inspect a domain's records, DNSSEC, email authentication, and TLS posture with the free DNS lookup tool or a Free Domain Risk Report.

To apply continuous verification across your entire domain footprint, the "always verify, monitor continuously" core of Zero Trust DNS, start free at dnsassistant.com.

Building a DNS Audit Checklist for Quarterly Reviews (With Free Template)

Kishore Bhavnanie — Fri, 17 Jul 2026 18:41:42 +0000

Most DNS problems are not caused by attacks. They are caused by drift. A record added for a project that ended two years ago. An SPF entry for a vendor you no longer use. A subdomain pointing at a cloud resource someone deleted last spring. None of it breaks anything today, which is exactly why nobody looks at it, and why it quietly accumulates into an outage or a takeover.

A quarterly DNS audit is the discipline that catches drift before it costs you. It does not need to be a week-long project. Done properly, with a repeatable checklist and continuous monitoring handling the day-to-day, a quarterly review is a focused session that surfaces what changed, what should not exist, and what needs fixing.

This guide gives you that checklist, organized into six areas, with a free downloadable framework at the end you can use as your template.

Why Quarterly, and What It Is Not

A quarterly audit is not your monitoring. If the first time you learn about a dangling record is at your quarterly review, you have already been exposed for up to three months. Continuous monitoring catches changes as they happen; the quarterly audit catches the things automation cannot judge, whether a record should still exist, whether an owner still works here, whether a baseline is still the right baseline.

Think of it as the human layer on top of the automated one. Automation answers "what changed?" The audit answers "is any of this still correct?"

1. Inventory: Does Your List Match Reality?

Start here, because everything downstream depends on it.

Reconcile your domain register. Pull every domain your organization owns, including defensive registrations, regional variants, and anything inherited through acquisitions. Compare it to your documented list and reconcile the gaps.
Enumerate subdomains, including the ones nobody remembers. Most teams cannot list their full subdomain footprint. Active discovery, rather than reading your own documentation, is what surfaces the shadow DNS created by marketing campaigns, dev environments, and retired SaaS tools.
Assign an owner to every domain and subdomain. Anything without a named owner is a candidate for removal. Unowned DNS is how drift becomes risk.
Flag anything you cannot explain. If nobody can say why a record exists, that is a finding, not a curiosity.

2. Dangling Records and Takeover Exposure

This is the highest-severity item on the list, so treat it as the priority finding each quarter.

Check every record pointing at a third party. CNAMEs aimed at cloud services, SaaS platforms, or CDNs are where subdomain takeover lives. Verify the target still exists and still belongs to you.
Cross-check against decommissioned services. Ask what your teams shut down last quarter, then confirm the matching DNS records were removed. This is where the audit catches what the offboarding process missed.
Review NS delegations. Delegated zones pointing at nameservers that no longer serve them are a takeover path most audits skip entirely.

3. Email Authentication

Review SPF for accuracy and lookup limits. Vendors get added and never removed, and SPF has a hard limit on DNS lookups. Confirm every entry is still a service you actually use. Our SPF, DKIM, and DMARC guide covers the mechanics.
Confirm DKIM selectors are current and that retired sending services no longer have live keys.
Check your DMARC policy. Has it drifted back to p=none? Are the aggregate reports going somewhere a human reads?
Audit subdomain email policy. Subdomains without their own protection can be spoofed even when your apex domain is locked down.

4. Certificates, TLS, and DNSSEC

Verify CAA records still list only the certificate authorities you intend to use. See our CAA records guide for what to check.
Review TLS configuration across your public endpoints, not just the apex domain.
Check DNSSEC signature validity and key rollover schedule. A routine rollover done wrong can take a domain offline for validating resolvers, and it fails silently for the people who broke it. Our DNSSEC guide explains the chain of trust.

5. Registration, Expiry, and Access

Confirm expiration dates for every critical domain and that auto-renew is on with a valid payment method. A lapsed domain is the most preventable outage there is, and we cover why in our piece on domain expiration as a silent risk.
Verify registrar lock is enabled on domains that matter.
Review who has access to registrar and DNS provider accounts. Remove departed staff. Confirm MFA is enforced.
Check that renewal and alert contacts point at monitored inboxes, not an individual who left.

6. Change Review and Baselines

Read the change history for the quarter. Every change should map to a known request. Anything unexplained deserves investigation.
Re-validate your baselines. What you defined as "correct" last quarter may not reflect this quarter's architecture.
Close the loop on last quarter's findings. An audit that produces findings nobody remediates is theatre. Start each review by confirming the previous one's items are done.

Free Template: DNS Compliance & Governance Framework

To run this as a repeatable process, we publish a free DNS Compliance & Governance Framework as a shareable PDF. It includes a roles and responsibilities matrix, a 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. Use it as your quarterly template. No signup required, and it is free to circulate inside your organization.

Download the DNS Compliance & Governance Framework (PDF)

Making the Audit Take Hours, Not Weeks

The reason quarterly audits balloon into multi-week projects is that teams try to do the discovery, the checking, and the reviewing all in one go, manually. The fix is to let automation carry the first two so the review is the only part that needs people.

This is where DNS posture management changes the shape of the work. With continuous monitoring in place, you arrive at your quarterly review with the inventory already current, dangling records already flagged, email authentication and DNSSEC already assessed, and a change history already recorded. The audit becomes a review of findings rather than a scramble to produce them.

DNS Assistant supports exactly that: subdomain discovery to keep your inventory honest, dangling DNS detection across 22+ cloud providers, continuous record change detection with real-time alerts, email authentication and TLS posture checks, DNSSEC validation, WHOIS and expiration monitoring, a viewable change-history audit trail, and data export in CSV, Excel, or PDF for the evidence your review produces. Two honest boundaries worth stating: it detects and alerts on changes rather than gating them, and its exports are data you attach to your own documentation, not auto-generated control-mapped reports. The audit judgment stays yours; the legwork does not have to.

Start Your First Review

You can inspect a domain's records, DNSSEC status, email authentication, and TLS posture right now with the free DNS lookup tool or a Free Domain Risk Report, useful for a domain you already know about, and a reasonable way to start section 3 and 4 of this checklist today.

For the parts that need discovery and continuous coverage, finding forgotten subdomains and catching dangling records across your footprint, start free at dnsassistant.com and let the monitoring do the legwork before your next quarterly review.

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.