use in production? - Githubissues

dudicoco commented 3 years ago

Hi,

Is this plugin safe to use in production?

According to this comment it has only been lightly tested: https://github.com/coredns/coredns/issues/2311#issuecomment-479013237

Just making sure that since then it has been properly tested :)

Thanks

chrisohaver commented 3 years ago

It is used in production.

dudicoco commented 3 years ago

Thanks @chrisohaver. In that case why is this plugin external and not part of the core essential plugins? I believe rate limiting should be an essential part of coredns, otherwise a rogue application and dns flood coredns.

chrisohaver commented 3 years ago

In that case why is this plugin external and not part of the core essential plugins?

Until now, no one has asked for it. However, there is a known limitation regarding wildcards (in which an attacker could use wildcards to launch an undetected amplification attack).

a rogue application and dns flood coredns

The primary feature of RRL (response rate limiting) doesn't protect against that. It helps mitigate "amplification attacks" against other endpoints not CoreDNS itself. RRL secondarily allows request rate limiting, which is different and could help a little bit there, but would not do well to prevent a client from flooding CoreDNS with queries (CoreDNS still has to receive the DNS requests and count them).

dudicoco commented 3 years ago

@chrisohaver so what would be the proper mitigation for request rate limiting in that case? We've encountered an issue on which an application sent thousands of requests to coredn, thus overloading it.

chrisohaver commented 3 years ago

Whether or not rrl's request rate limiting would help depends on the situation. It would do better if the following are true ...

the attacker isn't spoofing its source address (e.g. using random source address for each query)
the responses for the queries are not cached (some types of error responses are not cache by CoreDNS)
the cost of resolving the answers is high, e.g. the requests are being forwarded by CoreDNS to an upstream DNS server, or perhaps that the responses are very large.

I'm guessing that an application errantly (not maliciously) sending thousands of requests to CoreDNS, would probably be sending the same query repeatedly. If CoreDNS is sending the queries upstream, and the answer is a non-cachable error, then rrl request rate limiting could help.

ltagliamonte-dd commented 3 years ago

would love to see this added to the official list of plugins @chrisohaver i a shared infrastructure we need a way to block noisy neighbors

fedor-git commented 3 years ago

[WARNING] An external plugin (/go/src/github.com/coredns/coredns/plugin/rrl/setup.go line 67) is using the deprecated function Normalize. This will be removed in a future versions of CoreDNS. The plugin should be updated to use OriginsFromArgsOrServerBlock or NormalizeExact instead.

Will it be updated in the future?

chrisohaver commented 3 years ago

[WARNING] An external plugin (/go/src/github.com/coredns/coredns/plugin/rrl/setup.go line 67) is using the deprecated function Normalize. This will be removed in a future versions of CoreDNS. The plugin should be updated to use OriginsFromArgsOrServerBlock or NormalizeExact instead.

Will it be updated in the future?

Yes

chrisohaver commented 3 years ago

would love to see this added to the official list of plugins

@ltagliamonte-dd, I added it to the "official list" of external plugins: https://coredns.io/explugins/

ltagliamonte commented 3 years ago

@chrisohaver thank you, what i meant it was to see the plugin part of the official release. In this way we don't have to maintain a internal fork. Thanks

coredns / rrl

use in production? #24