What is DNS Security? The Complete Guide for SaaS and Dev Teams

Introduction

On April 24, 2018, MyEtherWallet users were redirected to a phishing site after attackers abused internet routing to intercept traffic intended for Amazon Route 53 DNS infrastructure. Some users saw a browser certificate warning, clicked through anyway, and lost Ethereum from their wallets.

The attackers did not need a bug in MyEtherWallet's application code. The useful path was DNS and routing: send users who typed the correct domain to the wrong server, then rely on users ignoring the certificate warning.

That is why DNS security matters. DNS records decide where your traffic goes, which services are reachable, who can send email as your domain, which certificate authorities can issue certificates, and which old subdomains still point to third-party services.

For SaaS and development teams, DNS risk grows quietly. New deployments create records. Marketing tools add CNAMEs. Email vendors add SPF and DKIM records. Preview environments appear and disappear. If nobody reviews the DNS layer, old records become phishing, spoofing, takeover, and traffic-redirection risk.

What DNS security actually is

DNS security is the set of controls that protect how your domain names resolve, how your email domain is authenticated, how certificates are issued, and how DNS records are changed over time.

It is not one feature. DNSSEC protects DNS response integrity. SPF, DKIM, and DMARC protect email authentication. CAA limits certificate issuance. Registrar security protects the account that controls your domain. Zone-transfer restrictions protect your DNS inventory from being exposed.

DNS security also includes operational hygiene: removing stale CNAME records, reviewing delegated subzones, checking public cloud records, validating email senders, and monitoring DNS changes after deployments.

The goal is simple: users who type your domain should reach your real infrastructure, mail receivers should know which senders are legitimate, and old DNS records should not become attacker-controlled entry points.

How DNS security works at the protocol level

DNS translates names such as api.example.com into records such as IP addresses, mail exchangers, text records, or certificate authority policies. The core DNS resolution model is defined by RFC 1034 and RFC 1035.

When a browser resolves api.example.com, the device asks a recursive resolver. If the resolver has a cached answer, it returns that answer. If not, it asks the DNS hierarchy: root nameservers, then the top-level domain nameservers, then the authoritative nameservers for example.com.

The authoritative nameserver returns the DNS record. The resolver caches the answer for the record's TTL. That cache improves performance, but it also means stale or malicious answers can affect many users until the cache expires.

DNS security controls protect different parts of this path. DNSSEC lets validating resolvers verify that records came from the real zone and were not modified. Registrar security protects who can change nameservers. Email records tell receivers how to validate mail. CAA tells certificate authorities whether they are allowed to issue for the domain.

What goes wrong: common DNS attack vectors

DNS attacks happen at different layers. Some target resolvers. Some target registrar accounts. Some abuse old records. Some exploit weak email authentication.

The right defense depends on where the failure happens.

• DNS cache poisoning — A resolver accepts and caches a forged DNS answer. Users who rely on that resolver may be sent to the wrong IP address until the cache expires. DNSSEC validation helps because forged records cannot produce a valid signature chain for the real zone.

• DNS hijacking — An attacker changes nameserver or DNS records by compromising the registrar account, DNS provider account, or support workflow. Strong registrar MFA, registry lock where available, restricted account roles, and DNS change monitoring reduce this risk.

• Zone transfer exposure — AXFR zone transfer allows secondary nameservers to copy a full zone from a primary nameserver. If misconfigured to allow transfers from any IP address, it can expose a full DNS inventory, including internal-looking hostnames, staging systems, mail records, and forgotten subdomains.

  # Test only domains and nameservers you own or are authorized to assess
  
  dig NS example.com
  
  dig axfr example.com @ns1.example.com
  
  # Secure result:
  # Transfer failed.
  
  # Dangerous result:
  # Full zone records are returned.

• DNS amplification — Open recursive resolvers can be abused in DDoS attacks. An attacker spoofs the victim's IP as the source of DNS queries, and resolvers send larger responses to the victim. Disable open recursion on authoritative nameservers and restrict recursive resolvers to trusted clients.

• Subdomain takeover through stale CNAME records — A CNAME points a subdomain to a third-party service. If the third-party resource is deleted but the DNS record remains, another party may be able to claim a resource at the target provider and serve content under your subdomain.

• Email spoofing through weak SPF, DKIM, and DMARC — Email authentication is published in DNS. Missing, weak, or misaligned records can let attackers send messages that appear to come from your domain, depending on receiver policy and local filtering behavior.

SPF, DKIM, and DMARC: how email authentication works

SPF, DKIM, and DMARC work together. SPF checks whether the sending IP is authorized. DKIM checks whether the message was signed by a domain-controlled key. DMARC tells receivers how to handle mail when authentication does not align with the visible From domain.

SPF is published as a TXT record on the sending domain. It lists authorized sending services and ends with a qualifier such as -all or ~all. SPF also has a 10-DNS-lookup evaluation limit, which matters when SaaS teams add many email vendors.

DKIM uses a private key on the sending system and a public key in DNS. Each sender usually has one or more selector records, such as google._domainkey.example.com or s1._domainkey.example.com.

DMARC builds on SPF and DKIM by requiring alignment with the visible From header. A DMARC policy of p=none requests monitoring only. Policies of p=quarantine or p=reject request stronger receiver handling after you confirm legitimate senders are aligned.

• SPF: weaker and stronger endings — SPF ~all is a softfail signal. It tells receivers the sender is probably not authorized, but it is weaker than -all. SPF -all requests hard failure for senders not listed in the SPF record. Receiver behavior can still vary based on local policy, reputation, forwarding, and DMARC alignment.

  # Weaker SPF signal
  example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
  
  # Stronger SPF signal
  example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
  
  # Check SPF
  dig TXT example.com | grep spf

• DKIM: selector records — Each sending service may use a different DKIM selector. No response for a selector means that selector is missing or the selector name is wrong; it does not prove that no DKIM exists anywhere for the domain.

  # Google Workspace example selector
  dig TXT google._domainkey.example.com
  
  # SendGrid-style selector example; selector names vary by account
  dig TXT s1._domainkey.example.com
  
  # A valid response usually contains:
  # v=DKIM1; k=rsa; p=...

• DMARC: monitoring vs enforcement — DMARC p=none is useful for rollout because it collects reports without requesting enforcement. It should not be treated as the final state for high-value sending domains. Move gradually toward p=quarantine or p=reject after you verify legitimate senders.

  # Monitoring only
  _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
  
  # Quarantine failing aligned mail
  _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"
  
  # Reject failing aligned mail
  _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
  
  # Check DMARC
  dig TXT _dmarc.example.com

• SPF lookup limit — SPF evaluation allows up to 10 DNS lookups. SaaS teams often exceed this by stacking Google Workspace, SendGrid, Mailchimp, Salesforce, Intercom, and other senders. SPF PermError can weaken authentication outcomes.

  # Inspect SPF includes
  dig TXT example.com | grep spf
  
  # Count include:, a:, mx:, exists:, and redirect= mechanisms.
  # Each can trigger DNS lookups during SPF evaluation.

DNSSEC: what it protects and what it does not

DNSSEC adds data-origin authentication and data integrity to DNS. When a zone is signed and the chain of trust is valid, a validating resolver can reject forged or modified DNS answers.

DNSSEC helps against cache poisoning and forged DNS data. It does not encrypt DNS queries, hide who is querying a domain, fix a compromised registrar account, or prevent you from publishing insecure records.

DNSSEC also needs careful operations. Broken key rollovers, missing DS records, expired signatures, or mismatched keys can cause validating resolvers to return SERVFAIL, making the domain appear unreachable to users behind those resolvers.

DNS-over-HTTPS and DNS-over-TLS protect the transport between client and resolver. They help with privacy and some on-path tampering scenarios, but they do not replace DNSSEC's record-level integrity model.

• Check whether DNSSEC is enabled — Look for DNSKEY, DS, and RRSIG records. Use a validating resolver or DNSSEC checking tool to confirm the chain of trust is healthy.

  # Query with DNSSEC records included
  dig +dnssec example.com A
  
  # Check DNSKEY at the zone
  dig DNSKEY example.com
  
  # Check DS record at the parent zone
  dig DS example.com @a.gtld-servers.net

CAA records: limiting certificate issuance

CAA records tell certificate authorities which CAs are authorized to issue TLS certificates for your domain. Without a CAA record, any trusted public CA can issue a certificate after validating control of the domain.

CAA does not prevent subdomain takeover. It limits certificate issuance paths. That can reduce the chance of unauthorized or unexpected certificate issuance, but it is not a replacement for fixing stale CNAME records.

For SaaS teams, CAA is a low-maintenance control when configured carefully. The main risk is accidentally blocking a legitimate CA used by your CDN, hosting provider, or deployment platform.

• CAA record example — The issue tag allows single-name certificates. The issuewild tag controls wildcard certificates. The iodef tag tells CAs where to send incident reports.

  # Allow only Let's Encrypt and DigiCert
  example.com. IN CAA 0 issue "letsencrypt.org"
  example.com. IN CAA 0 issue "digicert.com"
  example.com. IN CAA 0 issuewild ";"
  example.com. IN CAA 0 iodef "mailto:security@example.com"
  
  # Check CAA
  dig CAA example.com

DNS security concerns specific to SaaS and dev teams

SaaS and development teams change DNS often. That makes DNS a living attack surface rather than a static setup task.

The risk is rarely one dramatic mistake. It is usually many small records created by deployments, vendors, preview environments, email tools, and infrastructure automation.

• CNAME sprawl from third-party tools — Status pages, help centers, marketing sites, CDNs, docs portals, analytics tools, and preview environments often require CNAME records. When the vendor resource is removed but the DNS record remains, the subdomain may become a takeover candidate.

• Preview deployments and short-lived environments — Vercel, Netlify, AWS Amplify, CI/CD preview apps, branch deployments, and PR environments can create short-lived DNS patterns. If teardown does not remove records, DNS keeps pointing to abandoned infrastructure.

• Delegated subzones — A parent domain may be well protected while dev.example.com, staging.example.com, or customer.example.com is delegated to a separate nameserver with weaker controls. Treat delegated subzones as independent DNS security scopes.

• Too many email senders — SaaS companies often send mail through several vendors. SPF records become long, DKIM selectors drift, old vendors remain authorized, and DMARC reports are not reviewed. This creates spoofing and deliverability risk.

• Registrar and DNS provider access — DNS provider admin access is production infrastructure access. Use phishing-resistant MFA where possible, restrict admin roles, review API tokens, and monitor DNS changes like you monitor code changes.

How to assess your DNS security exposure

Start with domains you own. Include your apex domain, product domains, marketing domains, sending domains, support domains, acquisition domains, and delegated subzones.

Run these checks from a controlled environment and document the results. For takeover and zone-transfer checks, test only domains and nameservers you own or are authorized to assess.

• Check SPF, DKIM, and DMARC — For DKIM, list the selectors used by each sending provider first. Unknown selectors cannot be guessed reliably.

  # SPF
  dig TXT example.com | grep spf
  
  # DMARC
  dig TXT _dmarc.example.com
  
  # DKIM selectors; replace selector names with your actual sender selectors
  dig TXT google._domainkey.example.com
  dig TXT s1._domainkey.example.com

• Check zone transfer exposure — Every authoritative nameserver should refuse AXFR from unauthorized sources.

  # Find authoritative nameservers
  dig NS example.com
  
  # Test each authoritative nameserver you own or are authorized to test
  dig axfr example.com @ns1.example.com
  dig axfr example.com @ns2.example.com
  
  # Expected result:
  # Transfer failed.

• Check CAA — Confirm that expected CAs are listed and that wildcard issuance is allowed or denied intentionally.

  dig CAA example.com
  
  # If no CAA exists, decide whether to add one based on your certificate issuance workflow.

• Check DNSSEC — Verify that the zone is signed and the parent zone has the right DS record if you intend to use DNSSEC.

  dig +dnssec example.com A
  
  dig DNSKEY example.com
  
  dig DS example.com @a.gtld-servers.net

• Enumerate likely subdomains from certificate transparency — Certificate transparency logs can reveal many subdomains, but they are not a complete source of truth. Use them as one discovery source among DNS inventory, cloud inventory, and EASM results.

  curl -s 'https://crt.sh/?q=%.example.com&output=json' | jq -r '.[].name_value' | sort -u > ct-subdomains.txt

• Audit CNAME records for takeover candidates — Run takeover checks only against domains you own or have permission to test. Confirm candidates manually before treating them as exploitable.

  # Check CNAMEs for discovered subdomains
  cat ct-subdomains.txt | xargs -I{} sh -c 'echo {}; dig CNAME {} +short'
  
  # Optional: run approved takeover fingerprint checks against owned domains only
  # nuclei -l ct-subdomains.txt -t takeovers/ -silent

What vulnerable DNS configurations look like

DNS security failures often combine. A weak SPF record, missing DMARC policy, and stale CNAME record may look like separate medium or low findings. Together, they create phishing and takeover risk.

The examples below show common unsafe patterns and safer replacements.

• Vulnerable: weak email authentication — SPF uses a softfail, DMARC is missing or left at monitoring only, and not all legitimate senders have aligned DKIM. A phisher can attempt visible-From spoofing, and receiver handling will depend on local filtering behavior.

  # Weak SPF
  example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
  
  # Missing DMARC
  _dmarc.example.com. IN TXT ""
  
  # Monitoring-only DMARC
  _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

• Safer: aligned senders and DMARC enforcement — All legitimate senders are known, DKIM selectors are present, SPF is strict where appropriate, and DMARC has moved from monitoring to enforcement after rollout.

  # Stronger SPF
  example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"
  
  # DMARC enforcement after sender validation
  _dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

• Vulnerable: stale CNAME to a third-party service — The DNS record still points to a vendor target after the actual resource was deleted. This should be reviewed as a takeover candidate.

  # Stale-looking CNAME pattern
  old-help.example.com. IN CNAME example.zendesk.com.
  
  # Risk check
  # Does the target still exist?
  # Is it still claimed by your account?
  # Does the provider show an unclaimed/default page?

• Safer: remove stale records and verify ownership — Delete unused CNAME records. For active third-party records, verify the target resource is claimed by your organization and monitored for drift.

  # Safer process
  # 1. Identify CNAME owner
  # 2. Confirm vendor resource still exists
  # 3. Confirm it is claimed by your account
  # 4. Delete unused records
  # 5. Monitor for changes

How to fix DNS security issues

Fix DNS security in layers. Start with account control, then email authentication, then stale records, then DNS integrity and certificate issuance controls.

Do not jump straight to strict enforcement without inventory. Moving DMARC to reject before discovering all legitimate senders can break real email.

• Secure registrar and DNS provider access — Enable phishing-resistant MFA where possible. Restrict administrator roles. Remove unused accounts and API tokens. Use registry lock for high-value domains if your registrar supports it. Monitor nameserver and zone changes.

• Restrict zone transfers — Allow AXFR only from known secondary nameserver IPs. Every other source should be refused. Test every authoritative nameserver after changes.

• Move DMARC toward enforcement — Start at p=none with aggregate reporting. Identify legitimate senders. Fix DKIM and SPF alignment. Move to p=quarantine with a small percentage if needed, then increase. Move to p=reject once legitimate senders are passing.

• Verify DKIM for every sender — List every email vendor and transactional mail service. Confirm the selector records exist and that outgoing messages are signed with the expected domain.

• Clean stale CNAME records — Review records pointing to third-party services. Confirm ownership of active targets and delete records for deprovisioned services.

• Add CAA records — List the certificate authorities used by your CDN, hosting platform, and certificate automation. Add CAA records for approved CAs and review wildcard issuance before setting issuewild.

• Enable DNSSEC with a tested rollout plan — Use provider tooling where possible. Validate DS records, key rollover procedure, monitoring, and rollback plan before enabling DNSSEC on high-value production domains.

• Monitor DNS changes continuously — DNS changes should create security review events. Watch for DMARC policy regression, SPF record growth, new CNAME records, nameserver changes, new delegated subzones, and CAA changes.

Real-world context: the MyEtherWallet DNS hijack

The MyEtherWallet incident is a useful DNS security case because users typed the correct domain but were sent to the wrong infrastructure. A BGP hijack redirected traffic intended for Amazon Route 53 DNS infrastructure, and a rogue DNS server returned forged answers for myetherwallet.com.

The phishing site used an untrusted certificate, so browsers warned users. Some users clicked through the warning, entered wallet credentials, and lost funds. Public reporting at the time estimated roughly $150,000 in Ethereum was stolen.

DNSSEC validation could have helped users whose resolvers validated the zone because forged DNS answers would not have carried a valid signature chain. HSTS and strict certificate validation also reduce the chance that users accept a phishing site with an invalid certificate.

The lesson is not that one DNS control fixes every scenario. DNS security is layered: routing security, registrar security, DNSSEC validation, TLS certificate controls, strict browser behavior, and DNS change monitoring all protect different parts of the path.

Where ExternalSight fits

ExternalSight fits the external DNS and attack surface monitoring layer. It does not replace your DNS provider, registrar controls, email security gateway, or internal security tooling.

ExternalSight includes DNS scanning, email spoofing checks, zone-transfer checks, certificate transparency discovery, subdomain discovery, TLS checks, HTTP security checks, cloud exposure checks, and attack-chain evaluation as part of its broader external attack surface workflow.

It also supports issue classification, remediation planning, historical comparison, alerting, PDF export, JSON export on supported plans, and notifications depending on plan.

Monitoring is for verified domains on supported plans. Scanner coverage is tracked when external services, API keys, or modules are unavailable, so reports do not pretend every check succeeded.