From jerry at dns-oarc.net Tue Mar 19 11:50:46 2019 From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=) Date: Tue, 19 Mar 2019 12:50:46 +0100 Subject: [dnstap] IETF104 Hackathon dnstap projects Message-ID: Hi all, I will be attending the hackathon before IETF104 this weekend in Prague and have added a couple of suggestions for projects around DNSTAP which I've added to the hackathon wiki. https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon 1) DNSTAP over CBOR Today DNSTAP messages are delivered using protobuf encapsulated over fstrm, this project will try to use CBOR (RFC 7049) instead of protobuf but still use fstrm for the encapsulation and implement this in both sending (authoritative, resolver) and receiving (dnscap, dsc etc) software. Gist of CDDL example: ?https://gist.github.com/jelu/46d780709047c9c756dba3c5785e7820 2) Brainstorm/hack around DNSTAP and usage of fstrm Current common implementation is that the DNS server software connect out to a fstrm/DNSTAP listener, would also be nice to be able to connect to the DNS server and get the DNSTAP when needed. Comments/thoughts/2c's/+1's/-1's? And if you are attending the hackathon then I hope to see you at the DNS table! Cheers, Jerry From jerry at dns-oarc.net Thu Mar 28 08:25:29 2019 From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=) Date: Thu, 28 Mar 2019 09:25:29 +0100 Subject: [dnstap] IETF104 Hackathon dnstap projects In-Reply-To: References: Message-ID: Hi all, On 3/19/19 12:50 PM, Jerry Lundstr?m wrote: > I will be attending the hackathon before IETF104 this weekend in Prague > and have added a couple of suggestions for projects around DNSTAP which Here is a short summary of the hackathon outcome and the discussions around the projects I added. TL;DR: protobuf and fstrm usage is fine. W.r.t. using CBOR instead of protobuf: - protobuf is not a problem for anyone - CBOR could have a positive performance impact (preliminary tests showed 20-25% faster but might be related to protobuf-c) - replacing protobuf with CBOR will be hard, all tooling needs to be in place beforehand W.r.t. fstrm usage: - no problem with the design (srv connecting to cli) - fstrm recently got updates, TCP writer support etc - fstrm actually helps if migration to CBOR would be done, you can dual support DNSTAP over protobuf and CBOR at the same time and let the client/server negotiate what to use Cheers, Jerry From paul at redbarn.org Fri Mar 29 16:13:24 2019 From: paul at redbarn.org (Paul Vixie) Date: Fri, 29 Mar 2019 09:13:24 -0700 Subject: [dnstap] dnstap status Message-ID: <93251f0d-25fd-ce4d-9708-22aa53696d3d@redbarn.org> i heard folks talking about dnstap as abandonware, during ietf prague, and planning a rescue. allow me to clarify. dnstap is open source software, effectively owned by those who use it, who integrate it, who enhance it, and who submit bug reports to it. farsight funded the initial development, and we act as reviewers for pull requests, but more volunteers for that would be welcomed. if you think dnstap needs something-- say so on this mailing list, get a discussion going. if you know people who use or could or might use or integrate dnstap, who are not on this mailing list, please invite them. if there's finally critical mass for it, we should get cracking on an RFC to describe both dnstap and fstrm. and if there's critical mass for it, we should consider mentoring GSoC students who want to work in this area. and if there's critical mass for it, we should have periodic hackathons via videoconferencing. the dnstap is whoever shows up and contributes. no adoption or rescue is needed. just show up and contribute. -- P Vixie From matt at conundrum.com Fri Mar 29 16:19:12 2019 From: matt at conundrum.com (Matthew Pounsett) Date: Fri, 29 Mar 2019 17:19:12 +0100 Subject: [dnstap] dnstap status In-Reply-To: <93251f0d-25fd-ce4d-9708-22aa53696d3d@redbarn.org> References: <93251f0d-25fd-ce4d-9708-22aa53696d3d@redbarn.org> Message-ID: On Fri, 29 Mar 2019 at 17:13, Paul Vixie wrote: > i heard folks talking about dnstap as abandonware, during ietf prague, > and planning a rescue. > If that was one of my conversations you overheard, we were actually talking about the dnstap *draft* being abandoned, not the software. I'm one of the authors on that and have set it aside for about a year now because I wasn't getting any help. Some offers of help materialized this week, and I have high hopes that we'll be trying to get it rolling again. The plan was always to document the current state in an independent stream RFC, and then come back and -bis the thing in DNSOP with some more eyes on the protocol. I'm aware of some ongoing discussions about what that might look like, including reducing or removing the dependence on protobufs. That seems, to me, to be preliminary but I expect it'll make its way to public discussion before long. -------------- next part -------------- An HTML attachment was scrubbed... URL: From merike at doubleshotsecurity.com Fri Mar 29 22:11:02 2019 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Fri, 29 Mar 2019 15:11:02 -0700 Subject: [dnstap] dnstap status In-Reply-To: References: <93251f0d-25fd-ce4d-9708-22aa53696d3d@redbarn.org> Message-ID: embedded... > On Mar 29, 2019, at 9:19 AM, Matthew Pounsett wrote: > > > > On Fri, 29 Mar 2019 at 17:13, Paul Vixie > wrote: > i heard folks talking about dnstap as abandonware, during ietf prague, > and planning a rescue. > > If that was one of my conversations you overheard, we were actually talking about the dnstap *draft* being abandoned, not the software. I'm one of the authors on that and have set it aside for about a year now because I wasn't getting any help. Some offers of help materialized this week, and I have high hopes that we'll be trying to get it rolling again. That is great news. I had to abandon work when family needs became priority and there was noone else shepherding and moving the work along. All who were part of the meetings over a year ago at DNS-OARC and IETF was always greatly appreciated. It just needed someone to be the lead and driver. > The plan was always to document the current state in an independent stream RFC, and then come back and -bis the thing in DNSOP with some more eyes on the protocol. I'm aware of some ongoing discussions about what that might look like, including reducing or removing the dependence on protobufs. That seems, to me, to be preliminary but I expect it'll make its way to public discussion before long. Cool. I still care although am now on sidelines (still have family as priority?..life events usurp volunteer work). Nice to see this pick up. - merike > > _______________________________________________ > dnstap mailing list > dnstap at lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/dnstap -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: