7 DNS Security Gaps Enterprises Still Miss in 2026, From Dangling CNAMEs to Registrar Hijacks

Every breach investigation I've sat through eventually arrives at the same uncomfortable question: who owns this DNS record? In a well-run enterprise the answer should be immediate. In practice, it triggers a round of Slack messages across the networking team, the security team, the cloud platform group, and whichever application team inherited the asset three reorgs ago. Nobody is quite sure. The record has been resolving for years, so everyone assumed someone else was watching it.

That ambiguity is the real problem. DNS sits between teams. Networking sees it as plumbing, security sees it as networking's problem, and cloud and app teams create records through automation and forget about them. The registrar account is often still tied to whoever set the company up, sometimes a marketing contractor or a founder's personal email.

It matters more now than it did two years ago. In March 2026, NIST finalized SP 800-81r3, the first update to its Secure DNS Deployment Guide since 2013. It treats DNS as a security control and a source of signals for spotting malicious activity, not just infrastructure that turns names into addresses. NIST now explicitly calls for protective DNS, encrypted DNS transport, and monitoring for problems like dangling CNAMEs and lame delegation.

This article covers the DNS security gaps I still find in nearly every enterprise environment, real incidents that show what happens when they're left open, and how to close them. I reference DNSAudit.io in places because it's a quick way to spot several of these issues, but the techniques work with any tooling.

1. Dangling DNS Records and Subdomain Takeovers

A dangling DNS record is one that still points somewhere the organization no longer controls. The classic pattern is a CNAME aimed at a cloud service that has since been decommissioned. The DNS entry survives. The backing resource does not. An attacker who notices the gap re-registers the now-available resource and inherits the subdomain.

This is the most common DNS exposure I encounter, and it's almost always a process failure rather than a technical one. The lifecycle of the cloud resource and the lifecycle of the DNS record are owned by different teams, and nobody connects them. A developer spins up an Azure App Service, points app.example.com at it via CNAME, ships the project, and moves on.

A year later, someone deletes the App Service to clean up a subscription. The CNAME is still there, in a DNS zone the developer doesn't manage and the person doing cleanup never looks at. The gap is now open, and it will stay open until someone scans for it or an attacker finds it first.

The major platforms each have their own version of the problem:

• Azure: A CNAME pointing to a deleted App Service, Traffic Manager profile, or Cloud Service (*.azurewebsites.net, *.cloudapp.net) can be reclaimed by anyone who creates a resource with the same name in their own subscription. Microsoft documents subdomain takeover as a high-severity threat in its own security fundamentals guidance, which tells you how seriously the platform owner takes it.
• AWS: S3 static-site buckets and orphaned CloudFront or Elastic Beanstalk endpoints are frequent culprits. Delete the bucket, forget the CNAME, and the globally unique bucket name is available for anyone to claim.
• GitHub Pages: A CNAME to username.github.io for a repository that was deleted or made private lets an attacker create a matching repo, add a CNAME file, and serve their own content from your subdomain. This is one of the simplest takeovers to execute, which is exactly why it's so common.
• Shopify and Zendesk: Custom storefront and helpdesk subdomains (shop.example.com, support.example.com) point to platform-owned hostnames. When the account lapses or the store closes, the target becomes claimable on those platforms.

Once an attacker controls support.example.com, they can host phishing pages on your own brand, harvest cookies scoped to the parent domain, and frequently pass domain-validated TLS certificate issuance because they legitimately control the hostname. That last point is worth dwelling on: a takeover usually comes with a valid certificate, so the padlock your users trust now belongs to the attacker.

The scale of this problem moved from theoretical to alarming in early 2025. Researchers at watchTowr identified roughly 150 abandoned Amazon S3 buckets that had previously been referenced by commercial software, open-source projects, governments, and infrastructure deployment pipelines. They re-registered the buckets, for a total of about $420, and over a two-month window logged more than 8 million HTTP requests to them, including requests for software updates, unsigned Windows, Linux, and macOS binaries, virtual machine images, and CloudFormation templates. Requests came from government and military networks in the US, UK, Australia, and elsewhere, from Fortune 100 companies, and from banks.

An official CISA web page even pointed to a patch hosted in one of the abandoned buckets. Had a malicious actor claimed these resources instead, watchTowr's CEO described the supply-chain attack potential as making SolarWinds look insignificant. The point is not the hyperbole. The point is that a dangling reference is not a low-severity hygiene issue. It is a pre-positioned distribution channel for malware that targets pull from automatically.

What Attackers See: A subdomain resolving to a CNAME whose target returns a tell-tale error: "NoSuchBucket," "There isn't a GitHub Pages site here," Shopify's "Sorry, this shop is unavailable" page, or a 404 from a deprovisioned Azure resource. That error message is the open door. Certificate transparency logs and passive DNS make finding these candidates trivial at scale, and projects like "can-i-take-over-xyz" catalog the exact fingerprints for dozens of services.

How Defenders Should Respond: Inventory every CNAME and ALIAS record, resolve each target, and confirm the backing resource still exists and is still yours. The durable fix is process: removing the DNS record must be a required, gated step in any resource teardown, not an afterthought. Where the platform supports it, use ownership-verification features (Azure's custom domain verification with asuid TXT records is a good example) so a reclaimed resource name cannot silently inherit your subdomain. Treat any record pointing at third-party infrastructure as a standing liability that needs a named owner.

DNSAudit.io flags takeover candidates by resolving each record's target and matching the response signatures against known platform fingerprints, so a scan distinguishes a healthy CNAME from one pointing at claimable infrastructure rather than simply listing your records.

2. Shadow DNS and Forgotten Assets

Dangling records are a subset of a larger problem: you almost certainly don't have a complete list of your own DNS assets. Every enterprise accumulates shadow DNS, and each forgotten entry is attack surface that nobody monitors because nobody remembers it exists.

The sources are predictable, and they map almost perfectly onto organizational seams:

• Marketing campaigns that spun up promo-summer2023.example.com on a third-party landing-page service through a contractor who has since rolled off.
• Test and staging environments like dev., uat., and staging. that expose pre-production apps with weaker controls, verbose stack traces, and sometimes real customer data copied down for testing.
• Acquisitions, where the parent inherits the target's entire DNS footprint, frequently without a clean handoff of registrar access or zone documentation. I have watched acquisition due diligence cover financials in exhaustive detail and devote not a single line to "list every domain and DNS zone this company controls, and who has the keys." Six months later, a forgotten subdomain from the acquired company becomes the initial foothold.
• Departed vendors and contractors who configured subdomains pointing at their own infrastructure that's still live in your zone.

Multi-provider DNS makes all of this worse. Most enterprises of any size run DNS across more than one provider: a corporate domain at one registrar's managed DNS, marketing properties on a CDN's DNS, a SaaS platform managing a delegated zone, plus whatever the cloud teams create in Route 53 or Azure DNS. No single console shows the whole picture. The only authoritative view of your external DNS footprint is the one assembled from outside, the same way an attacker assembles it.

In one enterprise environment I reviewed, we discovered more than 400 active subdomains that nobody could confidently identify an owner for. The technical cleanup took days. The ownership conversations took weeks. That ratio is the part most teams underestimate: finding the records is a scanning problem you can solve in an afternoon, but deciding whether a given subdomain is safe to retire means tracking down a team that may have been reorganized out of existence, and that is a human problem with no API.

What Attackers See: Your complete external DNS surface, built from certificate transparency logs, passive DNS databases, and subdomain enumeration. They don't need your asset inventory. They build their own, and it is frequently more complete than yours because they're motivated to finish it and you have other priorities.

How Defenders Should Respond: Establish a single source of truth for DNS assets and reconcile it against what's actually resolvable from the outside, across every provider. After any acquisition, treat DNS inventory as a day-one integration task with a named owner, not a cleanup item for next quarter. Decommission test environments aggressively and remove their records as part of teardown. The goal is to make your internal asset list match the external reality, then keep it matching.

Here's where it helps to look at DNS as part of your attack surface. DNSAudit.io enumerates the records and subdomains associated with a domain and presents them in one view, so you end up with an actual list to go through instead of a guess. Its Subdomain Finder and DNS Record Lookup tools are a good place to start if you're building that inventory from scratch.

3. Email Authentication Weaknesses

Email authentication lives entirely in DNS, and it's where I see the highest density of misconfigurations in real scans. SPF, DKIM, and DMARC are DNS records that tell receiving mail servers whether a message claiming to be from your domain is legitimate.

Get them wrong and you've left the door open for spoofing and business email compromise, consistently among the most expensive attack categories in any incident-cost survey. The FBI's IC3 has tracked billions of dollars in annual BEC losses, and email remains the primary delivery vector for those attacks.

SPF (Sender Policy Framework) lists which servers may send mail for your domain. The most common mistakes: exceeding ten DNS lookups in the record, which causes a permerror and unpredictable handling; publishing multiple SPF records on one domain, which is invalid per the specification; and ending with +all, which authorizes the entire internet.

DKIM (DomainKeys Identified Mail) signs messages with a private key and publishes the public key in DNS. Mistakes here include keys shorter than 1024 bits, test-mode selectors (t=y) left enabled in production, and orphaned selectors for mail providers you've stopped using but never removed.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together with alignment checks and tells receivers what to do with failures. This is where the largest gap hides, and the data is stark. EasyDMARC's 2026 analysis of 1.8 million high-traffic domains found DMARC adoption had climbed past 52%, but more than half a million of those domains were still published at p=none, the monitoring-only policy that instructs receivers to take no action on failures. Adoption is surging while protection is not, largely because Google, Microsoft, and Yahoo bulk-sender requirements pushed organizations to publish a record without pushing them to enforce it. A record at p=none looks like DMARC in a checklist. It enforces nothing. An attacker spoofing your domain sails through.

The business impact is direct. A spoofed message from your CEO's address requesting a wire, or from your billing domain requesting updated payment details, succeeds far more often when DMARC isn't enforcing, because as far as the receiving server can tell from your DNS, the message is authorized. The mandate-driven data backs this up: jurisdictions that enforced DMARC saw phishing success rates fall sharply, while non-enforcing populations saw them climb.

What Attackers See: A domain with v=DMARC1; p=none is a green light to send mail as that domain and reach inboxes. SPF records that error out or end in ~all without DMARC enforcement give them the same opening.

How Defenders Should Respond: Move DMARC from p=none to p=quarantine and then p=reject, using aggregate (rua) reports during a monitoring window to confirm you won't break legitimate senders. Publish a rua tag if you haven't; a large share of DMARC-enabled domains lack one, which means flying blind. Keep SPF under the ten-lookup limit by flattening or consolidating includes. Use at least 2048-bit DKIM keys, rotate them, and remove selectors for retired providers.

DNSAudit.io checks SPF, DKIM, and DMARC together and explicitly flags the p=none trap rather than marking the record as merely present. In a scan response, a DMARC finding with a "warning" status and a note that the policy is set to none is the signal to act on, because it separates "configured" from "actually protecting you."

4. Delegation and Nameserver Misconfigurations

Delegation is how the DNS hierarchy hands authority for your zone to your nameservers. When delegation is broken or stale, you get intermittent resolution failures that are maddening to diagnose and, worse, security exposure that's easy to overlook.

Three patterns recur:

• Stale NS records: The delegation at your registrar still lists a nameserver you stopped using, or your zone's own NS records don't match what the parent publishes. Resolvers may query a server that no longer holds your zone, producing inconsistent answers depending on which nameserver they reach.
• Broken delegation chains (lame delegation): A nameserver is listed as authoritative for your zone but doesn't actually answer authoritatively for it, usually because the zone was removed from that server without removing it from the delegation. NIST SP 800-81r3 specifically calls out lame delegation exploitation as a risk warranting proactive monitoring.
• Missing glue records: When your nameservers live inside the zone they serve (ns1.example.com for example.com), the parent must publish glue records (the nameserver IP addresses) to break the circular dependency. Missing glue causes resolution failures and slow lookups.

The security dimension is the one teams miss. A nameserver listed in your delegation but pointing to infrastructure you no longer control is the nameserver-level equivalent of a dangling record, and it's far more dangerous. The conference research community has demonstrated NS-record takeovers stemming from exactly this pattern, often introduced by copy-pasted infrastructure-as-code that references a DNS provider account someone forgot to provision. An attacker who claims that infrastructure can answer DNS queries authoritatively for your entire zone. That's not one subdomain. That's everything: web, mail, the lot.

What Attackers See: A delegation pointing to a nameserver hostname or IP that's expired, parked, or claimable. Claiming it means answering DNS for your zone. It's the highest-value DNS takeover there is.

How Defenders Should Respond: Confirm the NS records at your registrar (the parent delegation) exactly match the NS records in your zone. Remove retired nameservers from the delegation before decommissioning the servers, not after. Verify glue records exist and are correct for in-zone nameservers. Re-check after every provider migration, because migrations are when these mismatches are introduced.

DNSAudit.io's Nameserver Configuration Analyzer and Zone Transfer Test check for these: mismatched delegation, lame nameservers, missing glue, and zones that improperly allow AXFR transfers, which leak your entire record set to anyone who asks.

5. DNSSEC Adoption Gaps

DNSSEC adds cryptographic signatures to DNS records so resolvers can verify that an answer genuinely came from the zone's owner and wasn't tampered with in transit. Without it, DNS responses are trust-on-faith, which is what makes cache poisoning and on-path manipulation possible. With it, a forged answer fails validation and gets rejected. NIST SP 800-81r3 continues to recommend DNSSEC for protecting the integrity and authenticity of authoritative DNS data.

Adoption remains stubbornly low at the zone level, and that's the gap most relevant to enterprises. Roughly 36% of internet users sit behind validating resolvers, but only around 7% of delegations are securely signed, per APNIC's 2025 measurements, and only about 5% of .com domains are signed. The global infrastructure (the root and most TLDs) is signed and mature. Your individual domains, internal and external, are far more likely to be the unsigned weak link, and attackers increasingly fingerprint where DNSSEC is and isn't deployed.

Where DNSSEC does exist, it's often misconfigured. Academic measurement studies have repeatedly found that over 30% of signed domains fail to upload their DS records to the parent, which means they get the operational cost of signing with none of the protection, because nothing actually validates. The common deployment mistakes:

• Expired signatures (RRSIG records): Signatures have validity windows and must be re-signed on schedule. Miss the rollover and the domain doesn't just lose DNSSEC, it goes dark for every validating resolver. Records fail validation and resolution stops.
• Broken chain of trust: The DS record at the parent must match the active DNSKEY. After a key rollover, if the DS isn't updated at the registrar, validation breaks.
• Partial deployment: Signing the zone but never publishing the DS record means it looks deployed internally and protects nothing externally.

Why do organizations still get this wrong? Because DNSSEC's failure mode is severe and self-inflicted, and teams that aren't confident in their automation reasonably fear it more than the threats it mitigates. The fear is not irrational.

On May 5, 2026, a botched Zone Signing Key rollover at DENIC produced a malformed signature for the entire .de zone, and roughly 17.7 million domains became unreachable for validating resolvers worldwide. It didn't matter that the affected sites' own servers, CDNs, and certificates were perfectly healthy.

A single bad signature at the TLD level took them all offline simultaneously, and the domain owners had zero control over the fix. Slack hit the same wall from the other direction: its September 30, 2021 outage was, by the company's own account, the third failed attempt to enable DNSSEC on slack.com. These incidents are not arguments against DNSSEC. They're arguments for operating it with the discipline it demands.

What Attackers See: An unsigned domain is a candidate for cache poisoning and on-path answer manipulation, redirecting users to attacker infrastructure while the domain in the browser stays unchanged. A domain with broken DNSSEC may already be failing for a meaningful share of users.

How Defenders Should Respond: Deploy DNSSEC with automated signing and key management rather than manual processes, which are where the catastrophic rollover failures originate. Monitor RRSIG expiration as a hard, paging alert. Confirm the DS record at the parent matches your active key after every rollover. Validate the full chain with DNSViz or Verisign's DNSSEC debugger before resolvers do it for you. And if you operate your own validating resolvers, confirm they trust the new root KSK (KSK-2024) before ICANN's October 11, 2026 rollover so your trust anchors don't go stale. If you're not ready to run DNSSEC reliably, build that capability first, because half-deployed DNSSEC is worse than none.

DNSAudit.io validates the full DNSSEC chain rather than just checking whether signing is enabled, so a scan distinguishes "properly configured" from "signed but the chain of trust is broken."

6. Registrar Security: The DNS Layer Most Organizations Ignore

Everything above assumes the attacker is working at the DNS-record level. There's a layer beneath that, and it's the one I find most neglected in enterprise environments: the registrar account that controls the domain itself. You can run flawless DNS, enforce DMARC, and sign every zone with DNSSEC, and none of it matters if an attacker can log into your registrar and repoint the entire domain in ninety seconds.

The registrar layer is neglected for a structural reason. Domains are often registered years before a security program exists, by a founder, an office manager, or an outside agency, using a personal email address and a shared password. That account then quietly controls the company's most critical asset while sitting entirely outside the controls security applies to everything else. The problems I see repeatedly:

• Missing MFA. The registrar account protecting a company's entire online presence is frequently secured by a password alone, sometimes one that's been reused elsewhere and is already in a breach corpus.
• Shared credentials. A single login shared across a team, with no individual accountability and no way to revoke one person's access when they leave.
• Excessive administrative access. Everyone who has ever needed to add a DNS record retains full account control, including the ability to transfer the domain away.
• No Registry Lock. Registrar-level transfer locks help, but they live in the same account an attacker is trying to compromise. Registry Lock operates one level up, at the registry, and requires manual out-of-band verification before any change to nameservers, transfers, or contacts. It assumes the registrar account can be breached and prevents that breach from escalating to domain-level impact.

In a lot of these cases the way in is social engineering, not a technical exploit. In November 2020, attackers compromised the cryptocurrency exchange Liquid.com by socially engineering employees at its registrar, GoDaddy, who were tricked into transferring control of the account and domain to the attacker. With that control, the attacker rewrote DNS records, took over internal email, and reached the company's document storage. The same campaign hit several other crypto services through the same registrar. Perl.com was hijacked through registrar-level manipulation and briefly listed for sale at $190,000. It keeps happening because companies spend a lot on app and network security and barely think about who can get into the registrar account.

Why do attackers target the registrar? Because it's the single point from which they control everything downstream, and because the change they make is legitimate from the infrastructure's perspective. Users type the correct domain and are silently sent to attacker infrastructure. DNSSEC won't save you, because the attacker controls the zone and can re-sign it. The compromise happened above the layer your defenses operate in.

What Attackers See: A registrar account with no MFA, a contact email they can phish, and support staff who can be talked into a change. Or a domain without Registry Lock, where compromised credentials translate immediately into a nameserver rewrite. They also look for the easier sibling: even when the registrar is locked down, the DNS provider account the registrar delegates to (Route 53, Cloudflare, NS1, a self-hosted BIND server) often has weaker controls, and rewriting A, MX, and TXT records there achieves the same result without touching the registrar.

How Defenders Should Respond: Enforce phishing-resistant MFA on both the registrar account and the DNS provider account. Get rid of shared logins and give each person their own account with only the access they need, and audit who has it. Enable Registry Lock on your most critical domains so changes require out-of-band approval. Keep WHOIS and registrar contact details accurate and respond promptly to verification emails, since ignoring them can get the domain suspended. Set alerting on contact changes, nameserver changes, and transfer requests, and send those alerts somewhere outside the registrar account, so whoever gets in can't just turn them off.

7. Continuous DNS Security Monitoring

Here's the structural problem with how most enterprises handle everything above: they check it once. An annual audit, a migration-time review, a penetration test that happens to include DNS. Then nothing until next year.

DNS doesn't hold still for a year. A marketing team spins up a subdomain on Tuesday. A cloud resource is deleted on Thursday, turning a healthy CNAME into a dangling one. A DNSSEC signature expires over a holiday weekend. A vendor changes their platform hostnames. A registrar contact email lapses. Each event opens a gap, and the average gap stays open until the next scheduled review, which might be eleven months away. The watchTowr buckets had been abandoned for months and years before anyone noticed. Attackers operate continuously; point-in-time audits are a snapshot of a moving target.

The same visibility required to identify dangling records and weak delegation is increasingly required to detect active DNS abuse. During my doctoral research into DNS Water Torture attacks, where attackers flood authoritative servers with queries for random, non-existent subdomains of a target zone, one lesson recurred: organizations often lacked sufficient DNS telemetry to distinguish normal traffic from malicious behavior until availability had already been impacted. By the time the resolver cache-miss rate spiked and the authoritative servers started shedding load, the attack had already been going for a while. The signs were in the DNS queries from the start, but nobody was looking at them. And this goes beyond that one type of attack. Misconfiguration and abuse both hide in DNS traffic that no one is instrumented to see, and if you're not collecting DNS data, you won't get alerts from it either.

What works is treating DNS the same way you treat any other monitored attack surface: scan continuously, alert on changes, and integrate the results into systems your team already uses. For that you need an API. NIST SP 800-81r3 goes in the same direction, treating DNS as a security control and a source of signals, not just infrastructure. Checking it once a year doesn't really count as a control.

DNSAudit.io exposes a REST API (access is enabled per account for registered users) so you can plug DNS scans into scheduled jobs, CI/CD pipelines, and your SIEM or ticketing workflow. So instead of someone having to remember to run a scan, you set up a nightly job that calls the API, compares the results with the last scan, and opens a ticket if the score drops or a new critical issue shows up.

What Attackers See: Nothing changes for them. They're already continuous. The asymmetry only closes when your monitoring matches their tempo.

How Defenders Should Respond: Automate. Schedule scans against your domains, diff results against the previous run, and alert on regressions. Wire critical findings into your existing incident workflow so a dangling record, a broken DNSSEC chain, or an unexpected nameserver change becomes a tracked ticket, not a line item in next year's audit.

8. DNSAudit.io API Examples

The DNSAudit.io API uses a single API key passed in the X-API-Key header, with all endpoints served from https://dnsaudit.io/api. A scan runs over two dozen security checks (DNSSEC, SPF/DKIM/DMARC, zone transfer tests, takeover candidates, and more) and returns structured JSON. Below are the building blocks for automation.

Initiating a scan

curl -X GET "https://dnsaudit.io/api/v1/scan?domain=example.com" \\
  -H "X-API-Key: your-api-key"

Sample scan response

{
  "status": "complete",
  "domain": "example.com",
  "scanDate": "2026-06-09T14:30:00.000Z",
  "securityScore": 85,
  "grade": "B+",
  "summary": {
    "criticalIssues": 0,
    "warnings": 3,
    "passed": 23
  },
  "results": {
    "spf": {
      "status": "pass",
      "record": "v=spf1 include:_spf.google.com \~all",
      "details": "Valid SPF record found"
    },
    "dmarc": {
      "status": "warning",
      "record": "v=DMARC1; p=none",
      "details": "DMARC policy set to none - consider quarantine or reject"
    },
    "dnssec": {
      "status": "pass",
      "details": "DNSSEC is properly configured"
    }
  }
}

Retrieving full findings as JSON

For integrating complete results into a dashboard or compliance report:

curl -X GET "https://dnsaudit.io/api/export/json/example.com" \\
  -H "X-API-Key: your-api-key"

Reviewing scan history

curl -X GET "https://dnsaudit.io/api/v1/scan-history?limit=20" \\
  -H "X-API-Key: your-api-key"

Filtering for high-risk issues

The API returns every check, so filtering happens client-side: walk the results object and keep anything with a status of warning or fail, and read summary.criticalIssues as your top-line alert trigger. The Python example does exactly that.

Python automation example

This script scans a list of domains, extracts only the findings that need attention, and prints a concise risk report. Drop it into a nightly cron job and pipe the output to your alerting channel.

import time
import requests
 
API_KEY = "your-api-key"
BASE_URL = "https://dnsaudit.io/api"
 
def scan_domain(domain):
    response = requests.get(
        f"{BASE_URL}/v1/scan",
        params={"domain": domain},
        headers={"X-API-Key": API_KEY},
        timeout=60,
    )
    # Respect the documented burst limit (HTTP 429).
    if response.status_code == 429:
        wait = int(response.json().get("retryAfter", 45))
        time.sleep(wait)
        return scan_domain(domain)
    response.raise_for_status()
    return response.json()
 
def high_risk_findings(scan):
    """Return only checks that failed or raised a warning."""
    flagged = []
    for check, data in scan.get("results", {}).items():
        if isinstance(data, dict) and data.get("status") in ("warning", "fail"):
            flagged.append({
                "check": check,
                "status": data["status"],
                "details": data.get("details", ""),
            })
    return flagged
 
def report(domains):
    for domain in domains:
        try:
            scan = scan_domain(domain)
        except requests.HTTPError as e:
            print(f"[{domain}] scan failed: {e}")
            continue
 
        summary = scan.get("summary", {})
        print(f"\\n{domain}  score={scan.get('securityScore')} "
              f"grade={scan.get('grade')} "
              f"critical={summary.get('criticalIssues', 0)}")
 
        for finding in high_risk_findings(scan):
            print(f"  [{finding['status'].upper()}] "
                  f"{finding['check']}: {finding['details']}")
 
if __name__ == "__main__":
    report(["example.com", "mysite.org"])

Conclusion

The gaps in this article (dangling records, shadow assets, weak email authentication, broken delegation, half-deployed DNSSEC and neglected registrar accounts) come from the same place. DNS changes all the time, it sits between teams, and almost nobody is watching it change. Attackers are, though. Mapping a DNS footprint and probing it for abandoned resources is cheap and easy to automate, and cases like the watchTowr buckets and the Liquid.com hijack are what happens when nobody on the defending side looks.

NIST's 2026 guidance treats DNS as a security control, and in practice that means checking it all the time, not once a year. Start by scanning your main domain. From there, build out the inventory, fix what gets flagged, lock down the registrar account, and set up the re-checks so they run on their own. None of it is exciting work, but it's what closes the gaps attackers keep using.

If you want extended DNS and domain scans and more features, you can create a free account.