[GH-ISSUE #3121] Tower-compatible services for hickory-server #1136

New issue

Open

opened 2026-03-16 01:42:42 +03:00 by kerem · 3 comments

kerem commented

2026-03-16 01:42:42 +03:00

Owner

Originally created by @alexrudy on GitHub (Jul 14, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3121

The hickory-server::ServeFuture implements what is effectively a tower::Service over the different transport protocols, creating a MakeService for each transport, and building a service which accepts a request and (in some cases) returns a response. Exposing such a service would allow for combining hickory-dns servers with the rest of the tower ecosystem and taking advantage of e.g. the wide availability of middleware.

Originally created by @alexrudy on GitHub (Jul 14, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3121 The [hickory-server::ServeFuture](https://docs.rs/hickory-server/latest/hickory_server/server/struct.ServerFuture.html) implements what is effectively a tower::Service over the different transport protocols, creating a MakeService for each transport, and building a service which accepts a request and (in some cases) returns a response. Exposing such a service would allow for combining hickory-dns servers with the rest of the tower ecosystem and taking advantage of e.g. the wide availability of middleware.

kerem commented

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

Author

Owner

@djc commented on GitHub (Jul 15, 2025):

Exposing such a service would allow for combining hickory-dns servers with the rest of the tower ecosystem and taking advantage of e.g. the wide availability of middleware.

Can you be more specific about what you're looking for? What problem or use case would this be trying to solve for?

(Note that I've already decomposed the ServerFuture -- now called Server -- quite a bit on main compared to 0.25.x. The direction I have in mind is to build more per-protocol public API which would potentially make it easier to wrap tower::Service stuff around it.)

@djc commented on GitHub (Jul 15, 2025): > Exposing such a service would allow for combining hickory-dns servers with the rest of the tower ecosystem and taking advantage of e.g. the wide availability of middleware. Can you be more specific about what you're looking for? What problem or use case would this be trying to solve for? (Note that I've already decomposed the `ServerFuture` -- now called `Server` -- quite a bit on `main` compared to 0.25.x. The direction I have in mind is to build more per-protocol public API which would potentially make it easier to wrap `tower::Service` stuff around it.)

kerem commented

2026-03-16 01:42:53 +03:00

Author

Owner

@alexrudy commented on GitHub (Jul 15, 2025):

One example: tower has good primitives for managing concurrent requests and load shedding, both of which are pretty baked into the internals of the current server.

For my use case, I also have a dynamically updated blocklist I use with most of my other projects, and being able to wrap DNS with the same block list would be handy, where as today that is pretty baked in to the hickory dns server.

A third case: I could see running DoH on a server that has multiple tower-based services running on the same listener.

In all of these cases I can hack my way to making things play nice with Hickory, but being able to throw a standard middleware stack on it would be nice.

@alexrudy commented on GitHub (Jul 15, 2025): One example: tower has good primitives for managing concurrent requests and load shedding, both of which are pretty baked into the internals of the current server. For my use case, I also have a dynamically updated blocklist I use with most of my other projects, and being able to wrap DNS with the same block list would be handy, where as today that is pretty baked in to the hickory dns server. A third case: I could see running DoH on a server that has multiple tower-based services running on the same listener. In all of these cases I can hack my way to making things play nice with Hickory, but being able to throw a standard middleware stack on it would be nice.

kerem commented

2026-03-16 01:42:58 +03:00

Author

Owner

@djc commented on GitHub (Jul 15, 2025):

Okay, if you want to move the code in this direction I can probably review it. Make sure to make small atomic commits, though.

@djc commented on GitHub (Jul 15, 2025): Okay, if you want to move the code in this direction I can probably review it. Make sure to make small atomic commits, though.