[dnstap] Caching status of Client Response messages

[Matthew Pounsett]

There are a couple of outstanding feature requests in the proto file's
github issue tracker which some of us were discussing yesterday.  A couple
of different ways to implement one of them came up, but we couldn't come to
consensus on which was the better approach.  We thought we'd bring it to
the list at large to see if there are any strong opinions out there.

The request was for a field to indicate when a CR is filled from cached
information or results in iterative queries.

One approach is to have an ENUM type which flags the CR as either:
1) data obtained from one or more iterative queries
2) cached data
3) authoritative data

The name server implementation would choose from these options using the
first match.  So if a response contained a mix of cached data and data
obtained from iterative queries, the first option would be selected.


The second approach is to use a bit field.  Since protobufs don't have a
bit or flag type this would most likely be implemented as a uint that name
servers and consumers would need to do bit math on.  The same three items
would be defined in the bit field, with some other bits reserved for future
expansion, and anything remaining available for implementation-specific
values.


The first option is the easiest to implement.  The second has increased
flexibility in that it can indicate when a CR is exclusively cached data,
or iterative data, or both.  It also allows implementations with more
complex caching to use implementation-specific bits to indicate special
things, such as which cache was used.. but is obviously more processing to
both generate and consume the data, and is much less "protobuf-ish".


Since there were no large recursive operators in the conversation we
weren't sure if there was a use case for consuming the more complex data.

Does anyone have any thoughts on which general approach is most useful?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20170720/3b37b207/attachment.html>