What Is a DNS Scanner? Checks, Findings & Tools

A DNS scanner inspects a domain’s records, subdomains, and configuration for weaknesses that expose an organization to hijacking, spoofing, and takeover. It turns one domain name into a map of connected assets, then tests that map for records pointing at services that no longer exist, missing email authentication, and nameservers configured to give away more than they need to.

Attackers work the same layer, and sometimes in places defenders never look. CloudSEK researchers documented phishing infrastructure staged across IPv6 reverse-DNS space through ip6.arpa wildcard abuse, a technique that sidesteps blocklists and conventional controls because almost nobody enumerates that address space. DNS is not a supporting service in these attacks. It is the target.

How a DNS Scanner Works

Scanning starts with a single seed domain and expands outward using public data rather than credentials or internal access, which makes it an outside-in exercise.

1. Enumerate the zone by querying authoritative nameservers for every record type, building the baseline picture of what the domain publishes.
2. Discover subdomains through Certificate Transparency logs, passive DNS databases, search engine indexes, and wordlist-based resolution, since no single source is complete on its own.
3. Resolve and classify each discovered name, identifying which point to owned infrastructure, which point to third-party services, and which resolve to nothing.
4. Test configuration for takeover conditions, email authentication gaps, DNSSEC status, and whether the nameservers answer zone transfer requests from strangers.

Certificate Transparency logs deserve particular attention as a discovery source. Every certificate issued by a publicly trusted authority is published to them, so any subdomain that has ever been given a certificate appears in a public record regardless of whether it is still linked from anywhere. That is how scanners surface dev, staging, and admin hosts that no internal inventory lists, and it is why external attack surface management treats DNS as a primary discovery layer.

DNS Scanning: What It Checks

A DNS scanner turns a single domain into a map of connected assets and then tests that map for weaknesses. The findings matter because DNS is a target in itself: 

DNS Records and Configuration

Records are the raw material a scan works from. Read together, they describe an organization’s infrastructure, vendors, and integrations, which is exactly why attackers enumerate them first.

What a domain omits matters as much as what it publishes. A missing CAA record places no restriction on which certificate authority can issue for a domain, and a missing DMARC policy leaves SPF and DKIM without enforcement. Manipulating these gaps defines a DNS attack, where traffic is blocked, redirected, or intercepted without ever touching the servers behind the names

Email Authentication Records

Whether anyone can send mail pretending to be a domain comes down to three records. A scanner checks that all three exist and that each one says something enforceable.

SPF

Sender Policy Framework lists the servers authorized to send mail for a domain. A missing record lets anyone deliver in the domain’s name, and an overly permissive one achieves much the same. Scanners flag records ending in a soft fail, which asks receivers to accept unauthorized mail and mark it, rather than reject it.

DKIM

DomainKeys Identified Mail attaches a cryptographic signature to outgoing messages, verified by receivers against a public key published in DNS. Scanners check that the selector record exists and that the key length meets current standards, since 1024-bit keys remain common and are no longer considered adequate.

DMARC

Domain-based message authentication, reporting and conformance tells receivers what to do with mail failing SPF and DKIM, and returns reports naming everyone sending under the domain. Policy strength is what a scanner reports on: a policy of p=none monitors without protecting, and only quarantine or reject stops a forged message. Domains left unprotected here become the raw material for email spoofing and wider domain spoofing campaigns.

Subdomain Discovery and Takeover Risk

Every subdomain is an asset, and the forgotten ones cause the damage. Discovery lists them; takeover testing establishes which can be stolen outright.

A takeover happens when a DNS record points to an external service that no longer exists. A CNAME aimed at a deleted cloud storage bucket or an abandoned hosting page still resolves, and anyone who registers that resource name controls the subdomain and everything a browser will trust on it. The OWASP subdomain takeover testing guide documents the conditions in detail, and dozens of SaaS providers allow the claim by design because reclaiming a released name is a normal product function.

Severity of a takeover scales with the record type involved. A dangling CNAME on a marketing subdomain lets an attacker serve phishing content under a genuine corporate name, which is a brand impersonation problem before it is a technical one. A dangling NS record hands over authority for the entire zone, letting an attacker rewrite every record beneath it. Where a takeover has already occurred, removal runs through a domain takedown process with the hosting provider or registrar.

DNS Security and Zone Exposure

Configuration of DNS itself forms the last stage of a scan, covering the protections a domain either has or lacks.

• DNSSEC status. Without cryptographic signing of records, a domain remains open to cache poisoning, where forged answers direct users to attacker-controlled destinations.
• Zone transfer exposure. A nameserver answering AXFR requests from any source hands over the complete zone file in one query, giving an attacker every record without enumeration.
• Registrar and nameserver controls. Weak registrar account protection and unlocked domains invite hijacking at the registrar level, which no record-level check detects.
• Private IP disclosure. Records resolving to RFC 1918 addresses leak internal network structure to anyone querying them.
• Wildcard records. A wildcard entry resolves every possible subdomain, which frustrates enumeration and can mask malicious hosts inside a legitimate namespace.

Registrar-level compromise sits outside what a record scan detects and produces the most severe outcome. Attackers who reach the registrar account alter nameserver delegation directly, which is the mechanism behind DNS hijacking and redirects an entire domain regardless of how well its zone is configured.

Common DNS Scan Findings

Certain findings recur across almost every estate, and each maps to a specific attack rather than to a theoretical weakness.

Reachability rather than finding type is what decides severity. A dangling record on a customer-facing subdomain warrants immediate action, while the same finding on a decommissioned internal name warrants a ticket. Scanners that rank purely by finding type rather than by reachability produce backlogs nobody works through.

Limits of DNS Scanning

A scan reads configuration rather than intent, and several conditions need human judgment before anyone acts.

Takeover detection produces false positives, because a dangling record and a temporarily unresponsive service look identical from outside. Validation before action prevents a team from deleting records for a service that was simply down. Third-party infrastructure complicates attribution too: records pointing at a CDN or SaaS platform describe configuration the organization does not control, so the finding belongs with the provider.

Configuration drift is the limitation no cadence fully removes. Records change with every infrastructure update, services get retired without their records being removed, and new subdomains appear whenever a team provisions something. A point-in-time scan begins going stale the day it completes.

Best Practices for DNS Scanning

Turning scan output into reduced exposure depends on a handful of operating habits.

• Inventory every domain first. Parked, legacy, and acquisition domains still resolve and still carry risk, and they are the ones missing from asset registers.
• Publish SPF, DKIM, and DMARC on all domains. Domains that never send mail get a deny-all SPF record and a reject policy, which closes them to spoofing entirely.
• Delete records when decommissioning services. Removing a service ends with removing the DNS entries that pointed at it, which is the step that prevents takeover.
• Publish a CAA record. Restricting which authorities can issue certificates limits mis-issuance and pairs with Certificate Transparency monitoring.
• Restrict zone transfers. AXFR answers only to authorized secondary nameservers, never to arbitrary sources.
• Scan continuously rather than periodically. DNS changes with every deployment, so scheduled scans miss the window in which most takeover risk appears.

Findings gain the right priority alongside other exposure data rather than in isolation. Feeding DNS results into external vulnerability scanning output and a broader security threat assessment places a dangling record next to the systems it could be used against.

DNS Scanning with CloudSEK BeVigil

Nobody has to deploy anything for DNS posture to decay. Records outlive the services they point to, and the risk grows in the quiet weeks when nothing changed. CloudSEK BeVigil runs DNS scanning as one of eight monitored surfaces, discovering subdomains through Certificate Transparency logs and enumeration, flagging dangling records and takeover conditions, checking SPF and DMARC posture, and surfacing private IP disclosures.

What the scanner looks for is shaped by the research behind it. The ip6.arpa investigation described earlier came from hunting phishing infrastructure in address space that conventional monitoring ignores, and findings like that inform detection rather than sitting in a report. Certificate-side exposure is covered alongside it, since the two layers fail together more than they fail separately, a relationship explored further under SSL misconfiguration.

Fixing what a scan surfaces stays with the teams owning each record. External scanning contributes the inventory and the finding, and the DNS change itself remains a registrar or hosting operation.

Conclusion

DNS carries no visible warning when it goes wrong. A dangling record resolves normally, a missing DMARC policy produces no error, and an open zone transfer answers politely to anyone who asks. Nothing breaks, which is why these findings persist for years in estates that are otherwise well managed.

Discovery is the half most organizations underinvest in. Testing configuration on the domains a team already knows about is straightforward, and the exposure sits in the subdomains nobody listed, the acquisition domains nobody migrated, and the records nobody deleted when a service was retired.

Frequently Asked Questions

What is the difference between a DNS scanner and a DNS lookup tool?

A lookup tool returns records for a name supplied to it. A scanner discovers names nobody knew existed, then tests their configuration for exploitable weaknesses.

Can a DNS scanner find subdomains that are not linked anywhere?

Yes. Certificate Transparency logs record every certificate issued, so any subdomain that has ever held one is discoverable regardless of whether anything links to it.

How is a subdomain confirmed vulnerable to takeover?

The record resolves to an external service that returns a claimable error, such as a removed cloud bucket. Confirmation requires checking whether the target resource can be registered.

Does DNSSEC prevent subdomain takeover?

No. DNSSEC authenticates that records came from the legitimate zone. A dangling record is legitimately published and correctly signed, so it passes DNSSEC validation.

Should internal DNS be scanned as well?

Yes, though the technique differs. Internal zones require queries from inside the network, since external scanning only reaches what authoritative nameservers publish publicly.

How often should DNS scanning run?

Continuously. Records change with every infrastructure update, and takeover windows open the moment a service is decommissioned while its record survives.