Table of Contents
DNS misconfigurations are everywhere. After scanning thousands of domains with DNSAudit.io, I kept running into the same issues I first saw more than twenty years ago when I was managing Linux servers. Old records, forgotten services, misconfigured email setups, and sensitive subdomains that never should have been public. These problems look small, but they create real opportunities for attackers.
Recent research shows the same trend at a global scale. In the OWASP Top 10:2025 list, Security Misconfiguration moved from number 5 in 2021 to number 2 in 2025, and about 3 percent of the applications tested had at least one misconfiguration in this category. Another study scanning more than 353 million domain names found that 381,965 of them accepted DNS dynamic updates with no authentication at all.
Seeing these numbers match what I keep finding in my own scans made something very clear to me. DNS misconfigurations are not rare, and they have been repeating for decades. So I put together the top 10 issues I see the most often, explained in simple terms with examples, so anyone can understand what to look for and why these problems matter.
Top 10 DNS Misconfigurations Explained
1. Broken or conflicting SPF records
SPF is extremely fragile. A single provider change, two SPF entries by mistake, or too many lookup calls can break the rule entirely. When SPF is broken, your domain loses one of its main protections against spoofing. Attackers can send emails that look like they came from you, and most people will not notice anything is wrong.
Example:
TXT "v=spf1 include:_spf.google.com ~all"
TXT "v=spf1 include:_spf.sendgrid.net -all"Why this is a problem:
Having two SPF records instantly invalidates SPF. Email receivers stop evaluating them because only one SPF record is allowed per domain.
Quick fix:
Merge all providers into a single SPF entry and delete duplicates.
2. MX servers with weak or missing email authentication
A domain can have functional MX records but still offer zero email protection. If SPF is weak, DKIM is not configured, or DMARC is missing, attackers can impersonate your domain from anywhere. Many phishing campaigns start exactly this way because the DNS setup allows it.
Example:
MX 10 mail.example.com
TXT "v=spf1 ?all"Why this is a problem:
"?all" tells receivers to accept any server as legitimate. It makes SPF useless and allows attackers to spoof your domain without restriction.
Quick fix:
Use a strict rule like "-all" or "~all", and configure DKIM plus a proper DMARC policy.
3. TXT records filled with random or oversized data
TXT records are often used as a dumping ground for leftover strings, old service verification tokens, testing data, or abandoned configurations. In some cases, the content is suspicious or encoded in a way that does not match any legitimate tool. These records can leak information or indicate the presence of malware staging.
Example:
TXT "8721hj2h18h1289h12h98hj12h9812h9812h981…"Why this is a problem:
Random or meaningless strings often indicate leftover test data or, in some cases, encoded payloads used by malware to hide configuration data inside TXT records.
Quick fix:
Remove any TXT record you cannot identify or map to a legitimate service.
4. Exposed sensitive subdomains
Many organizations unintentionally expose subdomains that reveal internal systems, tools, or environments. Even when these do not resolve publicly, the names alone give attackers useful insight into how your infrastructure is built and where weak points might be. This is one of the most common issues I see.
Examples:
admin.example.com
backup-db.example.com
internal-api.example.com
dev-auth.example.com
vpn-old.example.comWhy this is a problem:
Even if these hosts do not resolve, their names reveal internal tools, environments, and operational patterns that attackers can pivot on during reconnaissance.
Quick fix:
Delete unused subdomains and rename sensitive ones to generic labels where possible.
5. Dangling subdomains pointing to deleted cloud services
This is still one of the simplest takeover paths on the internet. A cloud bucket, app, CDN distribution, or SaaS integration is removed, but the DNS record remains. Anyone can recreate the missing resource and instantly control the subdomain.
Example:
blog CNAME blog-example.s3.amazonaws.comWhy this is a problem:
If the S3 bucket no longer exists, an attacker can recreate it and hijack "blog.example.com" instantly.
Quick fix:
Remove the CNAME if the service is gone, or recreate the resource yourself to keep control.
6. Wildcard DNS records that expose everything
Wildcard DNS records are usually created for testing and forgotten. They cause every subdomain to resolve, including ones that were never meant to exist. This can expose internal traffic, create unexpected behavior, and give attackers a way to probe deeper into your environment.
Example:
* A 34.120.50.23Why this is a problem:
This makes every possible subdomain point to that IP. Attackers can probe fake subdomains and reach your server, revealing behavior or services you didn't know were exposed.
Quick fix:
Remove wildcard A records unless you have a very specific use case that requires them.
7. Old nameservers that no one maintains anymore
Nameservers tend to be forgotten after migrations. Many domains still point to old hosting companies or providers that no longer manage their DNS. These nameservers might return outdated data, become unreliable, or reveal information you no longer intended to expose.
Example:
NS ns1.oldprovider.net
NS ns2.oldprovider.netWhy this is a problem:
Old nameservers may serve outdated data, reveal previous infrastructure, or even be taken over if the provider no longer exists.
Quick fix:
Update NS records so they point only to your current DNS provider.
8. Missing DNSSEC where integrity matters
DNSSEC is not required for every domain, but for login pages, financial services, and anything sensitive, skipping it leaves room for manipulation under certain conditions. It adds a layer of trust to DNS that prevents some forms of tampering.
Example check result:
no RRSIGs foundWhy this is a problem:
This means your zone is unsigned. Anyone in a position to intercept traffic can tamper with DNS responses for sensitive services.
Quick fix:
Enable DNSSEC at your registrar and confirm the DS record is published correctly.
9. Leftover DNS records from old infrastructure
These are extremely common. Old A records or CNAMEs that pointed to long gone servers, staging systems that no longer exist, or previous environments that were never fully cleaned up. They leak information about how your infrastructure used to work and sometimes allow attackers to recreate or abuse what was once there.
Example:
staging A 192.168.10.55Why this is a problem:
This exposes an internal IP that should never appear in public DNS, and it reveals details about old environments attackers can mimic.
Quick fix:
Remove records pointing to private IP ranges or unused servers.
10. TXT records being used as a hidden channel for malware
DNS TXT records support long strings, which is why some malware families use them to store configuration data, encoded payloads, or small commands. Most companies never inspect their TXT records, so attackers treat them as a quiet communication channel.
Example:
TXT "powershell -enc JAB3AG…"Why this is a problem:
This is a classic sign of encoded commands. Several malware families store configuration or payloads in DNS TXT records this way.
Quick fix:
Delete suspicious TXT records and review server logs related to the domain.
Bonus: Long CNAME chains that break easily
CNAME chains stack up when multiple services depend on each other. A change or outage in just one provider can break the whole chain, and the structure itself often exposes the layers behind your domain.
Example:
cdn.example.com CNAME cdn.hosting.net
cdn.hosting.net CNAME edge.serviceprovider.ioWhy this is a problem:
Two or more chained CNAMEs increase lookup time and create single points of failure. If one provider breaks, everything downstream fails.
Quick fix:
Flatten long chains by pointing directly to the final destination whenever possible.
How to fix all of this
The easiest way to deal with these issues is to run a DNSAudit.io scan. It checks for all the problems above, shows the exact records involved, and explains what should be updated or removed in simple language. It is the quickest way to clean up DNS zones that have not been reviewed in a long time.
Conclusion
Keeping DNS healthy is not a one-time task. Records change, services move, cloud providers get replaced, and small gaps turn into real security risks when no one is watching.
After seeing the same problems appear across so many domains, it's clear that most teams aren't dealing with DNS issues because they don't know they exist. A simple audit is usually all it takes to uncover years of leftovers, misconfigurations, or silent exposures.
If you want a quick way to get ahead of these problems, run a scan on DNSAudit.io and see what your own domain is really exposing. It's fast, free, and gives you a clear plan to tighten everything up before an attacker even looks in your direction.
