Dns over http2 5773 v16#11461
Conversation
by making tx parsing and creation more easily available, without needing a dns state. Dns event NotResponse is now set on the right tx, and not the one before. Also debug log for Z-flag on request says "request" instead of "response" Also rustfmt dns.rs
Ticket: 5773
Ticket: 5773
Ticket: 5773
Now a flow alproto can be changed by a call to AppLayerParserParse when HTTP2 forces the flow to turn into DOH2.
Ticket: 5773 Handles both directions the same way for data if content type is application/dns-message
So as to consume less memory for HTTP2Transaction
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #11461 +/- ##
==========================================
- Coverage 82.52% 82.51% -0.02%
==========================================
Files 938 938
Lines 248297 248533 +236
==========================================
+ Hits 204917 205077 +160
- Misses 43380 43456 +76
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: QA ran without warnings. Pipeline 21444 |
Probably fine, as these are
|
|
In dcerpc, we don't care if it comes over smb or udp/tcp directly, right? I feel dns records shouldn't be different regardless of their transport. It should be recognizable somehow as Dns over HTTP/2, Dns over HTTP, etc still, but that can be done in various ways. |
|
So, you would want |
Yeah that sounds good. |
|
Thanks Continued in #11498 |
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5773
Describe changes:
SV_BRANCH=OISF/suricata-verify#1970
#11428 with DNS v3 logging, no longer a draft, cf last commit
Should there be a squash up of commits ?
@jasonish here for a DOH2 tx, we log a bidirectional HTTP2 transaction, and then if any, a DNS transaction, preferring the answer... What do you think about it ? This allows to keep the same format as for regular dns.
Another option would be to log two doh2 events : one for the DNS request and one for the DNS answer, with HTTP2 getting logged twice... not sure how it would work out for alerts...