use in production?

[dudicoco]

Hi,

Is this plugin safe to use in production?

According to this comment it has only been lightly tested: coredns/coredns#2311 (comment)

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

Thanks

[chrisohaver]

It is used in production.

[dudicoco]

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]

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]

@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]

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]

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]

[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]

[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]

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]

@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