# DNSSEC enabled; DNS query logging configured

- **Pattern:** `ab-001645` (`infrastructure-hardening.monitoring-incident-response.dns-security`)
- **Severity:** low
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-001645
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-001645)

## 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:

```bash
aws route53 enable-dnssec --hosted-zone-id Z1234567890
```

For CoreDNS query logging, edit the `coredns` ConfigMap in `kube-system`:

```yaml
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.

## Detection

- **ID:** `dns-security`
- **Severity:** `low`
- **What to look for:** Enumerate all DNS configuration sources: cloud provider DNS settings (Route53, Cloud DNS, Azure DNS), on-cluster DNS (CoreDNS ConfigMap), and external DNS providers. For each, check whether DNSSEC signing is enabled and whether DNS query logging is configured. Count the DNS zones and how many have DNSSEC enabled.
- **Pass criteria:** 100% of DNS zones used by the project have DNSSEC enabled, and DNS query logging is configured and forwarded to the centralized logging system. Report: "X DNS zones found, all Y have DNSSEC enabled; query logging active."
- **Fail criteria:** DNSSEC is not enabled on any DNS zone, or DNS queries are not logged.
- **Skip (N/A) when:** DNS is managed entirely by a cloud provider with DNSSEC automatically enabled and query logging built in.
- **Detail on fail:** Quote the DNS zone. Example: `"DNS zone 'example.com' on Route53 does not have DNSSEC signing enabled."` or `"CoreDNS ConfigMap does not include the 'log' plugin — query logging is disabled"`
- **Remediation:** Enable DNSSEC on your DNS provider. For Route53:

  ```bash
  aws route53 enable-dnssec --hosted-zone-id <zone-id>
  ```

  Enable CoreDNS query logging in Kubernetes:

  ```yaml
  # CoreDNS ConfigMap
  data:
    Corefile: |
      .:53 {
        log
        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
        loop
        reload
        loadbalance
      }
  ```

## External references

- nist SC-20
- nist AU-12
- external CIS-DNS-3.1 — https://www.cisecurity.org/cis-benchmarks

Taxons: operational-readiness, observability

HTML version: https://auditbuffet.com/patterns/ab-001645