Harden CoreDNS Against DNS Amplification and Spoofing (2026)

CoreDNS doesn’t inherently protect against DNS amplification and spoofing attacks; it’s a feature you have to explicitly configure.

Let’s see how to lock down CoreDNS against these common DNS attacks.

DNS amplification attacks exploit the fact that a small DNS query can elicit a much larger response. Attackers send queries with a spoofed source IP address (the victim’s IP) to an open DNS resolver (like an unhardened CoreDNS instance). The resolver then sends the large response to the victim, flooding their network. Spoofing attacks are similar but aim to inject malicious DNS records into a system’s cache, redirecting traffic or causing other disruptions.

Here’s how we’ll harden CoreDNS:

1. Rate Limiting Queries

This is your primary defense against amplification. We’ll limit the number of queries a client can make within a given time frame.

Diagnosis: Look for unusually high query rates from specific IPs in your CoreDNS logs. If you’re seeing excessive traffic, this is a good place to start.
Fix: Add the ratelimit plugin to your Corefile.
```
.:53 {
    ...
    ratelimit 1000 # Allow 1000 queries per minute per client IP
    ...
}
```
Here, 1000 means 1000 queries per minute. You can adjust this based on your observed legitimate traffic.
Why it works: The ratelimit plugin tracks incoming queries per client IP. If a client exceeds the configured rate, their subsequent queries are dropped until the time window resets. This prevents a single attacker from overwhelming your server with a flood of requests.

2. Response Rate Limiting (RRL)

This specifically targets amplification by limiting the rate of responses sent to a single IP for a specific query name. This is crucial because amplification attacks rely on large responses.

Diagnosis: Similar to general rate limiting, monitor for high response volumes to specific IPs. This is more granular than the general ratelimit plugin.

Fix: Enable RRL using the dnssec plugin’s RRL options or the dedicated rrl plugin. The dnssec plugin is often used for this.

.:53 {
    ...
    dnssec {
        # Enable Response Rate Limiting
        # rates:
        #   - name: default  # Default rate for all queries
        #     rate: 20     # Max responses per second
        #     window: 1s     # Time window
        #     clients: 1000 # Max unique client IPs in the window
        #     # The following are optional
        #     # slip: 50     # Percentage of responses to slip through rate limiting
        #     # rrl_all: true # Apply RRL to all queries, not just those with DNSSEC
        #
        # Example: Limit responses to 20 per second per client IP
        rates . {
            rate 20
            window 1s
            clients 1000
        }
    }
    ...
}

This configuration limits the server to sending at most 20 responses per second to any single client IP for any given query. The clients parameter limits the number of distinct client IPs considered within the window.

Why it works: RRL adds a small delay to responses if the rate limit is approached. For legitimate clients, this delay is usually imperceptible. For an attacker sending a massive flood of spoofed queries, the accumulated delays and dropped responses effectively mitigate the amplification.

3. Disabling Recursion for External Clients

If your CoreDNS instance is not intended to be a public recursive resolver, disable recursion for external networks. This prevents your server from being used in amplification attacks against others.

Diagnosis: Check your network architecture. Is CoreDNS exposed to the internet? Is it intended for internal use only?

Fix: Use the acl plugin to define trusted networks.

.:53 {
    ...
    acl {
        # Allow queries from internal networks
        allow net 192.168.0.0/16
        allow net 10.0.0.0/8
        # Deny all other queries
        deny all
    }
    # Only allow recursion for trusted clients
    # The 'forward' plugin is often used in conjunction with acl for recursion.
    # If you have 'forward' here, ensure it's only for trusted IPs.
    # Example: forward . 8.8.8.8 8.8.4.4
    # If you don't want recursion at all, remove 'forward'.
    ...
}

The acl plugin explicitly permits queries from specified internal networks (allow net) and denies all others (deny all). If recursion is enabled via a forward directive, it will only be performed for clients matching an allow rule.

Why it works: By restricting who can query your CoreDNS server and, more importantly, who can trigger recursive lookups, you prevent unauthorized parties from using your server as a stepping stone for amplification attacks.

4. Setting a DNSSEC Policy (If Applicable)

While not directly preventing amplification, DNSSEC helps validate responses and can be used with RRL. If you are serving authoritative zones, ensure your DNSSEC configuration is robust.

Diagnosis: If you are using DNSSEC, check your Zone Signing Key (ZSK) and Key Signing Key (KSK) expiration and rotation policies.

Fix: Ensure your dnssec plugin is configured with appropriate signing policies and key management.

.:53 {
    ...
    dnssec {
        # Example: Sign zones with specific keys and policies
        keys /etc/coredns/keys/
        policy example.com {
            # Signing policy details...
        }
    }
    ...
}

This is a placeholder; actual DNSSEC configuration is complex and depends on your zone setup.

Why it works: Proper DNSSEC implementation ensures that responses are verifiable. While it doesn’t stop spoofing outright (as spoofers might forge signatures too), it makes it harder for forged responses to be accepted by validating clients and can be integrated with RRL for better protection.

5. Limiting EDNS0 Payload Size

EDNS0 (Extension Mechanisms for DNS) allows for larger UDP packet sizes, which attackers can exploit for amplification. Limiting this size can reduce the impact of such attacks.

Diagnosis: Monitor for large UDP DNS packets in your network traffic.
Fix: Use the edns-size plugin.
```
.:53 {
    ...
    edns-size 1024 # Limit EDNS0 UDP payload to 1024 bytes
    ...
}
```
Setting edns-size to 1024 means CoreDNS will advertise a maximum UDP payload size of 1024 bytes for EDNS0 queries.
Why it works: By artificially lowering the maximum allowed EDNS0 UDP packet size, you reduce the potential size of amplified responses, thus mitigating the impact of an amplification attack. Most legitimate DNS traffic doesn’t require extremely large UDP packets.

6. Enabling prefetch with Caution

The prefetch plugin can reduce load by proactively fetching popular records. However, misconfiguration can increase load.

Diagnosis: If you are experiencing high load and prefetch is enabled, review its configuration.
Fix: Configure prefetch carefully, specifying which zones to prefetch and at what intervals.
```
.:53 {
    ...
    prefetch 30s # Prefetch popular records every 30 seconds
    ...
}
```
This prefetchs popular records every 30 seconds.
Why it works: When configured correctly, prefetch reduces the number of actual queries your server needs to answer by keeping popular records fresh in its cache. This can indirectly help by reducing the number of responses you need to send, making it harder for attackers to exploit amplification. However, if misconfigured, it can generate its own load, so monitor closely.

The Next Headache: Cache Poisoning Attacks

After implementing these measures, you’ve significantly reduced your exposure to amplification and spoofing. The next logical step is to consider more advanced cache poisoning techniques, which might require deeper inspection of DNSSEC validation and transaction ID randomization.