8000
Skip to content

Expose nameserver send - #3751

Draft
AlisonT1230 wants to merge 4 commits into
hickory-dns:mainfrom
AlisonT1230:expose-nameserver-send
Draft

Expose nameserver send#3751
AlisonT1230 wants to merge 4 commits into
hickory-dns:mainfrom
AlisonT1230:expose-nameserver-send

Conversation

@AlisonT1230
@AlisonT1230 AlisonT1230 commented Jun 24, 2026
Copy link
Copy Markdown

NameServer's send method was previously accessible in hickory 0.25 but became private in 0.26. It would be helpful for use cases where only one name server is necessary.

@divergentdave
divergentdave commented Jun 24, 2026
Copy link
Copy Markdown
Collaborator

I don't think we should expose this API publicly. This layer of the internal implementation does not include critical features like truncation handling.

What is your motivation for using NameServer directly instead of Resolver? Are there any friction points you ran into?

@AlisonT1230
AlisonT1230 commented Jun 24, 2026
Copy link
Copy Markdown
Author

I'm working with a project that's built with hickory components but handles a lot of message processing outside of hickory as well (like truncation). It's sensitive to memory & performance constraints. For example, I can see Resolver has a built in response cache based on moka which has been tested to be too memory hungry for my use case so we have an alternative in place. NameServer has just been convenient to use since it's lightweight

@leshow
leshow commented Jun 24, 2026 •
edited
Loading
Copy link
Copy Markdown
Contributor

Just to add, we've been longtime users of the various library components, contributed a few times before and were going through the recent upgrade with all the breaking changes. NameServer itself is public, as is NameServerPool (which has send) but we're plugged in to NameServer and handle the pools differently ourselves, were wondering if that could be made public again so we don't have to maintain a fork.

@djc
djc commented Jun 30, 2026
Copy link
Copy Markdown
Member

@AlisonT1230 @leshow I think it would be useful if you can outline your concerns about the Resolver/NameServerPool abstractions, to see if there are other ways we can alleviate your concerns (for example, by making it possible to disable or swap out the cache implementation). For now I think I agree with @divergentdave that the NameServer abstraction is not designed to be used in a stand-alone fashion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@bluejekyll bluejekyll Awaiting requested review from bluejekyll bluejekyll will be requested when the pull request is marked ready for review bluejekyll is a code owner
@djc djc Awaiting requested review from djc djc will be requested when the pull request is marked ready for review djc is a code owner
@marcus0x62 marcus0x62 Awaiting requested review from marcus0x62 marcus0x62 will be requested when the pull request is marked ready for review marcus0x62 is a code owner
@divergentdave divergentdave Awaiting requested review from divergentdave divergentdave will be requested when the pull request is marked ready for review divergentdave is a code owner
@cpu cpu Awaiting requested review from cpu cpu will be requested when the pull request is marked ready for review cpu is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@AlisonT1230 @divergentdave @leshow @djc
0