DNSSEC enabled; DNS query logging configured
Why it matters
Without DNSSEC, DNS responses for your domain can be spoofed by attackers on the same network path — a forged A record redirects users to an attacker-controlled server that serves your site's login page to harvest credentials (NIST 800-53 SC-20). Without DNS query logging, there is no visibility into what domains cluster workloads are resolving — a key signal for detecting C2 communication and data exfiltration via DNS tunneling (NIST 800-53 AU-12). CIS DNS 3.1 requires both controls. CoreDNS logs are disabled by default in most Kubernetes deployments.
Severity rationale
Low because DNS spoofing requires a network-level position between the resolver and authoritative server, limiting exploitation to targeted rather than remote attacks.
Remediation
Enable DNSSEC on your DNS provider and activate the CoreDNS log plugin. For Route53:
aws route53 enable-dnssec --hosted-zone-id Z1234567890
For CoreDNS query logging, edit the coredns ConfigMap in kube-system:
data:
Corefile: |
.:53 {
log # Add this line to enable query logging
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
}
Forward CoreDNS logs to your centralized logging system so DNS queries are retained and searchable.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Infrastructure Hardening Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- nist:rev5 · SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
- nist:rev5 · AU-12 — Audit Record Generation
- external · CIS-DNS-3.1 — CIS DNS Benchmark — Enable DNSSEC for all authoritative zones
Taxons
History
- 2026-04-18·v1.0.0·Initial import from infrastructure-hardening·automated