[GH-ISSUE #3076] Consider lifting EDNS handling up from Catalog to ServerFuture #1124

New issue

Open

opened 2026-03-16 01:41:02 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 01:41:02 +03:00

Owner

Originally created by @cpu on GitHub (Jun 20, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3076

Missed this the first time, but would it perhaps make more sense to handle NSID at the ServerFuture level instead of the Catalog level?

Originally posted by @djc in https://github.com/hickory-dns/hickory-dns/pull/3070#discussion_r2159226609

The RequestHandler trait will need to be updated to accept response_edns: Option<Edns> as an argument. The catalog code handing the request EDNS to produce the initial response EDNS could then be lifted to the server future code somewhere.

Some other refactoring will have to be done to figure out where to stash the NSID payload state for populating in the response_edns when the request EDNS is evaluated. The ServerFuture struct is perhaps a good place, but the handle_request() fn that ends up invoking the RequestHandler will need some kind of &ServerFuture.

Originally created by @cpu on GitHub (Jun 20, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3076 > Missed this the first time, but would it perhaps make more sense to handle NSID at the `ServerFuture` level instead of the `Catalog` level? _Originally posted by @djc in https://github.com/hickory-dns/hickory-dns/pull/3070#discussion_r2159226609_ The `RequestHandler` trait will need to be updated to accept `response_edns: Option<Edns>` as an argument. The catalog code handing the request EDNS to produce the initial response EDNS could then be lifted to the server future code somewhere. Some other refactoring will have to be done to figure out where to stash the NSID payload state for populating in the `response_edns` when the request EDNS is evaluated. The `ServerFuture` struct is perhaps a good place, but the `handle_request()` fn that ends up invoking the `RequestHandler` will need some kind of `&ServerFuture`.