[dnstap] message tagging (was: Re: suggested optional fields for DNSTAP)

[Robert Edmonds]

Hi, Joe:

Thinking about this some more, what do you think about promoting the tag
to being a field in the top-level dnstap.Dnstap type?

Currently it doesn't make much difference whether we put the tag field
in dnstap.Dnstap or dnstap.Message, because dnstap.Message is the only
type of dnstap payload defined at the moment.  But in the future we
might want to add other types of payloads (e.g., dnstap.CacheOperation,
representing RRsets being added or replaced in the server's cache), and
it might be useful to correlate, say, a specific (tagged) dnstap.Message
payload with particular RRsets being inserted into the cache.  But,
maybe it's sufficient to simply have a 'tag' field in each payload type
that can logically receive a tag.

(Thanks for pinging me about this last month, too.)

Robert Edmonds wrote:
> Ah, OK, I didn't like the complexity on the protobuf side that the full
> generality of mapping resolver-side messages to all possible client-side
> messages would have required, but that's not what you're proposing here;
> you're explicitly limiting the scope of the tag to being able to
> identify only the first client query that triggered the resolution
> process, if there was one.  I like that a lot better, and it's basically
> just:
> 
>     optional bytes message_tag = ...;
> 
> I think I'd call this a "message tag" rather than a "query tag", just to
> make it a bit clearer.  (E.g., an RR and a CR can be related to each
> other through their tag value, even though neither is a query.)
> 
> Tracking issue here:
> 
>     https://github.com/dnstap/dnstap.pb/issues/3

-- 
Robert Edmonds