[GH-ISSUE #624] Expose send on the SyncClient #255

New issue

Open

opened 2026-03-07 23:02:33 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 23:02:33 +03:00

Owner

Originally created by @mattias-p on GitHub (Nov 21, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/624

I need to send queries with the RD flag disables. I started out with the SyncClient hello world example and just inlined my way towards the Message. However I can't inline client::ClientHandle::query because client::ClientResponse's data member is private and there's no constructor.

A public constructor for ClientResponse would solve my problem. Making the data member public would also work, but from my limited understanding it makes more sense to keep ClientResponse opaque.

Originally created by @mattias-p on GitHub (Nov 21, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/624 I need to send queries with the RD flag disables. I started out with the SyncClient hello world example and just inlined my way towards the Message. However I can't inline client::ClientHandle::query because client::ClientResponse's data member is private and there's no constructor. A public constructor for ClientResponse would solve my problem. Making the data member public would also work, but from my limited understanding it makes more sense to keep ClientResponse opaque.

kerem added the

enhance

crate:client

easy

labels

2026-03-07 23:02:33 +03:00

kerem commented

2026-03-07 23:02:44 +03:00

Author

Owner

@bluejekyll commented on GitHub (Nov 22, 2018):

I don't think this is actually what you want. Based on your description, you want to have more control over how the DnsRequest is constructed, or even directly send your own message. This method exists, but currently only exists on the ClientFuture, the async version of the SyncClient. It's the DnsHandle::send method implemented on BasicClientHandle (returned during construction of the ClientFuture). It should be fairly straightforward to expose this on the SyncClient in a similar way as the other methods, query for example, are exposed from the Client trait implementation.

Would you want to make this change to implement Client::send as a delegate to the underlying send method? This should look a lot like the other default implementations on the Client trait.

Another more extensive change we could make would be to create a new pre send hook, where a message could be inspected before send, and allow you to override different portions of the Message prior to it being sent. This might be better in the long run.

@bluejekyll commented on GitHub (Nov 22, 2018): I don't think this is actually what you want. Based on your description, you want to have more control over how the `DnsRequest` is constructed, or even directly send your own message. This method exists, but currently only exists on the `ClientFuture`, the async version of the `SyncClient`. It's the `DnsHandle::send` method implemented on [BasicClientHandle](https://docs.rs/trust-dns/0.15.0/trust_dns/client/struct.BasicClientHandle.html) (returned during construction of the ClientFuture). It should be fairly straightforward to expose this on the `SyncClient` in a similar way as the other methods, `query` for example, are exposed from the `Client` trait implementation. Would you want to make this change to implement `Client::send` as a delegate to the underlying `send` method? This should look a lot like the other default implementations on the `Client` trait. Another more extensive change we could make would be to create a new pre send hook, where a message could be inspected before send, and allow you to override different portions of the `Message` prior to it being sent. This might be better in the long run.

kerem commented

2026-03-07 23:02:49 +03:00

Author

Owner

@mattias-p commented on GitHub (Nov 22, 2018):

Thank you so much for your excellent response! Your explanation validates my general approach and it helped me realize where I went wrong.

I've ended up with this rather nice method fn send(&self, message: Message) -> ClientResult<DnsResponse> (which is derived from client::Client::query). In this method I'm calling DnsHandle::send and I was wrapping its result in a ClientResponse (which is what client::ClientHandle::query ends up doing) before sending it on to tokio::runtime::Runtime::block_on (which is what client::Client::query does). I just didn't realize that I could replace runtime.block_on(ClientResponse(future)) with Ok(runtime.block_on(future)?).

I'm quite happy with that solution. For me getting my hands on the async stuff is pure gravy as I was planning to go that route anyway.

@mattias-p commented on GitHub (Nov 22, 2018): Thank you so much for your excellent response! Your explanation validates my general approach and it helped me realize where I went wrong. I've ended up with this rather nice method `fn send(&self, message: Message) -> ClientResult<DnsResponse>` (which is derived from `client::Client::query`). In this method I'm calling `DnsHandle::send` and I was wrapping its result in a `ClientResponse` (which is what `client::ClientHandle::query` ends up doing) before sending it on to `tokio::runtime::Runtime::block_on` (which is what `client::Client::query` does). I just didn't realize that I could replace `runtime.block_on(ClientResponse(future))` with `Ok(runtime.block_on(future)?)`. I'm quite happy with that solution. For me getting my hands on the async stuff is pure gravy as I was planning to go that route anyway.

kerem referenced this issue

2026-03-15 22:25:08 +03:00

[GH-ISSUE #255] Server TLS test keys need to be rotated #418

kerem referenced this issue

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

[PR #284] [MERGED] Update certs and cleanup dns-over-tls tests #1345