DEV Community

Ramer Lacida
Ramer Lacida

Posted on

7 Tips for Securing Your DNS and Email Deliverability in Production

#dns #security #devops #linux

Why DNS Security Matters

As a DevOps lead, you know that DNS is the backbone of every internet‑facing service. A compromised zone can redirect users to malicious sites, sabotage email flow, and damage brand trust. While the headline‑grabbing attacks are DDoS‑related, the quieter DNS‑specific threats—zone‑transfer leaks, spoofed records, and email spoofing—often go unnoticed until they cause real business impact.

The Practical Checklist

Below is a 7‑point checklist you can run against any production environment. Each tip includes a short “why” and a concrete “how‑to” you can apply today.

1️⃣ Enable DNSSEC on Authoritative Zones

Why: DNSSEC adds cryptographic signatures to DNS responses, preventing attackers from tampering with records in transit.
How:

  • Verify that your registrar supports DNSSEC.
  • Generate a ZSK (Zone Signing Key) and KSK (Key Signing Key) using dnssec-keygen.
  • Publish the DS record at the registrar.
  • Enable automatic key rollover if your provider offers it. 
# Generate a ZSK (algorithm RSASHA256, 2048‑bit)
 dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com
# Generate a KSK (same algorithm, but flagged as KSK)
 dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK example.com
Enter fullscreen mode Exit fullscreen mode

2️⃣ Harden Zone Transfers (AXFR)

Why: Unrestricted AXFR allows anyone to download your entire zone file, exposing internal hostnames and IP ranges.
How:

  • Restrict AXFR to a whitelist of secondary name servers.
  • Use TSIG (Transaction SIGnature) to authenticate transfers.
  • Disable AXFR entirely if you don’t run secondary servers. 
# BIND named.conf snippet
options {
    allow-transfer { 192.0.2.10; 192.0.2.11; }; // IPs of secondary DNS
    also-notify { 192.0.2.10; 192.0.2.11; };
    provide-ixfr yes;
    // Enable TSIG keys
    key "tsig-key" {
        algorithm hmac-sha256;
        secret "Base64EncodedSecret==";
    };
};
Enter fullscreen mode Exit fullscreen mode

3️⃣ Publish CAA Records to Control Certificate Authorities

Why: CAA (Certification Authority Authorization) tells the world which CAs are allowed to issue certificates for your domain, reducing the risk of rogue certificates.
How:

  • Add a CAA record for each authorized CA.
  • Include a reporting address (iodef) to receive violation notices. 
example.com.   IN CAA 0 issue "letsencrypt.org"
example.com.   IN CAA 0 iodef "mailto:security@example.com"
Enter fullscreen mode Exit fullscreen mode

4️⃣ Implement SPF, DKIM, and DMARC Correctly

Why: These three records work together to verify that email sent from your domain is legitimate, dramatically lowering spam and phishing success rates.
How:

  • SPF: Publish a record that lists all legitimate sending IPs.
  • DKIM: Generate a key pair, publish the public key as a TXT record, and configure your mail server to sign outgoing mail.
  • DMARC: Set a policy (none, quarantine, or reject) and request aggregate reports. 
; BIND zone file excerpt
@   IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all"
selector1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; adkim=s; aspf=s"
Enter fullscreen mode Exit fullscreen mode

5️⃣ Use Short TTLs for Critical Records During Changes

Why: A low TTL (Time‑to‑Live) ensures that updates propagate quickly, limiting the window an attacker has to exploit stale data.
How:

  • Set TTL to 300 seconds (5 min) for A/AAAA records that you update frequently (e.g., load‑balanced services).
  • Increase TTL to 86400 seconds (24 h) for static records after the change window passes.

6️⃣ Monitor DNS Changes with Automated Alerts

Why: Real‑time visibility lets you react to unauthorized modifications before they cause damage.
How:

  • Use a service like DNSCheck, or roll your own script that queries dig and compares against a baseline.
  • Integrate alerts with Slack, PagerDuty, or your existing incident‑response pipeline. 
#!/usr/bin/env bash
# Simple change detector
ZONE="example.com"
BASELINE="/var/tmp/${ZONE}.baseline"
CURRENT="/tmp/${ZONE}.current"

dig @ns1.provider.com $ZONE ANY +noall +answer > $CURRENT
if ! diff -q $BASELINE $CURRENT > /dev/null; then
    echo "⚠️ DNS change detected for $ZONE" | slacktee.sh
    cp $CURRENT $BASELINE
fi
Enter fullscreen mode Exit fullscreen mode

7️⃣ Keep Registrar Contact Information Up‑to‑Date

Why: If your domain is ever locked or transferred, the registrar will need a reliable point of contact. Stale contact info can delay recovery.
How:

  • Review WHOIS data quarterly.
  • Enable two‑factor authentication on your registrar account.
  • Store the registrar login credentials in a password manager with audit logs.

Wrapping Up

Applying these seven steps will dramatically improve both the security of your DNS infrastructure and the deliverability of your outbound email. Remember that DNS is a moving target; regular audits, automated monitoring, and staying current with best‑practice records (like CAA and DMARC) are essential.

If you’re looking for a partner that can help you audit and harden your DNS setup without breaking your existing workflow, consider checking out https://lacidaweb.com for a low‑friction, developer‑friendly approach.

Top comments (0)