A note for the community
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Problem
The dnstap parser does not understand or deliver HttpProtocol to VRL. This is a fairly new change to the dnstap specification (https://github.com/dnstap/dnstap.pb/blob/main/dnstap.proto)
Configuration
Version
vector 0.57.0 (x86_64-unknown-linux-gnu 8832452 2026-07-14 20:58:30.491174540)
Debug Output
Example Data
n/a
Additional Context
What happened: PR #22348 (esensar, merged 2/3/2025) updated Vector's bundled dnstap schema to v20250201 — the release that added HttpProtocol. It was explicitly labeled a chore / non-functional / not a breaking change. So prost now generates the http_protocol field on the Message struct, but that's the whole extent of it.
Why it doesn't reach VRL: Vector's dnstap source doesn't pass the protobuf through generically — DnstapParser hand-maps each protobuf field into the event, and DnstapPaths in dnstap_parser::schema is the exhaustive list of emitted paths. All 76 fields are there, and http_protocol is not among them. You get socket_family and socket_protocol only. Since parse_dnstap() shares that same parser and returns DnstapEventSchema::request_message_schema_definition(), the VRL function has the identical gap.
So in our environment dnsdist 2.0 will happily emit http_protocol = 2 or 3, and Vector will decode it into a struct field and then silently drop it. The bytes arrive; the parser just never looks to see it or do anything with it.
References
No response
A note for the community
Problem
The dnstap parser does not understand or deliver HttpProtocol to VRL. This is a fairly new change to the dnstap specification (https://github.com/dnstap/dnstap.pb/blob/main/dnstap.proto)
Configuration
Version
vector 0.57.0 (x86_64-unknown-linux-gnu 8832452 2026-07-14 20:58:30.491174540)
Debug Output
Example Data
n/a
Additional Context
What happened: PR #22348 (esensar, merged 2/3/2025) updated Vector's bundled dnstap schema to v20250201 — the release that added HttpProtocol. It was explicitly labeled a chore / non-functional / not a breaking change. So prost now generates the http_protocol field on the Message struct, but that's the whole extent of it.
Why it doesn't reach VRL: Vector's dnstap source doesn't pass the protobuf through generically — DnstapParser hand-maps each protobuf field into the event, and DnstapPaths in dnstap_parser::schema is the exhaustive list of emitted paths. All 76 fields are there, and http_protocol is not among them. You get socket_family and socket_protocol only. Since parse_dnstap() shares that same parser and returns DnstapEventSchema::request_message_schema_definition(), the VRL function has the identical gap.
So in our environment dnsdist 2.0 will happily emit http_protocol = 2 or 3, and Vector will decode it into a struct field and then silently drop it. The bytes arrive; the parser just never looks to see it or do anything with it.
References
No response