-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add minimum cache TTL for successful DNS responses #18986
Add minimum cache TTL for successful DNS responses #18986
Conversation
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
1 similar comment
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
Pinging @elastic/siem (Team:SIEM) |
Hello @ansell and thanks for opening this PR! Could you rebase this from |
jenkins run tests |
Signed-off-by: Peter Ansell <p_ansell@yahoo.com>
b736d97
to
6044af7
Compare
@marc-gr I followed the basic instructions that @andrewkroh mentioned on the linked issue but I wasn't able to get the tests to work locally to verify my approach was appropriate. I would prefer if you took over at this point. I have rebased onto the current master and pushed again. |
No problem! |
jenkins run tests |
I fixed the set method and added a unit test. Please @andrewkroh take a look in case I missed something when you have a minute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have requested a change to ensure the TTL returned by the PTRLookupCache consistently reflects the cache TTL rather than the DNS response TTL.
Additionally this needs
- Changelog entry
- Doc update to include the new parameter
Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co>
jenkins run tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signed-off-by: Peter Ansell <p_ansell@yahoo.com>
I made one small change to make the error message match the configuration item it references. |
jenkins run tests |
jenkins run tests |
run tests |
An enhancement to add a minimum alternative cache TTL to the libbeat dns processor for successful DNS responses. This ensures that TTL=0 successful reverse DNS responses can be cached to avoid sending the same reverse DNS request again within a short period of time. The libbeat dns processor is used as a reverse DNS annotator for auditbeat events. Some of these IP addresses respond to reverse DNS requests with TTL=0 in the responses. These were causing load issues for my systems when I had the reverse DNS processor enabled for auditbeat. The new settings is `success_cache.min_ttl`. Closes elastic#18709 Signed-off-by: Peter Ansell <p_ansell@yahoo.com> Co-authored-by: Marc Guasch <marc.guasch@elastic.co> (cherry picked from commit 72da5a6)
…esponses (#20525) * Add success cache minimum TTL for DNS responses (#18986) An enhancement to add a minimum alternative cache TTL to the libbeat dns processor for successful DNS responses. This ensures that TTL=0 successful reverse DNS responses can be cached to avoid sending the same reverse DNS request again within a short period of time. The libbeat dns processor is used as a reverse DNS annotator for auditbeat events. Some of these IP addresses respond to reverse DNS requests with TTL=0 in the responses. These were causing load issues for my systems when I had the reverse DNS processor enabled for auditbeat. The new settings is `success_cache.min_ttl`. Closes #18709 Signed-off-by: Peter Ansell <p_ansell@yahoo.com> Co-authored-by: Marc Guasch <marc.guasch@elastic.co> (cherry picked from commit 72da5a6) * Update CHANGELOG.next.asciidoc Co-authored-by: Peter Ansell <p_ansell@yahoo.com>
An enhancement to add a minimum alternative cache TTL to the libbeat dns processor for successful DNS responses. This ensures that TTL=0 successful reverse DNS responses can be cached to avoid sending the same reverse DNS request again within a short period of time. The libbeat dns processor is used as a reverse DNS annotator for auditbeat events. Some of these IP addresses respond to reverse DNS requests with TTL=0 in the responses. These were causing load issues for my systems when I had the reverse DNS processor enabled for auditbeat. The new settings is `success_cache.min_ttl`. Closes elastic#18709 Signed-off-by: Peter Ansell <p_ansell@yahoo.com> Co-authored-by: Marc Guasch <marc.guasch@elastic.co>
What does this PR do?
An enhancement to add a minimum alternative cache TTL to the
libbeat
dns processor for successful DNS responses. This ensures thatTTL=0
successful reverse DNS responses can be cached to avoid sending the same reverse DNS request again within a short period of time.Why is it important?
The
libbeat
dns processor is used as a reverse DNS annotator forauditbeat
events. Some of these IP addresses respond to reverse DNS requests withTTL=0
in the responses. These were causing load issues for my systems when I had the reverse DNS processor enabled for auditbeat.Checklist
- [ ] I have commented my code, particularly in hard-to-understand areas- [ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
The
auditbeat
system/socket
module that I had the issue with is not open-sourced, so I have not been able to test its completeness myself. I am submitting this in good faith that it can be completed by someone with access to that module for testing purposes, or who is experienced enough to add the necessary tests here.Related issues
Use cases
This will add a cache for successful DNS responses that will not always correspond to the upstream DNS TTL value. This is acceptable as it avoids a possible denial-of-service for
auditbeat
enabled systems, and it is configurable by users.