starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #3221] RFC: redraw crate lines #1156

New issue

Closed

opened 2026-03-16 01:44:54 +03:00 by kerem · 6 comments

kerem commented

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

Owner

Originally created by @djc on GitHub (Aug 19, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3221

I've been thinking some reorganization of our crates is in order. Here's my proposal:

Move everything to do with transfer/network protocols/I/O out of -proto into a new -net crate. This drastically simplifies the dependency situation in -proto which makes sense for something that ought to be primarily about the low-level data types. It also allows all the runtime/network dependencies (tokio, rustls, hyper, quinn) to be built in parallel with -proto itself.
Subsume the client crate contents into the -net crate as well. The client crate is pretty small and in practice closely tied to the proto::xfer stuff. I don't think it really makes sense on its own.

What do people think?

Originally created by @djc on GitHub (Aug 19, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/3221 I've been thinking some reorganization of our crates is in order. Here's my proposal: - Move everything to do with transfer/network protocols/I/O out of -proto into a new -net crate. This drastically simplifies the dependency situation in -proto which makes sense for something that ought to be primarily about the low-level data types. It also allows all the runtime/network dependencies (tokio, rustls, hyper, quinn) to be built in parallel with -proto itself. - Subsume the client crate contents into the -net crate as well. The client crate is pretty small and in practice closely tied to the `proto::xfer` stuff. I don't think it really makes sense on its own. What do people think?

kerem closed this issue

2026-03-16 01:44:59 +03:00

kerem commented

2026-03-16 01:45:05 +03:00

Author

Owner

@djc commented on GitHub (Aug 28, 2025):

@cpu @marcus0x62 @bluejekyll opinions? ("No" is also a valid answer.)

@djc commented on GitHub (Aug 28, 2025): @cpu @marcus0x62 @bluejekyll opinions? ("No" is also a valid answer.)

kerem commented

2026-03-16 01:45:10 +03:00

Author

Owner

@cpu commented on GitHub (Aug 28, 2025):

This drastically simplifies the dependency situation in -proto which makes sense for something that ought to be primarily about the low-level data types.

This makes sense to me. I'm supportive 👍

Subsume the client crate contents into the -net crate as well.

I have less of an opinion here, but it sounds like a reasonable proposal if it doesn't increase the dep. surface of the -net crate.

@cpu commented on GitHub (Aug 28, 2025): > This drastically simplifies the dependency situation in -proto which makes sense for something that ought to be primarily about the low-level data types. This makes sense to me. I'm supportive 👍 > Subsume the client crate contents into the -net crate as well. I have less of an opinion here, but it sounds like a reasonable proposal if it doesn't increase the dep. surface of the `-net` crate.

kerem commented

2026-03-16 01:45:15 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Aug 30, 2025):

Moving networking/IO code out to a new crate makes sense to me.

I'm less convinced about moving hickory-client into proto though - maybe move client into resolver (or, although it would have a bigger blast radius, move resolver into client.) I think there's an argument for having the different client interfaces (the low level query interface in client, the stub resolver in resolver and the recursive lookup implementation in recursor exposed as different client interfaces in the client crate.

@marcus0x62 commented on GitHub (Aug 30, 2025): Moving networking/IO code out to a new crate makes sense to me. I'm less convinced about moving hickory-client into proto though - maybe move client into resolver (or, although it would have a bigger blast radius, move resolver into client.) I think there's an argument for having the different client interfaces (the low level query interface in client, the stub resolver in resolver and the recursive lookup implementation in recursor exposed as different client interfaces in the client crate.

kerem commented

2026-03-16 01:45:20 +03:00

Author

Owner

@djc commented on GitHub (Aug 30, 2025):

No, sorry -- the client would move along with the net stuff.

@djc commented on GitHub (Aug 30, 2025): No, sorry -- the client would move along with the net stuff.

kerem commented

2026-03-16 01:45:25 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Aug 30, 2025):

Sorry I misread that - that makes sense to me.

@marcus0x62 commented on GitHub (Aug 30, 2025): Sorry I misread that - that makes sense to me.

kerem commented

2026-03-16 01:45:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Aug 30, 2025):

This makes sense, I like the idea of pulling all the network related stuff into this new crate. It might be a little challenging to pull these things apart though.

@bluejekyll commented on GitHub (Aug 30, 2025): This makes sense, I like the idea of pulling all the network related stuff into this new crate. It might be a little challenging to pull these things apart though.

kerem referenced this issue

2026-03-16 04:41:44 +03:00

[PR #1156] [MERGED] Bump radix_trie from 0.1.6 to 0.2.0 #2018