DNS security — DoH, response policy zones, and DNSSEC

DNS security in Kubernetes involves encrypting DNS queries, blocking malicious domains, and verifying upstream responses. This lesson walks DoH, RPZ, DNSSEC, and the discipline.

The DNS security threats

flowchart LR
    A[DNS threats] --> B[Eavesdropping]
    A --> C[Malicious domains]
    A --> D[Upstream spoofing]
    B --> B1[Plaintext queries reveal internal services]
    C --> C1[Compromised Pods query C2 servers]
    D --> D1[Attacker forges DNS responses]

The threats:

• Eavesdropping. Plaintext DNS queries reveal internal service names and dependencies.
• Malicious domains. Compromised Pods query command-and-control (C2) servers.
• Upstream spoofing. An attacker forges DNS responses; the resolver returns wrong addresses.

Each threat has a corresponding mitigation.

DoH (DNS-over-HTTPS)

forward . tls://1.1.1.1 {
    tls_servername cloudflare-dns.com
    prefer_health
}

The CoreDNS forward plugin supports TLS (DoT) and HTTPS (DoH):

• DoT (DNS-over-TLS). Port 853; encrypted.
• DoH (DNS-over-HTTPS). Port 443; encrypted, looks like HTTPS traffic.

Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9) support DoH.

# Verify DoH
dig @127.0.0.1 -p 53 +tls example.com

The query is encrypted between CoreDNS and the upstream.

RPZ (Response Policy Zones)

.:53 {
    forward . 8.8.8.8
    response-policy {
        zone "rpz.example.com" {
            policy NXDOMAIN
        }
    }
}

RPZ blocks resolution of malicious domains:

• The response-policy plugin checks every response against a zone file (RPZ).
• Domains in the RPZ are blocked (NXDOMAIN) or rewritten.
• Sources: Spamhaus, Malware Domain List, custom.

A Pod that queries a malicious domain gets NXDOMAIN; the C2 connection is broken.

DNSSEC

.:53 {
    dnssec {
        key file /etc/coredns/dnssec.keys
    }
    forward . 8.8.8.8
}

DNSSEC verifies upstream responses:

• The upstream DNS signs responses with DNSSEC keys.
• CoreDNS verifies the signatures.
• A forged response (without valid signature) is rejected.

DNSSEC prevents upstream spoofing but requires:

• The upstream DNS supports DNSSEC.
• CoreDNS has the trust anchors for the upstream’s DNSSEC keys.

The configuration trade-offs

flowchart LR
    A[DoH] --> B[+ Encrypted upstream]
    A --> C[- Slight latency overhead]
    D[RPZ] --> E[+ Block malicious domains]
    D --> F[- Need to maintain zone file]
    G[DNSSEC] --> H[+ Verify upstream]
    G --> I[- Upstream must support]

The trade-offs:

• DoH: Encrypted upstream, slight latency.
• RPZ: Block malicious domains, maintain zone file.
• DNSSEC: Verify upstream, upstream must support.

Each addresses a specific threat; combine them for defense in depth.

Quiz

The operational discipline

DNS security in production rests on five non-negotiable elements:

• DoH for sensitive traffic. Encrypt upstream queries.
• RPZ for known-malicious zones. Block C2 and phishing domains.
• DNSSEC where supported. Verify upstream responses.
• Monitor DNS security. Alert on RPZ hits, DNSSEC failures.
• Document the configuration. Zones, sources, upstreams.

DNS security is layered; each layer addresses a specific threat. The discipline is to enable the appropriate layers for the environment.