[GH-ISSUE #3456] hickory-proto parsing all dnssec algorithms #1185

New issue

Open

opened 2026-03-16 01:50:48 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:50:48 +03:00

Owner

Originally created by @esensar on GitHub (Feb 11, 2026).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3456

Is your feature request related to a problem? Please describe.
Vector uses hickory-proto for parsing dnstap frames. When unsupported DNSSEC algorithm numbers are encountered a warning is emitted and they are ignored: https://github.com/vectordotdev/vector/issues/24632

It is also difficult to use hickory-proto for parsing the whole message and then parsing just this specific section manually - it would be easier to just do all of the parsing then.

Describe the solution you'd like
Would it be possible to parse out all of the algorithms, even if they are not supported by hickory-dns? In github.com/hickory-dns/hickory-dns@b2a4707b1a/crates/proto/src/dnssec/supported_algorithm.rs (L80-L93) I can see that only supported algorithms are added to the SupportedAlgorithms (which is expected considering its name), but that is the only structure that we get out of parsed message. Even though there are some algorithms listed in github.com/hickory-dns/hickory-dns@b2a4707b1a/crates/proto/src/dnssec/algorithm.rs (L105-L139), they are not supported by this structure.

My idea for this would be to just add some of the missing algorithms to the Algorithm enum, keeping them unused except for parsing and then to also keep unknown algorithms that were encountered in the SupportedAlgorithms, without affecting the existing uses (so not changing the SupportedAlgorithmsIter or has and similar methods, probably providing separate methods for unsupported algorithms. I am not sure if that would be acceptable, considering the SupportedAlgorithms uses a small bit map for all algorithms and this would require additional field, that would probably end up being a Vec<Algorithm> or Vec<u8>.

Originally created by @esensar on GitHub (Feb 11, 2026). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3456 **Is your feature request related to a problem? Please describe.** [Vector](https://github.com/vectordotdev/vector/) uses hickory-proto for parsing dnstap frames. When unsupported DNSSEC algorithm numbers are encountered a warning is emitted and they are ignored: https://github.com/vectordotdev/vector/issues/24632 It is also difficult to use hickory-proto for parsing the whole message and then parsing just this specific section manually - it would be easier to just do all of the parsing then. **Describe the solution you'd like** Would it be possible to parse out all of the algorithms, even if they are not supported by hickory-dns? In https://github.com/hickory-dns/hickory-dns/blob/b2a4707b1a0ca984b10c521946b5763013929bca/crates/proto/src/dnssec/supported_algorithm.rs#L80-L93 I can see that only supported algorithms are added to the `SupportedAlgorithms` (which is expected considering its name), but that is the only structure that we get out of parsed message. Even though there are some algorithms listed in https://github.com/hickory-dns/hickory-dns/blob/b2a4707b1a0ca984b10c521946b5763013929bca/crates/proto/src/dnssec/algorithm.rs#L105-L139, they are not supported by this structure. My idea for this would be to just add some of the missing algorithms to the `Algorithm` enum, keeping them unused except for parsing and then to also keep unknown algorithms that were encountered in the `SupportedAlgorithms`, without affecting the existing uses (so not changing the `SupportedAlgorithmsIter` or `has` and similar methods, probably providing separate methods for unsupported algorithms. I am not sure if that would be acceptable, considering the `SupportedAlgorithms` uses a small bit map for all algorithms and this would require additional field, that would probably end up being a `Vec<Algorithm>` or `Vec<u8>`.

kerem commented

2026-03-16 01:50:54 +03:00

Author

Owner

@djc commented on GitHub (Feb 11, 2026):

I'd be willing to review a PR in this direction, but no promises on merging anything. It would be nice to retain some type safety for supported algorithms (not sure if these types are also used via configuration, example, where we'd prefer to have them fail at compile time).

@djc commented on GitHub (Feb 11, 2026): I'd be willing to review a PR in this direction, but no promises on merging anything. It would be nice to retain some type safety for supported algorithms (not sure if these types are also used via configuration, example, where we'd prefer to have them fail at compile time).