[GH-ISSUE #51] Change return from query to just return RRSets? #331

New issue

Closed

opened 2026-03-15 22:01:31 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 22:01:31 +03:00

Owner

Originally created by @bluejekyll on GitHub (Oct 16, 2016).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/51

While working on the SecureClientFuture interface, I realized that returning Message, makes it difficult to implement cacheing over the current interfaces. I'm considering having query() return only RRSets, instead of Message to make caching wrapper libraries simpler. Similarly, I'm finding that I while I like that the SecureClientFuture interface is just a wrapper of ClientFuture, I may transform the returned RRSets. I was thinking of having it strip all unverified RRSets from the response. But I haven't figured this out yet...

I like that Message is returned today, because it allows consumers to do what they want. For cacheing this isn't great though, because there technically is no Message response from a cache request, it would be built on the stack. Similarly, for a DNSSec request the question is what to do with invalid records.

For example: there may be a set of DNSKEY records that have been validated, and a set that could not be validated. This is a valid situation, IMO, as the invalid DNSKEYs may exist as new which haven't yet been signed, or old keys that are in the process of being removed. Obviously we don't want DNSKEYs used which have not been validated, so I'm considering stripping them from the Message RRSets. This seems hacky though, so I'm considering changing the return from query() entirely to make it simpler for both this case and for caching cases.

Does anyone have any strong concerns in this area?

Originally created by @bluejekyll on GitHub (Oct 16, 2016). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/51 While working on the SecureClientFuture interface, I realized that returning Message, makes it difficult to implement cacheing over the current interfaces. I'm considering having `query()` return only RRSets, instead of Message to make caching wrapper libraries simpler. Similarly, I'm finding that I while I like that the SecureClientFuture interface is just a wrapper of ClientFuture, I may transform the returned RRSets. I was thinking of having it strip all unverified RRSets from the response. But I haven't figured this out yet... I like that Message is returned today, because it allows consumers to do what they want. For cacheing this isn't great though, because there technically is no Message response from a cache request, it would be built on the stack. Similarly, for a DNSSec request the question is what to do with invalid records. For example: there may be a set of DNSKEY records that have been validated, and a set that could not be validated. This is a valid situation, IMO, as the invalid DNSKEYs may exist as new which haven't yet been signed, or old keys that are in the process of being removed. Obviously we don't want DNSKEYs used which have not been validated, so I'm considering stripping them from the Message RRSets. This seems hacky though, so I'm considering changing the return from query() entirely to make it simpler for both this case and for caching cases. Does anyone have any strong concerns in this area?

kerem

2026-03-15 22:01:31 +03:00

closed this issue
added the
unclear
label

kerem commented

2026-03-15 22:01:47 +03:00

Author

Owner

@bluejekyll commented on GitHub (Oct 16, 2016):

For reference:

https://github.com/bluejekyll/trust-dns/blob/bfry/future_dnssec/src/client/client_future.rs#L262

@bluejekyll commented on GitHub (Oct 16, 2016): For reference: https://github.com/bluejekyll/trust-dns/blob/bfry/future_dnssec/src/client/client_future.rs#L262

kerem commented

2026-03-15 22:01:52 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 16, 2017):

I will probably make this part of a Resolver, as resolution is not Message based, but instead returned records.

@bluejekyll commented on GitHub (Jan 16, 2017): I will probably make this part of a Resolver, as resolution is not Message based, but instead returned records.

kerem commented

2026-03-15 22:01:57 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 30, 2017):

Closing this as the Resolver seems like a better interface for simplified querying...

@bluejekyll commented on GitHub (Jun 30, 2017): Closing this as the Resolver seems like a better interface for simplified querying...

kerem referenced this issue

2026-03-16 02:02:41 +03:00

[PR #331] [MERGED] Update rusqlite to 0.13 #1367