What is DNS and SSL Scanner? How Each Scan Works

A DNS scanner inspects a domain's records, subdomains, and configuration for weaknesses. An SSL scanner inspects the certificates and encryption settings a site presents to visitors.

Together, the two cover the trust layer of the internet. DNS decides where a name points, and SSL proves the destination is genuine and encrypts the connection to it. A browser checks both before it trusts a site, and so does an attacker looking for a way in.

Scanning this layer means answering a short list of questions. Which records and subdomains exist, which of them are misconfigured or abandoned, which certificates are weak or about to expire, and what does all of it look like from the outside?

Why DNS and SSL are Scanned Together

The two layers are tied at the root: every certificate is issued for a domain name. Certificate Transparency logs are the public record of every certificate issued by trusted authorities. They double as a primary source for discovering an organization's subdomains.

Control flows the other way too. A CAA record, a DNS entry, declares which certificate authorities are allowed to issue certificates for a domain, so DNS configuration directly governs certificate issuance.

Findings straddle the boundary constantly. A forgotten subdomain with an expired certificate is one asset failing on both layers at once. Scanning the layers together is the only way to see it whole.

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: a DNS attack manipulates the naming system to block, redirect, or intercept traffic without ever touching the servers behind it.

DNS Records and Configuration

Records are the raw material of DNS scanning. A and AAAA records reveal server addresses, MX records reveal mail providers, NS records reveal DNS hosting, and CNAME records reveal the SaaS platforms and CDNs a domain depends on.

TXT records round out the picture with verification strings and email policies. Read together, the records describe an organization's infrastructure, vendors, and integrations, which is exactly why attackers enumerate them first.

Email Authentication Records

Three DNS records decide whether anyone can send email pretending to be a domain. A scanner checks that all three exist and says something sensible.

SPF

The Sender Policy Framework record lists the servers allowed to send mail for a domain. A missing or overly loose SPF record lets anyone deliver mail in the domain's name.

DKIM

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. Receiving servers use the public key in DNS to confirm a message was not forged or altered in transit.

DMARC

Domain-based Message Authentication, Reporting, and Conformance tells receivers what to do with mail that fails SPF and DKIM checks. It sends reports on who is spoofing the domain too. Without a DMARC policy set to quarantine or reject, the other two records carry little enforcement weight.

Subdomain Enumeration and Takeover

Every subdomain is an asset, and forgotten subdomains are the ones that hurt. A scanner finds them, then tests whether any can be stolen.

Subdomain Discovery

Discovery combines Certificate Transparency log searches with enumeration techniques to list every subdomain tied to a domain. The output routinely includes dev, staging, and admin subdomains that the security team never knew were public.

Subdomain Takeover

A takeover happens when a DNS record points to an external service that no longer exists. A CNAME aimed at a deleted cloud bucket or an abandoned hosting page still resolves. An attacker who registers that resource controls the subdomain, a risk that the OWASP subdomain takeover testing guide documents in detail. Scanners hunt for these dangling records. Severity peaks with NS records, where a takeover hands over the entire DNS zone.

DNS Security and Zone Exposure

DNS scanning finishes with the configuration of DNS itself. Missing DNSSEC, the extension that cryptographically signs records, leaves a domain open to cache poisoning, where forged answers send users to fake sites. Weak registrar and nameserver controls invite DNS hijacking, where attackers alter queries or settings to redirect users to malicious destinations.

Zone transfer settings get tested too. A nameserver that answers AXFR requests from anyone hands out the complete zone file, giving an attacker every record in one download.

SSL/TLS Scanning: What It Checks

An SSL scan opens a real encrypted connection to a host and grades everything it observes. The checks fall into three groups: the certificate, the encryption, and the issuance record.

Certificate Validity and Trust

The certificate is the identity document of a site, and scanners read every field of it.

Expiry and Renewal

An expired certificate is an outage. Every visitor hits a full-screen browser warning at once, and API clients that validate certificates simply stop connecting. Certificate lifetimes are shrinking toward 90 days. That moves the real risk from a missed renewal to renewal automation breaking quietly, so scanners track the days remaining on every certificate.

Chain, Hostname, and Issuer

A certificate has to be served with its full chain of intermediates, match the hostname it protects through its Subject Alternative Names, and come from a trusted authority. Scanners flag incomplete chains, name mismatches, and self-signed certificates. Each one breaks trust for a clean client, even when the certificate itself is fine.

Protocol and Cipher Strength

A perfect certificate can still sit on a weak connection. TLS 1.0 and 1.1 were formally deprecated by the IETF in 2021. NIST guidance on TLS sets TLS 1.2 as the minimum secure version, with TLS 1.3 support expected. Scanners test which protocol versions a server accepts and flag the deprecated ones. Old protocols enable downgrade attacks with names like POODLE and BEAST.

Cipher suites get the same treatment. Weak algorithms such as RC4 and 3DES are flagged, along with older CBC constructions, even when strong options sit beside them. A server that offers a weak cipher can be forced onto it.

Certificate Transparency Monitoring

Certificate Transparency logs record every certificate issued by publicly trusted authorities. Monitoring them answers a question no local check can: has anyone issued a certificate for this domain that the organization never requested?

An unexpected certificate in the logs signals either a certificate authority error or an active impersonation attempt. Pairing CT monitoring with a CAA record closes the loop. The DNS record restricts who is allowed to issue, and the log reveals anyone who did.

Common DNS and SSL Findings

The two scans produce a shared queue of findings. These appear most often, and each maps to a concrete attack or outage.

Severity varies by exposure. A weak cipher on an internal test host matters less than a dangling record on a customer-facing subdomain, and good scanners rank accordingly.

Limits of DNS and SSL Scanning

A scan reads configuration, not intent, and the trust layer has quirks that demand judgment. CDNs and load balancers can serve certificates on infrastructure that the organization does not control. A weak protocol finding sometimes belongs to a provider rather than a server; the team can fix it directly.

Takeover detection produces false positives that need manual validation before anyone acts. Above all, this layer drifts on its own. Certificates age toward expiry, records rot as services are retired, and a point-in-time scan starts going stale the day it runs.

Best Practices for DNS and SSL Scanning

Continuously verify DNS posture and certificate health across domains, APIs, and supporting subdomains. The habits below turn that principle into routine.

• Inventory every domain first. Parked, legacy, and acquisition domains still resolve and still carry risk.
• Automate certificate renewal and alerting. Alert well before expiry and treat a failed renewal as an incident, not a reminder.
• Enforce TLS 1.2 as the floor. Disable SSLv3, TLS 1.0, and TLS 1.1 everywhere, and remove weak ciphers rather than ranking them last.
• Set SPF, DKIM, and DMARC on every domain. Domains that never send mail get a deny-all SPF record and a reject policy, closing them to spoofing.
• Remove dangling records promptly. Decommissioning a service ends with deleting the DNS records that pointed at it.
• Monitor CT logs continuously. A certificate the organization never requested warrants investigation the day it appears.
• Fold findings into wider scanning. DNS and certificate issues gain the right priority alongside external vulnerability scanning results, where exposure decides priority.

Catch Expiring Certificates and Hijackable Subdomains with CloudSEK BeVigil

The trust layer decays without anyone deploying a thing. Certificates march toward expiry on their own schedule, and DNS records outlive the services they point to, so the risk grows in the quiet weeks when nothing changed.

CloudSEK BeVigil watches both layers from the outside, continuously. Its DNS scanning discovers subdomains through Certificate Transparency logs and enumeration, flags dangling records and takeover risk, and checks SPF, DKIM, and DMARC posture. Its SSL scanning tracks certificate expiry across every discovered asset, tests for deprecated protocols and weak ciphers, and surfaces certificates issued for the organization's domains without its knowledge.

The research behind the platform runs deep on DNS abuse. An investigation by CloudSEK into ip6.arpa wildcard abuse exposed attackers staging phishing infrastructure across IPv6 reverse-DNS space. The technique sidesteps blocklists and traditional controls entirely. That research depth shapes what the scanner looks for: the expiring certificate gets caught before the outage, and the dangling record gets removed before anyone claims it.

Frequently Asked Questions

What does a DNS and SSL scanner do?

A DNS scanner checks a domain's records, subdomains, and email authentication for misconfigurations, while an SSL scanner checks certificates, protocols, and ciphers for weaknesses. Together, they audit the trust layer that attackers probe first.

What is subdomain takeover?

Subdomain takeover happens when a DNS record points to a deleted external service, like a removed cloud bucket, and an attacker registers that resource. The attacker then controls the subdomain and can serve phishing content from it.

How do you check if an SSL certificate is expired or weak?

An SSL certificate checker opens a live connection to the host and reads the certificate's expiry date, chain, and hostname coverage. It then tests which protocols and ciphers the server accepts. Expired certificates and deprecated protocols are flagged immediately.

What are SPF, DKIM, and DMARC?

They are three DNS records that authenticate email. SPF lists the servers allowed to send for a domain, DKIM signs messages cryptographically, and DMARC sets the policy for mail that fails both checks.

What is Certificate Transparency monitoring?

Certificate Transparency monitoring watches the public logs of every issued certificate for entries covering an organization's domains. A certificate the organization never requested signals a certificate authority error or an impersonation attempt.

How often should you scan DNS and SSL?

Continuously. Certificates move toward expiry every day, records change with every infrastructure update, and new certificates for a domain can be issued at any time, so continuous monitoring beats any scheduled scan.