[dnstap] dnstap use case assistance

[Kyle Fiducia]

Paul, Robert,
Let me first say thank you to both of your for your immense
contributions to the space, and for taking the time to push me in the
right direction! Its humbling to have people that have made such
significant contributions offer assistance.
I am using the golang-dnstap tool to read the socket, and after Paul's
assurance the data was there, I educated myself further on how to get
more verbose data out of the stream with golang-dnstap. I was
previously just dumping to stdout, incorrectly assuming it would offer
what I was looking for and found what Robert just explained: use the
-y.
As Paul promised, the data is there, and accomplishes my goal. My next
task is finding an efficient way to parse the answer section, store,
and query this data. For now, I am pleased to have a such a useful and
cleverly designed tool to work with.

Thanks to you both!

Kind Regards,
Kyle


On Sat, May 13, 2017 at 12:19 AM, Robert Edmonds <edmonds at mycre.ws> wrote:
> Kyle Fiducia wrote:
>> But the logs I am seeing coming out of DNS tap reference the
>> responding authoritative server. So it mentions "evil-host.tld" but
>> gives the authoritative nameserver IP address that responded with the
>> A record, not the contents of the A record, so 1.2.3.4 is not present
>> in my logs.
>
> Hi, Kyle:
>
> The data you're looking for is going to be included in the DNS answer
> section of the DNS response message payload. And there might be more
> than one A record for "evil-host.tld" in the response, of course.
>
> What tool are you using to decode your dnstap logs? The three dedicated
> tools that I'm aware of (the standalone dnstap-ldns and golang-dnstap
> tools, and the dnstap-read tool included with BIND) default to using a
> compact one line per message representation that resembles what you
> described above, but they also have a more verbose format that can be
> enabled with the '-y' parameter which includes a full decode of the DNS
> response sections.
>
> BTW, at one point I was working on adding support for decoding Frame
> Streams files with dnstap-encoded payloads to Wireshark. I started it
> but didn't finish it; the hardest part looked like it was going to be
> integrating a protobuf decoder and code generator into the build system
> (and making it work on the platforms supported by Wireshark), rather
> than actually implementing the dnstap dissector.
>
> --
> Robert Edmonds