A normal week at a big company, DNS wise:
1. monday marketing spins up a subdomain for a campaign
2. wednesday someone deletes an old cloud app and forgets the CNAME
3. saturday a DNSSEC signature expires and nobody's around
And the next DNS review is... next year? maybe
@enrique_somoza has a part about this in his article and I laughed a bit because it's exactly how it goes everywhere. nothing fancy, just how it works!
DNS changes constantly and almost nobody is watching it change. attackers are though, it's cheap for them to automate
In the article he wrote for https://t.co/7i64HAItu9, he goes through 7 of these gaps, how to fix each one, and there's API stuff at the end if you'd rather have scans running on their own than rely on someone remembering
How often does your team actually look at your DNS? once a year? never?
Check this out ๐
https://t.co/eS95MT4vAr
#DNS #DNSSecurity #CyberSecurity #AttackSurfaceManagement #InfoSec
~150 abandoned S3 buckets. About $420 to re-register them. Over 8 million requests in two months, some from government and military networks asking for software updates.
That was watchTowr's research in 2025, and it's one of the cases @enrique_somoza walks through in his new article for us, along with the .de DNSSEC outage in May and the Liquid[.]com registrar hijack.
7 DNS gaps that still show up in big orgs, and how to close each one ๐
https://t.co/nPocViVMbv
#DNS #DNSSecurity #DMARC #DNSSEC #AttackSurface
~150 abandoned S3 buckets. About $420 to re-register them. Over 8 million requests in two months, some from government and military networks asking for software updates.
That was watchTowr's research in 2025, and it's one of the cases @enrique_somoza walks through in his new article for us, along with the .de DNSSEC outage in May and the Liquid[.]com registrar hijack.
7 DNS gaps that still show up in big orgs, and how to close each one ๐
https://t.co/nPocViVMbv
#DNS #DNSSecurity #DMARC #DNSSEC #AttackSurface
๐ Managing Your Domains Just Got Easier in DNSAudit 1.3
One of the new features in https://t.co/3fgUJUML5U 1.3 is a much easier way to import and manage your domains.
You can add them one by one, paste a full list, upload a BIND zone file or CSV, or pull them directly from your DNS provider.
Cloudflare, Route 53, Google Cloud DNS, Azure DNS, GoDaddy, DigitalOcean, Linode, Gandi, and NS1 are supported.
Once imported, you can star key domains, scan several at once, add tags, export them, and review Top Issues.
Discover everything included in DNSAudit 1.3 โก๏ธ https://t.co/p70mxLgDNw
#DNS #Networking #DevOps #SysAdmin
๐ Meet the Domain Exposure Engine in DNSAudit 1.3
As we mentioned last week, https://t.co/3fgUJUMdgm 1.3 is now out, and one of the new features is the Domain Exposure Engine.
It adds 26 checks around domain registration and ownership, covering expiration, registrar locks, recent transfers, domain age, nameserver redundancy, DNSSEC, WHOIS exposure, and more.
You also get a separate Domain Exposure Score from 0โ100, alongside your DNS Security Score.
If you havenโt read the version 1.3 announcement yet, you can find the full breakdown on our blog โก๏ธ https://t.co/p70mxLg5XY
#DNS #Networking #DevOps #SysAdmin
๐ Free Accounts Are Now Available in https://t.co/3fgUJUMdgm 1.3
https://t.co/3fgUJUMdgm 1.3 launched yesterday, introducing free accounts with more room to scan and a dashboard to keep track of your domains.
The free plan includes 10 scans per day, up to 100 subdomains per domain scan, 14 days of history, advanced mail security checks, full Domain Exposure Engine results, MFA, and PDF, JSON, and CSV exports. Also, no credit card required!
Anonymous scanning is still available for quick checks, but with a free account you can also track recent scans, priority issues, and the average score across your domains.
Sign up for your free account here, it takes less than a minute โฌ๏ธ
https://t.co/XPXiSVdX61
#DNS #Networking #DevOps #SysAdmin
We are happy to introduce https://t.co/3fgUJUMdgm 1.3 ๐
The main addition is the Domain Exposure Engine. Scans used to stop at your DNS config and skip the domain itself. Now they look at both.
It checks expiry and redemption status, registrar locks, transfers, domain age, DNSSEC, high-risk TLDs, WHOIS privacy exposure and a few more. 26 checks in total, with a separate score out of 100 that sits next to your DNS score.
Other stuff in this release:
- 14 more email security checks covering SPF, DMARC, DKIM and TLS-RPT
- Bulk domain import. Paste a list, upload a zone file or CSV, or sync from Cloudflare, Route 53, GoDaddy, DigitalOcean and others
- Official Python SDK, just pip install dnsaudit
- Free accounts, no credit card. 10 scans a day, up to 100 discovered subdomains, 14 days of history, and PDF, JSON and CSV exports. Scanning without an account still works too
Release notes here ๐
https://t.co/p70mxLg5XY
Big thanks to @whoisxmlapi for sponsoring us since the beginning!
If DNS or domain security is part of your job, give it a try and tell us what you think. A lot of what's in this release came from people using it and telling us what was missing.
๐จ Unbound DNSSEC Validator Bug Opens the Door to RCE
Unbound is a widely used open-source DNS resolver, and a critical flaw in its DNSSEC validator could allow remote code execution.
Tracked as CVE-2026-81642, the heap overflow affects all versions up to 1.26.0 and can be triggered by an attacker-controlled DNS zone using a specially crafted DNSKEY record.
Unbound 1.26.1 fixes the issue, along with eight other security vulnerabilities.
Read more โก๏ธ https://t.co/V9WXHoYgDq
#DNS #DNSSEC #Networking #DevOps #SysAdmin
๐ DNS TTLs: Too Low, Too High, or Just Right?
Do you know if your DNS TTLs are set too low, too high, or at the right level for your infrastructure?
Our DNS TTL guide breaks down how TTL values affect caching, DNS traffic, server load, and how quickly changes propagate.
Set them too low and resolvers keep coming back for fresh answers. Set them too high and outdated or compromised records can stay cached longer than you want.
We also cover recommended TTLs by record type, BIND examples, dig verification, and when to lower TTLs before infrastructure changes.
Check out our guide here โก๏ธ https://t.co/JlvZ1hIf94
#DNS #Networking #DevOps #SysAdmin
โ ๏ธ How DNS Response Types Can Amplify Random-Name Attacks
Have you ever heard about random-name attacks? They are far easier to mount than other attacks, and they target authoritative DNS servers with a constant stream of unique, nonexistent subdomains.
Because every name is different, recursive resolver caches canโt absorb much of the traffic, so each fresh query is passed upstream, keeping the authoritative server busy and potentially pushing legitimate DNS traffic aside.
APNIC has tested how resolvers react to different negative responses, and the gap was huge. The main metric was queries per test, where a higher number means resolvers kept retrying, sending more traffic and putting more load on the authoritative DNS server.
โข Definitive answers behaved relatively well: NOERROR/NODATA averaged 3.93 queries per test, while NXDOMAIN averaged 4.40.
โข Things changed when the answer was less final: REFUSED reached 11.47 queries per test, SERVFAIL jumped to 51.73, and no response at all reached 83.46.
What does this mean? During a random-name attack, those retries can significantly amplify the pressure already hitting the authoritative DNS server.
So, where possible, returning a clear, definitive negative response can help limit unnecessary retries and keep extra DNS load down.
Read more โก๏ธ https://t.co/z3do8EQj7R
#DNS #Networking #DevOps #SysAdmin
๐ A Practical Guide to DNSSEC NSEC3 Parameters
NSEC3 is one of those DNSSEC settings where more security can also mean more CPU and slower queries.
Our guide on NSEC3 parameters breaks down how iteration counts, salts, and opt-out affect that balance, with practical examples for BIND and PowerDNS.
We also cover benchmarking, parameter checks, salt rotation, and ways to tune your setup without guessing.
If you manage DNSSEC zones, this guide gives you a practical way to review your NSEC3 setup.
Check it out here โก๏ธ https://t.co/w6IUnCNjRU
#DNS #DNSSEC #Networking #DevOps #SysAdmin
๐ข DNS Security Is More Than Blocklists
At least 10% of new gTLD domains registered in 2025 had already appeared on security blocklists, while estimates suggest malicious actors may control closer to 20% โก๏ธ https://t.co/Jgw0tq7CBQ
But blocklists only show part of the problem.
Domains can sit unused, support fraud, or remain undetected for months. On the defensive side, at https://t.co/3fgUJUML5U, we help organizations review their own DNS exposure, misconfigurations, and missing protections across 75+ checks.
Better visibility matters on both sides of the DNS ecosystem.
#DNS #Networking #DevOps #SysAdmin
๐ Why DNSSEC Algorithm Choice Matters: Our Implementation Guide
Choosing a DNSSEC algorithm is more than a configuration detail.
Older options like RSA/MD5 and DSA/SHA1 carry known weaknesses, while modern algorithms such as ECDSA and Ed25519 offer stronger security with smaller signatures.
Our DNSSEC implementation guide covers:
โข Which algorithms to replace
โข What to use for new deployments
โข BIND, Unbound, PowerDNS, and Cloudflare examples
โข Safe algorithm rollover and validation
Read our full guide for implementation steps and configuration examples โก๏ธ https://t.co/myfBtauWkg
#DNS #DNSSEC #CyberSecurity #InfoSec
๐ข The DNS Cold-Start Problem
What happens when a DNS resolver starts with an empty cache?
A single lookup can turn into several queries across the DNS hierarchy. The resolver may first need to find the authoritative nameservers for a domain, then resolve the addresses of those nameservers before it can continue.
Thatโs the DNS cold-start problem.
Caching normally removes much of this work by keeping previously learned information available.
Without cached data, more of the DNS resolution process has to happen from scratch, which can result in additional queries.
Read more โก๏ธ https://t.co/9Kc06TgnwW
#DNS #Networking #DevOps #SysAdmin
๐ Wildcard DNS Security Risks and How to Reduce Them
Wildcard DNS can be convenient, but it also means subdomains you never created may still resolve.
That can make subdomain abuse, DNS rebinding, and convincing fake hostnames easier to pull off.
In our docs, we explain how to detect wildcard DNS, test random subdomains, remove unnecessary wildcard records, and add tighter controls when wildcards are actually needed.
We also cover examples for BIND, Unbound, PowerDNS, and Cloudflare.
Check it out here โก๏ธ https://t.co/dR4YDhzqUt
#DNS #DNSSecurity #CyberSecurity #InfoSec