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.

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.