Re: [dnstap] dnstap fanout and replay

Paul Vixie wrote: > Jerry Lundström wrote: > > > > I would gladly see dnstap move towards CBOR, it's basically the same thing > > as msgpack/protobuf so the transition should be easy. > > > > cbor is pretty recent. does it have a code generator for C yet? RFC 7049 is from 2013, which was five

Re: [dnstap] dnstap fanout and replay

Jerry Lundström wrote: > I would gladly see dnstap move towards CBOR, it's basically the same thing > as msgpack/protobuf so the transition should be easy. There are major differences among CBOR, msgpack, and protobuf. It doesn't really make sense to refer to them all as basically the same thing.

Re: [dnstap] dnstap fanout and replay

On 25 April 2018 at 12:43, Paul Vixie wrote: > > > Matthew Pounsett wrote: > >> ... >> >> I like C-DNS for long term storage, but even its creators agree that >> it's not particularly good at streaming data, which is a basic >> requirement of any useful dnstap deployment. So,

Re: [dnstap] dnstap fanout and replay

Matthew Pounsett wrote: ... I like C-DNS for long term storage, but even its creators agree that it's not particularly good at streaming data, which is a basic requirement of any useful dnstap deployment. So, I don't see us moving in that direction. Someone might want to write a

Re: [dnstap] dnstap fanout and replay

On 25 April 2018 at 04:13, Paul Vixie wrote: > > dnstap is now years old. i don't expect it to change its on-wire format. >>> >> >> But it would be really good to move away from a proprietary format. >> > > i don't think it's proprietary in any sense. google open sourced it. >

Re: [dnstap] dnstap fanout and replay

Jerry Lundström wrote: On Tue, 2018-04-24 at 07:24 -0700, Paul Vixie wrote: cbor is pretty recent. does it have a code generator for C yet? There are plenty of libraries for reading and writing CBOR today in multiple languages. The "code generator" is protobuf specific. so, cbor is

Re: [dnstap] dnstap fanout and replay

On Fri, 2018-04-13 at 17:43 -0400, Matthew Pounsett wrote: > On 13 April 2018 at 13:59, Tony Finch wrote: > > > The dnstap implementation in BIND only supports one output stream, so if > > we are going to satisfy these consumers, we would need to split the dnstap > > feed

Re: [dnstap] dnstap fanout and replay

> On 13 Apr 2018, at 22:27, Robert Edmonds wrote: > > The component doesn't even need to be on the same machine as the DNS server > if you're using the 'next' branch of fstrm, which has TCP support, though > BIND would probably need to be updated to allow configuring an

Re: [dnstap] dnstap fanout and replay

Tony Finch wrote: > We have a couple of kinds of people who have expressed interest in getting > dnstap feeds from our campus resolvers. > > * There are people on site doing threat intelligence research, who would > like a full feed of client queries and responses. > > * And there are third