The Domain Name System is the phone book of the internet — it translates human-readable domain names into IP addresses. When DNS works, nobody notices it. When DNS is compromised or misconfigured, everything breaks at once: your site goes down, email stops delivering, and in the worst cases, attackers silently redirect your visitors to malicious servers while your SSL certificate still shows green in the browser. DNS security is one of the most underrated attack surfaces in web security, and the misconfigurations are alarmingly common even on large, well-resourced sites.

Why DNS Is a High-Value Target

DNS was designed in the 1980s for convenience, not security. The original protocol has no built-in authentication — a DNS resolver has no reliable way to verify that the answer it receives actually came from an authoritative server. This fundamental design gap has been exploited in attacks ranging from cache poisoning to full domain hijacking.

Beyond active attacks, simple misconfigurations — wrong TTL values, stale CNAME records pointing at abandoned services, missing email authentication records — create vulnerabilities that attackers can exploit without any sophisticated tooling.

TTL: Small Number, Large Consequences

Time-to-Live (TTL) is the value attached to every DNS record that tells resolvers how long to cache the answer before re-querying. TTL has two opposing security implications:

The recommended TTL for most production records is between 300 and 3600 seconds. If you are anticipating a DNS change, lower your TTL to 300 at least 48 hours in advance, make the change, confirm stability, then raise the TTL again.

DNSSEC: The Authentication Layer DNS Was Missing

DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records, allowing resolvers to verify that the answer they received has not been tampered with in transit. DNSSEC prevents cache poisoning attacks and certain man-in-the-middle scenarios. Despite being standardised in 2005, adoption remains low — many hosting providers do not enable DNSSEC by default, and configuring it incorrectly can cause resolution failures more severe than not having it at all.

DNSSEC does not encrypt DNS traffic (that is the role of DNS-over-HTTPS or DNS-over-TLS), but it guarantees integrity. For high-assurance domains in financial services, government, or healthcare, DNSSEC should be considered a baseline requirement.

The Misconfigurations That Get Sites Hacked

DNS Hijacking

DNS hijacking occurs when an attacker gains control of a domain's DNS records — typically by compromising the registrar account through credential theft, phishing, or social engineering. Once in control, the attacker can redirect all traffic. If they obtain a TLS certificate for the domain (which certificate authorities will issue to whoever controls domain DNS), the attack becomes effectively invisible: the browser shows HTTPS, the padlock is green, and there is no warning whatsoever. Mitigation requires registrar-level two-factor authentication, domain lock, and active monitoring for unexpected record changes.

Subdomain Takeover

Subdomain takeover exploits CNAME records that point to third-party services you have since cancelled or abandoned. When you shut down a Heroku app, a GitHub Pages site, or a Netlify deployment, the CNAME record in your DNS often remains. An attacker who notices this pattern can claim the abandoned resource on the third-party platform and immediately begin serving content on your subdomain — complete with your domain's implicit trust. The subdomain looks legitimate to every browser and every user, because from a DNS perspective it is still yours.

Missing SPF and DMARC Records

Without SPF and DMARC, any server on the internet can send email appearing to originate from your domain. Attackers use this to send phishing emails that look like they came from your organisation — targeting your customers, partners, or employees. Many successful business email compromise (BEC) attacks begin with exactly this misconfiguration, and the fix is a DNS record change that takes minutes.

How Shieldome Checks This

Shieldome includes a dedicated DNS security check suite:

Frequently Asked Questions

What is the safest TTL value for a production DNS record?

For most production environments, a TTL between 300 and 3600 seconds balances propagation speed with query efficiency. Always lower your TTL to 300 at least 48 hours before a planned DNS change — this ensures the old record expires quickly during the transition.

How do I find out if any of my subdomains are vulnerable to takeover?

Audit every CNAME record in your DNS zone and verify that the resource it points to is still active on the third-party platform. Common risky targets include *.herokudns.com, *.github.io, and *.netlify.app. Shieldome continuously monitors for these patterns automatically.

Does DNSSEC prevent DNS hijacking at the registrar level?

No. DNSSEC prevents cache poisoning and record tampering in transit, but it does not protect against registrar account compromise. If an attacker gains access to your registrar account, they can modify DNSSEC records just as easily as A records. DNSSEC and strong registrar account security — MFA, domain lock, notification alerts for any record change — are complementary controls.

What is the difference between SPF and DMARC?

SPF defines which IP addresses and servers are authorised to send email on behalf of your domain. DMARC builds on top of SPF (and DKIM) to specify what receiving servers should do when a message fails authentication — reject it, quarantine it, or allow it — and where to send aggregate reports. You need both.

Concerned about subdomain takeover, missing SPF records, or DNS performance issues on your site? Start a free Shieldome scan and get a complete DNS security report alongside 40+ additional checks — results in under five minutes, no installation required.