DNS Security Guide: DNSSEC, DNS over HTTPS, and DNS Filtering

DNS is the phonebook of the internet. Every connection your application makes — to an API, a database, a CDN — starts with a DNS lookup. Attacks against DNS are attacks against the foundation of all your other security controls: a poisoned DNS cache can redirect your users to attacker infrastructure even while your application code is perfectly secure. Understanding and hardening DNS is non-negotiable for any security-conscious engineering team.

DNSSEC: Authenticating DNS Responses

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records. A resolver that validates DNSSEC can verify that a DNS response was authorized by the domain's owner and has not been tampered with in transit. This directly addresses DNS cache poisoning and the Kaminsky attack.

How DNSSEC works

Each zone has a public/private key pair. The zone owner signs all DNS records with their private key. Resolvers fetch the public key (the DNSKEY record) and verify signatures (RRSIG records). The chain of trust flows from the root zone down through TLDs to your domain — each level signing the public key of the level below (via DS records).

Enabling DNSSEC on your domain

Most modern registrars and DNS hosting providers (Cloudflare, Route 53, Google Cloud DNS) provide one-click DNSSEC. The process is:

Enable signing in your DNS provider's dashboard. The provider generates a ZSK (Zone Signing Key) and KSK (Key Signing Key).
Your provider uploads a DS record to your registrar, which passes the chain of trust up to the TLD.
Validation begins — resolvers with DNSSEC support will now verify your zone's signatures.

Verify signing is active:

# Check for DNSKEY records
dig DNSKEY yourapp.com +short

# Verify the chain of trust
dig yourapp.com +dnssec +multi | grep -i rrsig

# Use Verisign's DNSSEC Debugger
# https://dnssec-debugger.verisignlabs.com/yourapp.com

DNSSEC limitations

DNSSEC does not encrypt DNS queries. It only authenticates the data. An observer on the network can still see which domains you are querying. For privacy, you need DNS over HTTPS or DNS over TLS.

DNS over HTTPS (DoH) and DNS over TLS (DoT)

Traditional DNS queries are sent in plaintext UDP or TCP on port 53. Anyone on the network path — your ISP, a coffee shop router, a corporate proxy — can see and modify them.

DNS over TLS (DoT) wraps DNS queries in a TLS connection on port 853. It provides encryption and authentication of the resolver.

DNS over HTTPS (DoH) sends DNS queries inside HTTPS requests on port 443. Beyond encryption, this makes DNS traffic indistinguishable from normal HTTPS traffic, preventing blocking or inspection by intermediaries.

Configuring DoH for your application's outbound DNS

In Node.js, you can force your application's DNS lookups through a DoH resolver:

import dns from 'dns/promises';
import { Resolver } from 'dns/promises';

// Use Cloudflare's DoH resolver (1.1.1.1) via their DNS module
// Or configure at the OS/container level in /etc/resolv.conf

// For explicit DoH in application code, use a DoH client library:
import { Resolver as DoHResolver } from 'doh-js';

const resolver = new DoHResolver('https://cloudflare-dns.com/dns-query');

async function resolveHostname(hostname: string): Promise<string[]> {
  const result = await resolver.resolve(hostname, 'A');
  return result.Answer?.map(a => a.data) ?? [];
}

For production workloads, configuring DoH at the infrastructure level (via the container's DNS resolver or a sidecar like CoreDNS) is more reliable than application-level overrides.

DoH in browser contexts

Modern browsers support DoH natively. For enterprise environments where you run your own DNS infrastructure, you can deploy a DoH server (Cloudflare's cloudflared, CoreDNS with the forward plugin, or Bind 9.17+) and configure browsers to use it via group policy or MDM.

CAA Records: Restricting Certificate Issuance

Certification Authority Authorization (CAA) records let you publish a DNS policy restricting which CAs are permitted to issue certificates for your domain. This prevents mis-issuance — a rogue or compromised CA issuing a certificate for your domain without your authorization.

Every CA is required by the CA/Browser Forum Baseline Requirements to check CAA records before issuing.

Setting CAA records

; Only Let's Encrypt and DigiCert can issue for yourapp.com
yourapp.com. IN CAA 0 issue "letsencrypt.org"
yourapp.com. IN CAA 0 issue "digicert.com"

; Only Let's Encrypt can issue wildcard certificates
yourapp.com. IN CAA 0 issuewild "letsencrypt.org"

; Send violation reports to your security team
yourapp.com. IN CAA 0 iodef "mailto:security@yourapp.com"

With Cloudflare:

# Using Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "CAA",
    "name": "yourapp.com",
    "data": { "flags": 0, "tag": "issue", "value": "letsencrypt.org" },
    "ttl": 3600
  }'

Verify your CAA record:

dig CAA yourapp.com

DNS Filtering for Malware Blocking

DNS filtering intercepts DNS queries and returns NXDOMAIN (or a block page) for known malicious domains. It is one of the cheapest and most effective controls for preventing malware communication and phishing.

Options for DNS filtering

Recursive resolver with filtering (Cloudflare Gateway, Cisco Umbrella, NextDNS): Route all DNS queries through a provider that maintains threat intelligence feeds. Configure via network policy (DHCP option 6) or agent software.

Self-hosted: Pi-hole or AdGuard Home consumes blocklists (e.g., Steven Black's hosts list, URLhaus DNS blocklist) and blocks queries at the resolver level. Suitable for home labs and small offices.

Cloud-native: In AWS VPCs, Route 53 Resolver DNS Firewall lets you associate domain blocklists with your VPC's resolver and alert or block matching queries via CloudWatch.

# AWS CLI: create a DNS Firewall rule group
aws route53resolver create-firewall-rule-group \
  --name "malware-block" \
  --tags Key=Environment,Value=production

# Associate a managed domain list (AWS maintains malware/botnet feeds)
aws route53resolver create-firewall-rule \
  --firewall-rule-group-id rslvr-frg-xxx \
  --firewall-domain-list-id rslvr-fdl-xxx \
  --priority 100 \
  --action BLOCK \
  --block-response NXDOMAIN \
  --name "block-malware"

Split-Horizon DNS: Risks to Understand

Split-horizon (or split-brain) DNS serves different DNS responses to internal and external clients. The intent is to give internal clients private IP addresses for services while external clients get public IPs.

The risks

Inconsistent security policy: If an internal zone serves records that bypass security controls (WAF, load balancer TLS termination), an attacker who gains any internal network access immediately gets a more privileged attack surface.

DNS rebinding amplification: DNS rebinding attacks cause a browser to associate a malicious domain with an internal IP address, allowing the browser to make requests to internal services. Split-horizon amplifies this if internal zones are less locked down.

VPN and tunneling confusion: When users are partially on-network, split-horizon can cause inconsistent behavior that is hard to debug and that sometimes leaks internal network topology.

Safe split-horizon practices

Restrict internal zone queries to internal resolvers only (using ACLs in BIND/Unbound).
Do not bypass TLS on internal services just because they have private IPs.
Use the same certificate infrastructure internally as externally (internal PKI with proper CA trust).
Consider a zero-trust model where you eliminate the internal/external distinction entirely.

DNS Monitoring and Anomaly Detection

DNS is an excellent threat detection signal. Attackers use DNS for C2 communication (DNS tunneling), data exfiltration, and initial domain generation (DGA). Monitor for:

High query volume to a single domain: possible DNS tunneling.
Long subdomain strings: aGVsbG8gd29ybGQ.evil.com — base64-encoded data in subdomains.
Queries to newly registered domains: most malware C2 domains are less than 30 days old.
NXDOMAIN storms: DGA malware generates hundreds of random domain names and queries them sequentially looking for the one that resolves.

# Quick check for unusually long subdomains in your DNS logs
awk '{print length($1), $1}' /var/log/dns/queries.log \
  | sort -rn | head -50 | awk '$1 > 50'

Cloud providers export DNS query logs (Route 53 Resolver Query Logging, Azure DNS diagnostic logs) to your SIEM. Set alerts for the patterns above.

DNS security is multi-layered: DNSSEC ensures data integrity, DoH/DoT ensures query privacy, CAA records restrict certificate issuance, and DNS filtering blocks outbound malware communication. Each layer addresses different threat scenarios, and together they harden the most fundamental layer of your network stack.