[Proxy/Client] Fix DNS server denial-of-service issue when DNS entry expires #15403
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…expires
- DnsNameResolver doesn't coordinate concurrency and this leads to DNS server DoS
under high load
- In Netty, DnsAddressResolverGroup internally uses internal InflightNameResolver
class to address the problem
- The solution is to use DnsAddressResolverGroup instead of instantiating DnsNameResolver
directly
lhotari
added
type/bug
lhotari
requested review from
merlimat,
rdhabalia,
eolivelli,
codelipenghui,
BewareMyPower and
michaeljmarshall
Technoboy-
approved these changes
May 2, 2022
lhotari
added a commit
to datastax/pulsar
that referenced
this pull request
May 3, 2022
…expires (apache#15403) - DnsNameResolver doesn't coordinate concurrency and this leads to DNS server DoS under high load - In Netty, DnsAddressResolverGroup internally uses internal InflightNameResolver class to address the problem - The solution is to use DnsAddressResolverGroup instead of instantiating DnsNameResolver directly
lhotari
added a commit
to datastax/pulsar
that referenced
this pull request
May 3, 2022
…expires (apache#15403) (cherry picked from commit 40d7169)
lhotari
added a commit
to datastax/pulsar
that referenced
this pull request
May 3, 2022
…expires (apache#15403) (cherry picked from commit 40d7169)
|
I'm a bit late, but LGTM. |
nicoloboschi
pushed a commit
to datastax/pulsar
that referenced
this pull request
May 10, 2022
…expires (apache#15403) (cherry picked from commit 40d7169)
lhotari
added a commit
that referenced
this pull request
Jun 1, 2022
…expires (#15403) - DnsNameResolver doesn't coordinate concurrency and this leads to DNS server DoS under high load - In Netty, DnsAddressResolverGroup internally uses internal InflightNameResolver class to address the problem - The solution is to use DnsAddressResolverGroup instead of instantiating DnsNameResolver directly (cherry picked from commit fe78908)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
DnsNameResolverdoesn't coordinate concurrency and this leads to DNS server DoSunder high load to the Pulsar Proxy. This happens when a large number of connections are initiated at once.
Dns lookups will timeout since the DNS server will get overloaded and won't be able to respond in time.
Example error message
query via UDP timed out after 5000 milliseconds:DnsAddressResolverGroupinternally uses internalInflightNameResolverclass to address the problem
Modification
Additional context
Similar issue in AsyncHttpClient: AsyncHttpClient/async-http-client#1650
Netty issue netty/netty#5838