DEV Community: Kishore Bhavnanie

DNS Posture vs. ASM: Where They Overlap, Where They Don't

Kishore Bhavnanie — Sat, 15 Aug 2026 18:12:52 +0000

If your organization runs an Attack Surface Management platform, there is a fair question to ask before considering DNS posture management: do I not already have this? ASM tools discover internet-facing assets, including subdomains, from an attacker's perspective. On the surface, that sounds like it covers the DNS layer. It is a reasonable objection, and it deserves a straight answer rather than a hand-wave, because ASM and DNS posture management genuinely overlap in one area, and genuinely diverge in several others.

The short version: ASM is built for breadth, discovering everything an attacker can see across your entire external footprint. DNS posture management is built for depth on one specific, high-value layer. They are complementary, and the overlap is narrower than it first appears. This article explains where they meet, where they part, and how to think about whether you need both.

What ASM Is Built to Do

Attack Surface Management, specifically external ASM, emulates what an attacker sees when they reconnoiter your organization from the outside. It continuously discovers internet-facing assets across your whole digital footprint: cloud instances, exposed ports and services, APIs, web applications, third-party connections, and yes, subdomains. Its core value is finding the assets you did not know you had, the shadow IT, the orphaned staging environment, the microsite a team spun up without telling security.

The defining characteristic of ASM is breadth from the outside in. Platforms in this category scan enormous swaths of the internet to map your exposure, and their strength is scale: catching the new internet-facing service that appeared this week anywhere across your footprint. That breadth is exactly what makes ASM valuable, and it is a genuinely important capability that DNS posture management does not replace.

Where ASM and DNS Posture Management Overlap

The real overlap is subdomain and asset discovery. Both an ASM tool and a DNS posture tool will surface subdomains you had forgotten about. If your only concern is "what subdomains exist that I do not know about," an ASM platform addresses part of that need, and so does DNS posture management. This is the real basis for the "do I not already have this?" question, and pretending the overlap does not exist would not be credible.

So if you already run ASM, you are already getting some subdomain discovery. That is true, and worth acknowledging plainly.

Where They Diverge, and It Is a Lot

The divergence is in what happens to the DNS layer after discovery. ASM treats DNS records largely as asset metadata, a way to find and attribute assets. DNS posture management treats the DNS configuration itself as the thing to be continuously assessed for security problems. That difference produces several capabilities ASM tools generally do not provide, because they are not what ASM is for.

Continuous DNSSEC validation. Whether your DNSSEC chain of trust is intact, whether a signature has expired, whether a key rollover broke validation, this is DNS-layer security posture, not asset discovery. ASM notes that a domain exists; it does not continuously verify the domain's DNSSEC integrity.

Email authentication posture. SPF, DKIM, and DMARC determine whether your domain can be spoofed. They are DNS records that require ongoing correctness assessment, not assets to be inventoried. This is squarely DNS posture territory, covered in our email authentication guide.

Dangling-record and subdomain-takeover depth. Discovering a subdomain is one thing; continuously evaluating whether it points at a deprovisioned resource that can be claimed is another. Deep dangling-record and subdomain-takeover detection across many cloud providers is a specialized, ongoing check, not a one-time discovery event.

Registrar, WHOIS, and nameserver change monitoring. An unauthorized nameserver change or a quiet WHOIS contact-email swap is one of the clearest signals of domain hijacking, and it happens at the registrar layer. ASM, focused on scanning internet-facing assets, is not watching your registrar for these changes. DNS posture management is, as we cover in protecting against registrar account takeovers.

Delegation and glue integrity. Whether your delegation is consistent between parent and child, whether glue records are stale, whether a delegation points at infrastructure you no longer control, these DNS-specific structural checks sit outside ASM's discovery-oriented remit.

The Cleanest Way to Think About It

A useful mental model: ASM answers "what do I have exposed?" across your entire external surface. DNS posture management answers "is my DNS layer secure and correctly configured?" in depth. The first is a wide, shallow sweep of everything. The second is a deep, continuous assessment of one critical layer.

ASM's job is to make sure no asset escapes notice, across cloud, web, ports, and services. It is intentionally broad, and its subdomain discovery is one feature among many rather than a deep DNS-security capability. DNS posture management's job is to take the DNS and domain layer specifically and continuously check it against the ways DNS goes wrong: broken DNSSEC, spoofable email, dangling records, hijacked delegations, registrar tampering. An ASM tool that discovers a subdomain will not tell you that subdomain's parent domain has an expired DNSSEC signature or a DMARC record that permits spoofing. That is not a failing of ASM; it is simply outside its purpose.

Do You Need Both?

For most organizations with meaningful external exposure, the answer is that they serve different needs and the overlap is small enough that having both is not redundant. If you run ASM, keep it, it does broad discovery that DNS posture management does not attempt. What DNS posture management adds is the depth on the DNS layer that ASM's breadth-first design does not provide.

If you run neither, the choice depends on your primary concern. If it is broad visibility into unknown assets across your whole footprint, ASM is the right starting point. If it is the security and correctness of your domains specifically, their DNSSEC, email authentication, takeover exposure, and registrar integrity, DNS posture management is the more direct fit, and it is a smaller, more focused addition than a full ASM platform.

The two are not competitors fighting for the same budget line. They are adjacent tools that see different things, and the subdomain-discovery overlap is the one place they touch. This is the same complement-not-replace pattern that applies to how DNS posture management relates to the rest of the security stack, which we cover in the DNS posture gap your CNAPP does not cover.

See Your DNS Layer in Depth

You can inspect the DNS-layer posture of a domain, its records, DNSSEC status, email authentication, and TLS, with the free DNS lookup tool or a Free Domain Risk Report.

To add continuous, DNS-specific posture depth alongside whatever discovery tooling you already run, start free at dnsassistant.com. For the broader discipline, see our guide to DNS posture management.

The DNS Posture Gap Your CNAPP Doesn't Cover

Kishore Bhavnanie — Tue, 11 Aug 2026 17:54:11 +0000

If your organization has invested in a Cloud-Native Application Protection Platform, you have consolidated a genuinely impressive amount of security into one place. A modern CNAPP pulls together cloud configuration posture, workload protection, identity entitlements, data security, and infrastructure-as-code scanning into a single view of cloud risk. It is one of the most effective ways to close the gaps that used to exist between a dozen separate point tools.

But there is one layer that sits just outside the boundary of what a CNAPP was built to see: your DNS and domain posture. It is not a flaw in these platforms; it is a matter of scope. CNAPPs are oriented around the cloud control plane and the workloads running on it. Your domains, subdomains, delegations, and DNS records live at a different layer, one that is public-facing, spans every provider at once, and is not part of any single cloud account. This article explains why that gap exists, what lives in it, and how DNS posture management complements a CNAPP rather than competing with it.

What a CNAPP Covers, and Where Its Edge Is

It helps to be precise about what a CNAPP actually consolidates, because the gap becomes obvious once the scope is clear. A CNAPP typically brings together cloud security posture management for configuration and compliance, cloud workload protection for the virtual machines and containers running your applications, cloud infrastructure entitlement management for identities and permissions, data security posture management for where sensitive data lives, and infrastructure-as-code scanning for catching problems before deployment.

Every one of those is oriented around your cloud accounts and the resources inside them. The CNAPP authenticates to AWS, Azure, and Google Cloud, reads their APIs, and builds a picture of the posture inside those environments. That is exactly what it should do, and it does it well.

DNS posture is a different kind of thing. Your domain is not a resource inside one cloud account. It is a public-facing asset that resolves from the open internet, often points at multiple clouds and third-party services simultaneously, and is administered through a registrar and DNS provider that may have nothing to do with your cloud environment at all. A CNAPP reading your cloud APIs does not see the dangling CNAME pointing at a deprovisioned service, the subdomain that never appeared in any cloud account, or the nameserver change made at your registrar. Those live outside the control plane it monitors.

What Lives in the DNS Gap

The DNS layer carries a specific set of risks that a cloud-oriented platform is not positioned to catch. These are not exotic; they are among the most exploited weaknesses in real attacks.

Subdomain takeover from dangling records. When a DNS record points at a cloud resource or SaaS service that has been deprovisioned, an attacker can claim the abandoned resource and serve content from your trusted domain. The record often lives in DNS that no cloud account owns, and the vulnerable target may be on a platform your CNAPP does not monitor. We cover this in depth in our guide to dangling DNS and subdomain takeover.

Forgotten and undiscovered subdomains. Marketing campaigns, test environments, and retired tools leave behind subdomains that never appeared in a cloud inventory. This shadow DNS is invisible to a platform scanning cloud accounts, because the assets were never cloud resources in the first place.

Email authentication drift. SPF, DKIM, and DMARC live in DNS and determine whether your domain can be spoofed. They are not cloud configuration, so they fall outside the CNAPP's remit, yet a broken one exposes you to impersonation.

DNSSEC and certificate-issuance posture. DNSSEC integrity and CAA records govern the trust layer of your domains. A failed DNSSEC signature or a permissive CAA record is a DNS-layer problem, not a cloud-workload one.

Registrar and nameserver changes. An unauthorized nameserver change or registrar-level modification is one of the clearest signs of a domain hijacking, and it happens entirely outside your cloud environment, at a provider a CNAPP has no visibility into.

Domain expiration. A lapsed domain causes total outage and is a registrar concern, not a cloud one. It is exactly the kind of thing that falls between the cracks of a cloud-focused tool.

Why the Gap Is Structural, Not Accidental

It is worth being clear that this is not a shortcoming of CNAPPs. The gap exists because DNS posture and cloud posture are genuinely different problems that need different vantage points.

A CNAPP works from the inside, authenticated into your cloud accounts, reading configuration from the control plane. That inside-out view is exactly right for cloud workloads and configuration. DNS posture requires the opposite: an outside-in view that sees your domains the way the internet sees them, across every provider at once, including the parts hosted nowhere near your cloud. You cannot get a complete DNS picture by reading one cloud's API, because your DNS is not confined to one cloud, and the most dangerous DNS problems, dangling records, forgotten subdomains, registrar changes, are precisely the ones that live outside any cloud account.

This is the same reason a CNAPP does not replace, say, an external attack surface scanner. Different vantage points see different things. DNS posture management is the outside-in view of one specific, high-value part of your attack surface.

How DNS Posture Management Complements Your CNAPP

The two fit together cleanly because they cover adjacent, non-overlapping layers. Your CNAPP secures the cloud control plane and the workloads on it. DNS posture management secures the domain and resolution layer that sits in front of and around all of it. Together they close a gap that either one alone leaves open.

DNS Posture Management as a discipline covers continuous discovery of your domains and subdomains, detection of dangling records and takeover risk, monitoring of email authentication and DNSSEC, and alerting on record, nameserver, and registrar changes. DNS Assistant delivers exactly this, and it is built to sit alongside your existing stack rather than duplicate it:

An outside-in view of your domains across every provider, not confined to one cloud account.
Subdomain discovery and dangling-record detection across 22+ cloud providers, catching the takeover exposure that lives outside the control plane.
Email authentication, TLS, and DNSSEC monitoring, the DNS-layer trust signals a cloud tool does not assess.
Registrar, WHOIS, and nameserver change alerts, visibility into the registrar layer your CNAPP cannot reach.
SIEM integration via API and webhooks, so DNS findings flow into the same place your CNAPP and other security signals are already correlated.

That last point matters for how the two actually work together in practice. DNS Assistant is not trying to be your single pane of glass; it feeds the pane you already have. Its alerts route into your SIEM and workflow via API and webhooks, so DNS posture becomes one more correlated input alongside your cloud posture, rather than a separate silo. It is worth being clear about the integration model: this is connection via documented API and webhooks, not a prebuilt marketplace connector, so it involves a small amount of setup on your side, described in our guide to integrating DNS monitoring with your SIEM.

The Practical Takeaway

If you have a CNAPP, you have done the hard work of consolidating cloud posture, and you should keep it. The question worth asking is narrower: who is watching the DNS and domain layer that sits outside it? For most organizations, the answer is no one, because it was never any single tool's job. That is the gap DNS posture management fills, and it is a small, well-defined addition rather than another sprawling platform to adopt.

See the Gap for Yourself

You can inspect what your DNS layer exposes right now, records, subdomains, email authentication, DNSSEC, and TLS posture, with the free DNS lookup tool or a Free Domain Risk Report.

To add continuous DNS posture management alongside your existing cloud security stack, start free at dnsassistant.com.

Email Deliverability Beyond SPF, DKIM, and DMARC

Kishore Bhavnanie — Mon, 10 Aug 2026 12:39:53 +0000

SPF, DKIM, and DMARC are the foundation of email authentication, and any organization serious about deliverability and anti-spoofing needs all three. But they are not the whole story. A newer set of standards, also published largely through DNS, addresses problems the original three do not: encrypting the connection between mail servers, reporting when that encryption fails, displaying your verified logo in the inbox, and preserving authentication through mailing lists and forwarders. Each solves a specific gap, and each lives, at least partly, in records you publish and can monitor.

If you have already implemented SPF, DKIM, and DMARC, covered in our complete email authentication guide, this piece is the natural next layer. It explains MTA-STS, TLS-RPT, BIMI, and ARC: what each does, what the records look like, and why they are worth monitoring.

MTA-STS: Enforcing Encryption Between Mail Servers

When one mail server delivers to another, it can upgrade the connection to TLS using STARTTLS. The weakness is that this is opportunistic: the encryption is negotiated in plaintext, so an attacker positioned in the middle can strip the upgrade and force the message through unencrypted, a downgrade attack. SPF, DKIM, and DMARC do nothing about this, because they authenticate the message, not the transport.

MTA-STS closes the gap by letting your domain publish a policy that says, in effect, "servers delivering to me must use TLS, and must validate my certificate." It has two parts: a DNS TXT record that signals the policy exists, and a policy file served over HTTPS that spells out the details.

The DNS record is published at a specific name under your domain:

_mta-sts.example.com.   IN   TXT   "v=STSv1; id=20260415000000"

The id is a version marker you change whenever you update the policy, so sending servers know to re-fetch it. The policy file itself lives at a fixed HTTPS location, https://mta-sts.example.com/.well-known/mta-sts.txt, and looks like this:

version: STSv1
mode: testing
mx: mail.example.com
max_age: 604800

The mode is the key setting. Start at testing, which reports problems without blocking delivery, then move to enforce once you have confirmed legitimate mail is not affected. This staged rollout is the safe path, and it depends on the next standard to tell you what is happening.

TLS-RPT: Seeing When Encryption Fails

MTA-STS in testing mode is only useful if you can see the results, and that is what TLS-RPT (SMTP TLS Reporting) provides. It asks sending servers to send you daily aggregate reports about TLS connection successes and failures, so you can spot certificate problems, handshake failures, or downgrade attempts before switching MTA-STS to enforce.

It is a single DNS TXT record at its own name, pointing at where reports should go:

_smtp._tls.example.com.   IN   TXT   "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The rua tag names the address (or addresses, comma-separated) that receive the JSON reports. The relationship between the two standards is simple: MTA-STS enforces encryption, and TLS-RPT tells you how that enforcement is going. Deploying MTA-STS without TLS-RPT means flying blind through the exact period when you most need visibility.

BIMI: Your Verified Logo in the Inbox

BIMI (Brand Indicators for Message Identification) is the standard that displays your organization's logo next to authenticated messages in supporting email clients. Beyond looking professional, it is a trust signal: recipients see a verified brand mark, which is harder for impersonators to fake.

BIMI has an important prerequisite: it only works if you have DMARC in place at an enforcement policy. It is explicitly a reward for having done the authentication groundwork, not a shortcut around it. The record is a TXT record pointing at your logo (in a specific SVG format) and, for most real deployments, a verification certificate:

default._bimi.example.com.   IN   TXT   "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/bimi-cert.pem"

The l tag points to the logo, and the a tag points to the Verified Mark Certificate that attests you own the logo. Major mailbox providers generally require that certificate before they will display the mark, which is what stops anyone from simply pointing BIMI at a logo they do not own.

ARC: Preserving Authentication Through Forwarders

ARC (Authenticated Received Chain) solves a subtler problem. When a message passes through an intermediary, a mailing list, a forwarding service, that intermediary often modifies the message in ways that break SPF and DKIM. The result is that legitimate mail, forwarded through a list, can fail authentication at the final destination and get rejected, even though it was genuine.

ARC addresses this by letting each intermediary record the authentication results it saw at the time it received the message, and cryptographically sign that assessment. The final receiver can then see the chain: "this message passed authentication when the mailing list received it, and here is the list vouching for that." It does not override the receiver's own judgment, but it gives them the context to accept legitimate forwarded mail that would otherwise fail.

ARC is implemented by mail servers rather than being a single record you publish, so it is less a DNS configuration task and more a capability your mail infrastructure either supports or does not. It is worth knowing about because it explains why some legitimate forwarded mail fails, and why mature mail platforms implement it.

How These Fit Together

It helps to see the layers as complementary rather than competing:

SPF, DKIM, DMARC authenticate the message and its sender.
MTA-STS and TLS-RPT secure and report on the transport encryption between servers.
BIMI rewards strong authentication with a visible trust signal.
ARC preserves authentication results through intermediaries.

You do not need all of them on day one, and the sensible order is to get SPF, DKIM, and DMARC solid first, then add MTA-STS with TLS-RPT, then BIMI once DMARC is enforced. ARC largely comes along with a capable mail platform. Each layer addresses a real, distinct gap.

Why These Records Are Worth Monitoring

Every one of these standards, except ARC, lives in DNS records, which means they share the failure mode of all DNS configuration: they can be changed, break, or drift without anyone noticing until mail is affected. An MTA-STS policy record whose id is stale, a TLS-RPT address that no longer has a monitored mailbox behind it, a BIMI record pointing at a moved logo or an expired certificate, each is a silent failure that undermines the protection or trust signal you set up.

Because these are TXT records in your zone, they fall within the same continuous change monitoring that covers the rest of your DNS. DNS Assistant detects changes across your DNS records, including the TXT records these standards rely on, and surfaces them in real time, so an unexpected change to your email-security records is something you learn about promptly. It monitors and alerts rather than managing your mail configuration for you: the setup lives in your DNS and mail platform, and the value here is catching the day one of these records changes or disappears when it should not have. This is part of the broader email authentication posture we cover in the SPF, DKIM, and DMARC guide.

Check Your Email Records

You can inspect the email-related records a domain publishes with the free DNS lookup tool or a Free Domain Risk Report, a quick way to see what is in place and what is missing.

To keep your email authentication and transport-security records continuously monitored for change, start free at dnsassistant.com.

DNS in Multi-Cloud and Hybrid Environments

Kishore Bhavnanie — Wed, 05 Aug 2026 15:28:25 +0000

Adopting a second cloud, or keeping one foot on-premises, solves a lot of problems. It also quietly creates one that teams rarely plan for: DNS stops being a single, coherent thing. Each cloud brings its own DNS service, its own private zones, its own way of handling internal resolution, and none of them natively knows about the others. What was one authoritative picture of your namespace fractures into several that do not automatically agree. The applications keep working right up until the moment a service in one cloud cannot resolve a name in another, and then the failure is baffling, because the network is fine and only DNS is broken.

This guide covers the specific challenges of running DNS across multiple clouds and hybrid environments, the patterns teams use to tame them, and why visibility across the whole fragmented picture matters more here than anywhere else. It is vendor-neutral: the goal is to understand the shape of the problem, not to recommend one provider.

Why Multi-Cloud DNS Is Genuinely Harder

The difficulty is not that any one cloud's DNS is bad. Each of the major providers offers a capable, highly available DNS service. The difficulty is that they were each designed to be the center of their own world, not to cooperate as equals in someone else's architecture.

Private zones do not cross cloud boundaries. This is the core issue. When a service in one cloud tries to resolve a private, internal name that lives in another cloud's private DNS zone, the resolver has no idea that zone exists. The name is not on the public internet, so the lookup returns NXDOMAIN, a "no such domain" answer, and the connection fails even though the underlying network path between the two clouds is perfectly healthy. The problem is purely that DNS in cloud A cannot see the private names in cloud B.

The walled garden runs one way. Cloud providers generally let you delegate DNS to them easily but make it awkward to delegate authority back out, and they resist standard zone transfers away from their platform. This asymmetry is fine if you live inside one cloud and painful the moment you need clouds to treat each other as peers.

Every provider solves internal resolution differently. Private zones, resolver endpoints, and forwarding are configured in a different way in each cloud, with different terminology and different constraints. There is no single mental model that carries across all of them, so operational knowledge does not transfer cleanly, and mistakes are easy.

Consistency features are uneven. Capabilities such as DNSSEC support and various security controls are not implemented identically across providers. An assumption that holds in one cloud may not hold in another, which is exactly the kind of gap that goes unnoticed until it is exploited or it breaks.

Split-Horizon: The Same Name, Two Answers

A concept worth understanding on its own, because it appears everywhere in these environments, is split-horizon DNS (also called split-brain). It means returning a different answer for the same name depending on where the query comes from. Internal users get a private address; external users get the public one:

# Internal view: a query from inside the network
app.example.com.   300   IN   A   10.0.1.50

# External view: the same name, queried from the public internet
app.example.com.   300   IN   A   203.0.113.50

Cloud providers implement this through private hosted zones that shadow a public name internally. It is useful and common, but it multiplies the number of "correct" answers a name can have, which makes reasoning about, and monitoring, your namespace harder. When a name can legitimately resolve to different things from different vantage points, "is this record correct?" becomes a question with more than one right answer.

The Patterns That Tame It

Teams that run multi-cloud DNS well tend to converge on a few patterns.

Conditional forwarding between clouds. The standard fix for the private-zone visibility problem is to set up forwarding so that queries for another cloud's private names are directed to that cloud's resolver. Each major provider now offers managed resolver endpoints designed for exactly this, inbound and outbound endpoints that receive and send cross-boundary queries, so a workload in one cloud can resolve private names in another. Using these managed services is generally preferred over hand-running your own forwarder instances inside each cloud.

A hub-and-spoke resolution topology. Rather than wiring every cloud to every other cloud directly, many teams centralize DNS forwarding through a hub, a central point that knows how to route queries to the right authoritative source. This turns an unmanageable mesh of forwarding rules into a single, comprehensible hub with spokes out to each environment.

A clear naming strategy. Deciding up front which names are public, which are private, and how internal names are structured across environments prevents the collisions and ambiguity that split-horizon and multi-cloud private zones invite. A consistent naming convention is unglamorous and enormously valuable.

Infrastructure-as-code for DNS. Managing records across several providers by hand, through several different consoles, is where drift and error creep in. Expressing DNS in code applied consistently across providers keeps the environments aligned and changes reviewable, which matters more the more places your DNS lives.

Why Visibility Is the Hard Part

Every challenge above shares a root: in a multi-cloud, hybrid environment, no single provider's console shows you the whole picture. Your namespace is spread across AWS, Azure, Google Cloud, and on-premises, each with a partial view, and the gaps between those views are exactly where problems hide, the private name that cannot be resolved across a boundary, the record that drifted in one cloud but not another, the inconsistent security posture that holds in one place and not the next.

This is why an external, provider-independent view of your public DNS becomes so valuable in these environments. You need something that looks at your domains the way the outside world sees them, across every provider at once, rather than trusting each cloud's console to tell you its own slice is fine. The whole is more than the sum of the consoles, and the failures live in the seams.

Where DNS Assistant Fits

DNS Assistant provides that provider-independent view of your public DNS surface. Rather than logging into three consoles to check three partial pictures, it monitors your domains from the outside, the way a resolver on the public internet sees them, and surfaces changes and problems across your whole external footprint regardless of which provider hosts each zone.

That means it watches record changes, delegation and nameserver changes, dangling records, email authentication, TLS, DNSSEC status, and expirations across all your public-facing domains in one place, and alerts in real time when something changes. It is worth being precise about scope: this is monitoring of your public, authoritative DNS surface, not management of the internal private-zone forwarding and resolver topology inside each cloud, which remains the job of your cloud configuration and tooling. What it removes is the blind spot of having no single vantage point on the public side of a fragmented estate.

See Your Whole External Footprint

You can inspect how any of your domains resolves from the outside, across whichever provider hosts it, with the free DNS lookup tool or a Free Domain Risk Report.

To get one continuous, provider-independent view of your public DNS across a multi-cloud estate, start free at dnsassistant.com. For the broader discipline this supports, see our guide to DNS posture management.

Monitoring Glue Records and Delegation

Kishore Bhavnanie — Tue, 04 Aug 2026 19:00:39 +0000

Some of the most consequential DNS records are ones most people never touch and few think to monitor. Glue records and the delegation they support sit at the boundary between your domain and the wider DNS, in the parent zone rather than your own. When they are correct, everything just works. When they break or drift, the failure is often total, the domain becomes unreachable, and confusing, because the problem is not in the zone you administer. This is exactly the kind of overlooked surface where continuous attention pays off.

This guide explains what glue records and delegation actually are, shows what they look like, walks through how to inspect them, and covers what is worth monitoring and why.

Delegation: How the Parent Points at You

DNS is a hierarchy. When someone looks up your domain, a resolver starts at the root, gets referred to the top-level domain (such as .com), and the TLD refers it to your authoritative nameservers. That final referral, the TLD telling the world which nameservers are authoritative for your domain, is delegation, and it is expressed as NS records in the parent zone.

A crucial detail: the NS records that matter for finding you live in the parent zone, published there through your registrar, not in your own zone. You also have NS records at your zone apex, and the two should match. When they drift apart, resolution can still work but audit tools flag it, and the mismatch can mask a real delegation problem:

; In the parent (.com) zone, published via your registrar:
example.com.   172800   IN   NS   ns1.example.com.
example.com.   172800   IN   NS   ns2.example.com.

; At your own zone apex, these should match:
example.com.   3600     IN   NS   ns1.example.com.
example.com.   3600     IN   NS   ns2.example.com.

Glue: Solving the Chicken-and-Egg Problem

Look closely at the delegation above and a circular dependency appears. The nameservers for example.com are ns1.example.com and ns2.example.com, names inside the very domain they are supposed to serve. To find ns1.example.com, a resolver would need to ask the nameservers for example.com, but to reach those, it first needs the address of ns1.example.com. It cannot get there from here.

Glue records break the deadlock. A glue record is an A or AAAA record for your nameserver, published in the parent zone alongside the delegation, so the resolver receives the nameserver's IP address in the same response that tells it the nameserver's name. In a query to a TLD nameserver, glue appears in the ADDITIONAL section:

;; AUTHORITY SECTION:
example.com.   172800   IN   NS   ns1.example.com.
example.com.   172800   IN   NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.   172800   IN   A   203.0.113.1     <- glue
ns2.example.com.   172800   IN   A   203.0.113.2     <- glue

Those A records in the Additional section are the glue: bootstrap addresses that let a resolver contact your nameserver without needing to resolve its name first.

When Glue Is Required, and When It Must Not Exist

This is the part that trips people up, and it comes down to a concept called bailiwick.

In-bailiwick nameservers need glue. When your nameserver's hostname is inside the domain it serves (ns1.example.com serving example.com), glue is required. Without it, the circular dependency above makes your domain unreachable.

Out-of-bailiwick nameservers must not have glue. When you use a managed provider whose nameservers live in a different domain (say ns1.provider.net serving example.com), no glue is needed or wanted. The resolver simply looks up ns1.provider.net through provider.net normally. The TLD should not publish glue for a host it is not authoritative for, both because it is unnecessary and because accepting out-of-bailiwick additional data is a cache-poisoning risk that modern resolvers deliberately reject.

The practical takeaway: if you run nameservers inside your own domain, glue is critical and must be correct. If you use a managed DNS provider, glue is the provider's concern and not something you maintain. Knowing which case you are in is the first step to knowing what to monitor.

How to Inspect Your Delegation and Glue

You can check all of this directly. The key is to query a parent (TLD) nameserver, because glue lives in the parent, not your zone.

Ask a TLD server for your domain's NS records and look at the Additional section for the glue:

# Query a .com TLD nameserver directly for the delegation + glue
dig @a.gtld-servers.net example.com NS

# Compare with the NS records your own zone reports
dig example.com NS +short

# Check the addresses your nameservers actually have now
dig ns1.example.com A +short

What you are checking for: that the parent's NS records match your apex NS records, that glue addresses in the Additional section match the real current addresses of your nameservers, and that you do not have stale glue pointing at an address you no longer control.

What Can Go Wrong, and Why It Is Worth Monitoring

Delegation and glue fail in specific, high-impact ways, and because they live in the parent zone, they are easy to forget until something breaks.

Stale glue after an IP change. If you renumber a nameserver, change its IP, but forget to update the glue at the registrar, resolvers keep receiving the old address from the parent. The domain can become unreachable even though your own zone is perfect. This is one of the most common and most confusing glue failures.

Parent and child NS mismatch. When the NS records at the registrar drift from the NS records at your apex, resolution may still work but delegation is in an inconsistent state that hides problems and complicates troubleshooting. Keeping them aligned is basic hygiene that is easy to let slip.

Broken or lame delegation. If a nameserver listed in the delegation no longer answers authoritatively for the zone, resolution becomes unreliable, sometimes working, sometimes not, depending on which nameserver a resolver tries. These lame delegations are notoriously hard to notice because the domain appears to work much of the time.

Delegation to a nameserver you no longer control. If a delegation or its glue points at infrastructure you have given up, it becomes a takeover risk at the delegation level, conceptually similar to the dangling-record problem but one layer higher in the hierarchy. We cover the record-level version in our guide to dangling DNS and subdomain takeover.

The DNSSEC connection. Delegation also carries the DS record that links your zone into the DNSSEC chain of trust at the parent. A DS record that does not match your zone's keys breaks validation entirely, which is one of the delegation-level failures behind the DNSSEC problems we discuss in our DNSSEC guide.

What unites these is that they are all changes at the boundary of your domain, and they all cause outsized damage relative to how rarely anyone looks at them. That is precisely the profile of something worth watching continuously rather than checking manually once a year.

Where DNS Assistant Fits

Delegation and glue are part of the DNS surface that continuous monitoring is well suited to watch, because the failure mode is a change you did not expect, at a layer you rarely inspect. DNS Assistant monitors nameserver and delegation changes and surfaces them in real time, so an unexpected change to your NS records, or a delegation that stops behaving as it should, is something you hear about promptly rather than discovering through an outage. Its NS-delegation takeover detection specifically addresses the case where a delegation points at infrastructure that could be claimed by someone else.

As with the rest of the platform, it watches and alerts rather than making changes for you: the correction, updating glue at the registrar, realigning NS records, fixing a DS record, happens in your registrar and DNS provider, and DNS Assistant's job is to make sure you know a change happened in time to act on it.

Check Your Delegation

You can inspect a domain's nameservers and delegation with the free DNS lookup tool or a Free Domain Risk Report, a good way to confirm your current delegation looks the way you expect.

To be alerted when your nameservers or delegation change unexpectedly, start free at dnsassistant.com.

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.