Guard against wildcard flooding

[chrisohaver]

Employing a Response Rate Limiting function in CoreDNS (e.g. this plugin) was recommended in the security review by Trail of Bits' security review of CoreDNS to help prevent DNS reflection attacks.

There is a known issue that would be good to fix: the rrl plugin is susceptible to wildcard flooding. That is, an attacker can abuse a known wildcard to generate an (almost) unlimited number of unique queries, and thus launch a DNS reflection attack while keeping quotas under rrl limits.

BIND's RRL implementation solves this by lumping all responses synthesized by a given wildcard into one bucket for that wildcard. For CoreDNS to do this, it needs to be aware of the wildcards served by a zone.

The solution (in progress) will involve changes to this repo, but also to require changes to some plugins in CoreDNS (plugins that support wildcard records). This would mostly be file, auto, and other plugins that use the Zone package to serve zones.

I can think of two different general approaches to implement this in CoreDNS:

1. Authoritative plugins synthesizing a response from a wildcard record would earmark the response in some way, so that the rrl plugin can identify what subdomain segments are wild.
   • earmarking responses could be awkward code-wise - could require some core changes to structures, or involve stashing info in context (e.g. via metadata). Even though this approach adds processing to each wildcard response, it would be more efficient in the end since the plugins already know at the time of creating a response if it exists due to a wildcard record.
2. Authoritative plugins provide a list of all wildcards they serve. rrl would then infer that a response for a query name that is a subdomain of a wildcard should be accounted for in that wildcard's parent domain.
   • Maybe easier to implement, but static records "blocking" wildcards will break this assumption - and coding around that would be also adding a list of static records that are subdomains of wildcards to the list, which could result in the list being quite long. Essentially this approach requires extra legwork "re-figuring out" if a response was created by a wildcard record.

[chrisohaver]

Changes merged. This can close once CoreDNS is tagged/released with the fix coredns/coredns#5308, and go modules in this repo are updated.

[ihgann]

Changes merged. This can close once CoreDNS is tagged/released with the fix coredns/coredns#5308, and go modules in this repo are updated.

It looks like this change has been merged as well. Is this still an actual issue, or can this be closed/notes be fixed on the README?

[chrisohaver]

It’s solved for the file plugin, but I think it’s still an issue for wildcards served from other sources such as from upstream servers, or any plugin that synthesizes wildcard answers and does not create the wildcard metadata.