From matt at conundrum.com Thu Jul 20 09:16:15 2017 From: matt at conundrum.com (Matthew Pounsett) Date: Thu, 20 Jul 2017 11:16:15 +0200 Subject: [dnstap] Caching status of Client Response messages Message-ID: 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: From list-dnstap at dragon.net Thu Jul 20 09:39:48 2017 From: list-dnstap at dragon.net (Paul Ebersman) Date: Thu, 20 Jul 2017 11:39:48 +0200 Subject: [dnstap] Caching status of Client Response messages In-Reply-To: References: Message-ID: <20170720093948.991F87BF6C6@fafnir.remote.dragon.net> matt> The request was for a field to indicate when a CR is filled from matt> cached information or results in iterative queries. [...] matt> The second approach is to use a bit field. Since protobufs don't matt> have a bit or flag type this would most likely be implemented as a matt> uint that name servers and consumers would need to do bit math matt> on.?? The same three items would be defined in the bit field, with matt> some other bits reserved for future expansion, and anything matt> remaining available for implementation-specific values. matt> Since there were no large recursive operators in the conversation matt> we weren't sure if there was a use case for consuming the more matt> complex data. As a former large recursive operator who did DNSSEC validation, the 2nd option would be very handy for giving an idea of what mix of cached and iterative data goes into answering queries. Would also give me some idea of what damange folks doing lots of short TTLs but DNSSEC signing were doing to me in terms of cache misses vs hits.