Project

General

Profile

Actions

Bug #4474

closed

5.0.x: dns: high resource usage on long lived dns connections

Added by Victor Julien over 3 years ago. Updated over 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

The transaction handling is off for unidirectional protocols like DNS on long lived connections. That is a single TCP/UDP session that receives multiple DNS requests/responses. For DNS this is rare, but some devices do this.

This results in the transaction cleanup trying to remove transactions that have already been removed.


Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #4437: dns: high resource usage on long lived dns connectionsClosedJason IshActions
Actions #1

Updated by Victor Julien over 3 years ago

  • Copied from Bug #4437: dns: high resource usage on long lived dns connections added
Actions #2

Updated by Victor Julien over 3 years ago

Since the fixes in master and 6.x aren't going to be easily backported, we might need a special case workaround for dns in 5.

Actions #3

Updated by Jason Ish over 3 years ago

In 6.0.x we saw a case where the last cleaned up (free'd transaction) wasn't being recorded correctly. So for every transaction that needed to be cleaned up in 'AppLayerParserTransactionsCleanup', it would try to clean up the 32 preceding transactions that were already cleaned up. So in 'AppLayerParserTransactionsCleanup' we were looping at 32 times to cleanup a single transaction.

With 5.0.x that tracking seems to be OK. We only loop once in cleanup.

I'm wondering if its just general transaction handling improvements between 5 and 6 that are making 6 (with this fix applied) better than 5.0?

Actions #4

Updated by Jason Ish over 3 years ago

  • Status changed from New to In Review
Actions #5

Updated by Jason Ish over 3 years ago

  • Subject changed from dns: high resource usage on long lived dns connections to 5.0.x: dns: high resource usage on long lived dns connections
  • Status changed from In Review to Rejected

So far I don't think we have sufficient evidence that this is a real issue in 5.0. 6.0.x is more efficient with respect to transaction handling than 5.0, but this specific issue was an issue introduced in 6.0 that does not show in 5.0, and it was the upgrade to 6.0 where users started to notice an issue.

Rejecting for now.

Actions #6

Updated by Victor Julien over 3 years ago

  • Target version deleted (5.0.7)
Actions

Also available in: Atom PDF