[GH-ISSUE #1613] Make low-level request details available in high-level APIs (like `Authority`) #711

New issue

Closed

opened 2026-03-15 23:55:25 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 23:55:25 +03:00

Owner

Originally created by @moschroe on GitHub (Jan 5, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1613

Is your feature request related to a problem? Please describe.
I am creating a DNS proxy that intercepts and manipulates traffic according to a configuration (think name/record type whitelist) by implementing a custom Authority. It should also be able to handle a split horizon configuration (substituting/adding RRs in the context of a distributed system) where answers might depend on the origin of the query.

Describe the solution you'd like
In order to decide on legitimacy of the request and required/allowed RRs, the Authority needs to have access to lower level request details. Ideally, it would get RequestInfo, maybe src: SocketAddr might be sufficient for a start and the most cumbersome solution would be Header::id: u16 (with the caveat that it is client-controlled and might have collisions!).

Describe alternatives you've considered
I currently run a locally patched version of the repo where I threaded request_info: RequestInfo<'_> through the entire Authority trait but I am unsure whether this is too much of violation of design/separation of concern.
In case of the latter, either a special struct with connection details, just for use in client (as in library users) APIs, could be crafted or, at the very least, an internal, unique ID field could be associated with a query that is made available to any API. This would follow the C model of customizable APIs where it is customary to allow a pointer to be associated with an API entity that is then provided to any user callback. With such an ID, a library user could implement a RequestHandler (a Catalog wrapper) associating a random ID with a query, store any request details in (for example) a Dashmap and the Authority implementation could then use this provided "context ID" to correlate a query to this information again.

Additional context
Discovered #1441, which might require similar solutions

Originally created by @moschroe on GitHub (Jan 5, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1613 **Is your feature request related to a problem? Please describe.** I am creating a DNS proxy that intercepts and manipulates traffic according to a configuration (think name/record type whitelist) by implementing a custom `Authority`. It should also be able to handle a split horizon configuration (substituting/adding RRs in the context of a distributed system) where answers might depend on the origin of the query. **Describe the solution you'd like** In order to decide on legitimacy of the request and required/allowed RRs, the `Authority` needs to have access to lower level request details. Ideally, it would get `RequestInfo`, maybe `src: SocketAddr` might be sufficient for a start and the most cumbersome solution would be `Header::id: u16` (with the caveat that it is client-controlled and might have collisions!). **Describe alternatives you've considered** I currently run a locally patched version of the repo where I threaded `request_info: RequestInfo<'_>` through the entire `Authority` trait but I am unsure whether this is too much of violation of design/separation of concern. In case of the latter, either a special struct with connection details, just for use in client (as in library users) APIs, could be crafted or, at the very least, an internal, unique ID field could be associated with a query that is made available to any API. This would follow the C model of customizable APIs where it is customary to allow a pointer to be associated with an API entity that is then provided to any user callback. With such an ID, a library user could implement a `RequestHandler` (a `Catalog` wrapper) associating a random ID with a query, store any request details in (for example) a `Dashmap` and the `Authority` implementation could then use this provided "context ID" to correlate a query to this information again. **Additional context** Discovered #1441, which might require similar solutions

kerem closed this issue

2026-03-15 23:55:30 +03:00

kerem commented

2026-03-15 23:55:36 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 6, 2022):

Can you point to the function you'd want changed? I think it would be possible to pass RequestInfo into https://docs.rs/trust-dns-server/0.21.0-alpha.4/trust_dns_server/authority/trait.Authority.html#tymethod.search instead of just the query for example. That seems like a change that is necessary for other reasons anyway.

@bluejekyll commented on GitHub (Jan 6, 2022): Can you point to the function you'd want changed? I think it would be possible to pass `RequestInfo` into https://docs.rs/trust-dns-server/0.21.0-alpha.4/trust_dns_server/authority/trait.Authority.html#tymethod.search instead of just the query for example. That seems like a change that is necessary for other reasons anyway.

kerem commented

2026-03-15 23:55:41 +03:00

Author

Owner

@moschroe commented on GitHub (Jan 16, 2022):

Sorry for the late reply. Having the RequestInfo available in Authority::search() would certainly work for my use case. It would avoid changing other structs by just passing it on accordingly.

@moschroe commented on GitHub (Jan 16, 2022): Sorry for the late reply. Having the `RequestInfo` available in `Authority::search()` would certainly work for my use case. It would avoid changing other structs by just passing it on accordingly.

kerem referenced this issue

2026-03-16 02:16:31 +03:00

[PR #711] [MERGED] Bump toml from 0.4.10 to 0.5.0 #1622