Introduction
A mis‑configured DNS zone can expose your brand to phishing, spam abuse, and even downtime. As a DevOps lead, you’re probably juggling CI pipelines, monitoring dashboards, and a growing list of services. This checklist gives you a practical, step‑by‑step way to lock down the most common attack surfaces in DNS and email authentication – all without breaking your existing workflow.
1️⃣ Verify Core DNS Records
Before you dive into security extensions, make sure the basics are solid.
- A / AAAA records – Point to the correct IPs, and avoid CNAME chains that increase latency.
- CNAME flattening – If your provider supports it, use flattening for apex domains to reduce extra lookups.
- MX records – Ensure they reference only mail servers you control.
- NS records – Keep them limited to the authoritative name servers you actually run.
- TTL values – Set a low TTL (300–600 seconds) during changes, then raise to 1 hour or more for stability.
2️⃣ Harden Email with SPF, DKIM, and DMARC
These three records work together to prove that your domain is the legitimate sender of email.
SPF (Sender Policy Framework)
Create a TXT record that lists every server allowed to send mail on behalf of your domain.
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"
-
ip4
/ip6
– List your own mail server ranges. -
include
– Pull in third‑party services (Gmail, SendGrid, etc.). -
-all
– Hard‑fail any unauthorized sender.
DKIM (DomainKeys Identified Mail)
Generate a public/private key pair and publish the public key as a TXT record.
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
- Rotate keys every 6‑12 months.
- Align the selector (
default
above) with your mail server configuration.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC tells receiving servers what to do when SPF or DKIM fail, and where to send aggregate reports.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; fo=1"
-
p=reject
– Instruct receivers to discard unauthenticated mail. -
rua
/ruf
– Collect daily reports to monitor abuse. - Start with
p=none
for monitoring, then move toquarantine
and finallyreject
.
3️⃣ Deploy DNSSEC
DNSSEC adds a cryptographic signature to each DNS response, preventing cache poisoning.
- Generate ZSK and KSK keys on your authoritative server (BIND, PowerDNS, etc.).
- Sign the zone and publish the DS record at your registrar.
- Enable DNSSEC validation on recursive resolvers (e.g., Unbound, Cloudflare DNS).
# Example with BIND
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
dnssec-signzone -o example.com -k Kexample.com.+005+12345 example.com.zone
- Rotate keys annually.
- Verify signatures with
dig +dnssec example.com
.
4️⃣ Add CAA Records to Prevent Unauthorized Certificate Issuance
Certification Authority Authorization (CAA) tells CAs which ones are allowed to issue certs for your domain.
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
- Use
issue
for normal certificates. - Use
issuewild ""
to block wildcard certs unless explicitly allowed. - Add
iodef
tags to receive violation reports.
5️⃣ Harden the Resolver Layer
Even if your authoritative zone is locked down, a permissive resolver can leak information.
- Enable DNS over TLS (DoT) or DNS over HTTPS (DoH) on your recursive servers.
-
Rate‑limit queries to mitigate amplification attacks (
rate-limit
in BIND). -
Block public resolvers from querying internal zones using
allow-query
ACLs.
options {
rate-limit {
responses-per-second 5;
window 5;
};
allow-query { trusted; };
listen-on { 127.0.0.1; };
};
6️⃣ Continuous Monitoring & Alerting
Automation is key. Integrate DNS checks into your CI/CD pipeline.
-
Health checks – Use
dig +short @ns1.example.com example.com
in a cron job. -
Expiry alerts – Tools like
certbot
can also warn when DNSSEC keys are near rotation. - Log analysis – Forward BIND logs to a SIEM (e.g., Elastic Stack) and set alerts for NXDOMAIN spikes.
7️⃣ Backup & Disaster Recovery
Never assume a zone file is immutable.
- Store signed zone files in version‑controlled storage (Git).
- Keep encrypted snapshots of your DNS server configuration.
- Test restoration by loading the zone on a staging resolver before a real incident.
Final Thoughts
Securing DNS and email authentication is a marathon, not a sprint. By following this checklist you’ll dramatically reduce the risk of spoofing, phishing, and DNS‑based attacks while keeping your infrastructure observable and recoverable. For teams that need a partner to review their DNS hardening strategy or provide on‑demand expertise, consider checking out https://lacidaweb.com for a low‑friction consultation.
Top comments (0)