[GH-ISSUE #1814] Getting the response wireformat #778

New issue

Closed

opened 2026-03-16 00:12:27 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 00:12:27 +03:00

Owner

Originally created by @mattias-p on GitHub (Oct 31, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1814

I have this use case where I need to send out DNS queries and save the wireformat of each response. AFAICT trust-dns doesn't really support this use case today. The wireformat gets parsed into an internal representation before I can get my hands on it. From the internal representation I can serialize a new wireformat string, but this is inefficient and there doesn't seem to be any guarantees that this produces an identical wireformat string.

Ideally I'd like trust-dns to postpone parsing the wireformat for as long as possible and provide a public API just below this point.

Other possibilities:

Guarantee that the parse-serialize round-trip is an identity function.
Let the caller provide some callback that gets called with the wireformat string before it's dropped.

A while ago I tried to refactor the code base to postpone the parsing but it wasn't easy. I'd like to make another stab at it but I'd like to hear your opinion on it and if you have any ideas of how it should be done.

Originally created by @mattias-p on GitHub (Oct 31, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1814 I have this use case where I need to send out DNS queries and save the wireformat of each response. AFAICT trust-dns doesn't really support this use case today. The wireformat gets parsed into an internal representation before I can get my hands on it. From the internal representation I can serialize a new wireformat string, but this is inefficient and there doesn't seem to be any guarantees that this produces an identical wireformat string. Ideally I'd like trust-dns to postpone parsing the wireformat for as long as possible and provide a public API just below this point. Other possibilities: * Guarantee that the parse-serialize round-trip is an identity function. * Let the caller provide some callback that gets called with the wireformat string before it's dropped. A while ago I tried to refactor the code base to postpone the parsing but it wasn't easy. I'd like to make another stab at it but I'd like to hear your opinion on it and if you have any ideas of how it should be done.

kerem closed this issue

2026-03-16 00:12:32 +03:00

kerem commented

2026-03-16 00:12:38 +03:00

Author

Owner

@djc commented on GitHub (Oct 31, 2022):

Can you show some example code? It seems sensible to support this use case depending on the amount of complexity it adds.

@djc commented on GitHub (Oct 31, 2022): Can you show some example code? It seems sensible to support this use case depending on the amount of complexity it adds.

kerem commented

2026-03-16 00:12:43 +03:00

Author

Owner

@mattias-p commented on GitHub (Nov 4, 2022):

I couldn't find my previous failed attempt so I tried again and this time I managed to power through all the type errors. I ended up using a different approach than what I suggested in the description above. Instead of letting the responses propagate as SerialMessages up to some point near the top level API I used generics to let the caller decide if responses are to be returned as Messages or SerialMessages.

See #1823.

@mattias-p commented on GitHub (Nov 4, 2022): I couldn't find my previous failed attempt so I tried again and this time I managed to power through all the type errors. I ended up using a different approach than what I suggested in the description above. Instead of letting the responses propagate as SerialMessages up to some point near the top level API I used generics to let the caller decide if responses are to be returned as Messages or SerialMessages. See #1823.

kerem referenced this issue

2026-03-16 02:19:30 +03:00

[PR #779] [MERGED] only enable socket2/reuseport for mDNS #1679