[dnstap] dnstap not writing to unix domain sockets with unbound 1.5.10 on FreeBSD 11-STABLE.

[Murray Stokely]

Thanks for your reply.  I updated the FreeBSD Port to use fstrm 0.3.0 and
sent it to the maintainer
  freebsd at dns-lab.com.

In addition to the version upgrade, I added a line to let the FreeBSD Ports
system understand the way this port runs its test suite, so "make test"
from the Ports Collection will build the test binaries and run the test
suite shell scripts and output the results.

Eventually Dtrace helped me understand that I was getting permission denied
errors when trying to write to the named pipe.  FreeBSD runs unbound as the
unbound user, but I was running dnstap as the root user.  I've filed bug
#1142 with unbound with some thoughts about improving the documentation or
code.

  https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1142

I'm now able to extract this data and create meaningful aggregate
statistics and visualizations with R, RProtoBuf, and ggplot2.

I'm a long-time protobuf user but wasn't previously aware of the CBOR RFC.
Thanks for the pointer.

         - Murray

On Tue, Oct 25, 2016 at 9:26 AM, Robert Edmonds <edmonds at mycre.ws> wrote:

> Murray Stokely wrote:
> > I'm having trouble getting anything out of dnstap with unbound 1.5.10 on
> > FreeBSD 11-STABLE with dustup gocode freshly installed.
> >
> > I've run the fstrm 0.2.0 unit tests on this box to verify that
> > reading/writing to the unix domain sockets is working properly (has
> anyone
> > evaluated GRPC rather than fstrm now that google has released a transport
> > for protocol buffers?)
>
> Hi, Murray:
>
> fstrm 0.3.0 was released a while ago which you might want to upgrade
> to. There was a bug fix in that release that affected establishing the
> Unix socket (https://github.com/farsightsec/fstrm/issues/17).
>
> It looks like the FreeBSD ports system still has the older 0.2.0
> release.
>
> gRPC is interesting. I've looked at it a few times but never used it;
> like a lot of Google's open source projects, it doesn't have a good C
> binding, and with the exception of PowerDNS most DNS servers are
> implemented in C, not C++. If you wanted to add gRPC support to the
> dnstap ecosystem, it would probably be pretty easy to implement a bridge
> that accepts Frame Streams input over a Unix socket and outputs gRPC to
> an external endpoint. (This is also how I planned to implement TLS
> support. Implementing it as a bridge that speaks the plaintext Frame
> Streams protocol on the local host to the dnstap-enabled DNS server
> would let us keep the TLS stack out of the DNS server.)
>
> If I were re-implementing dnstap from scratch today, I would probably
> choose to rely on even less Google technology, so I'd probably choose a
> standardized format like CBOR over protobuf for the serialization
> format. (The dnstap message format uses protobuf 2 and relies on
> features in protobuf 2 like optional fields that have been removed from
> the protobuf 3 format.)
>
> > The dnstap section of my unbound.conf is:
> >
> > dnstap:
> >   dnstap-enable: yes
> >   dnstap-socket-path: "/var/run/unbound/dnstap.sock"
> >   dnstap-send-identity: yes
> >   dnstap-send-version: yes
> >   dnstap-log-resolver-response-messages: yes
> >   dnstap-log-client-query-messages: yes
> >
> > I'm running unbound in a chroot, but I can't find the socket either in or
> > out of the chroot :
>
> The dnstap-socket-path in unbound.conf is the path to a Unix socket that
> the dnstap client in Unbound will attempt to connect to (and re-connect,
> if the connection is broken), *not* a path that Unbound will bind a Unix
> socket to. So the dnstap socket won't appear in the filesystem until the
> dnstap listener is started.
>
> The dnstap client/server socket relationship was modeled on syslog,
> where the DNS server is a dnstap client (or syslog client). The idea was
> that you could have multiple DNS servers running on a single system all
> sending dnstap data to a single collector on the system, or (once TCP or
> TLS support was implemented, which hasn't happened yet), you could have
> a pool of machines running DNS servers sending dnstap data to a
> collector over the network.
>
> > server:
> >   directory: /usr/local/etc/unbound
> >   chroot: /usr/local/etc/unbound
> >
> > First I run two dustup listeners (as I'm not sure if its supposed to be
> > inside the chroot or not):
> >
> > dnstap -u /var/run/unbound/dnstap.sock -w /root/dnstap.1
> >
> > dnstap -u /usr/local/etc/unbound/var/run/unbound/dnstap.sock -w
> > /root/dnstap.2
>
> I'm actually not sure about this point without reading the code, but I
> think that the dnstap socket needs to be inside the chroot, because the
> connection can be broken and re-established during runtime (e.g. if the
> collector is restarted).
>
> > Then I start unbound:
> >
> > # sh /usr/local/etc/rc.d/unbound start
> >
> > Obtaining a trust anchor:.
> >
> > Starting unbound.
> >
> > [1477374748] unbound[10467:0] debug: creating udp4 socket 0.0.0.0 53
> > [1477374748] unbound[10467:0] debug: creating tcp4 socket 0.0.0.0 53
> > [1477374748] unbound[10467:0] debug: switching log to syslog
> >
> > unbound works fine, but I am not seeing anything written out to my
> > /root/dnstap files.
>
> Have you looked in syslog? The dnstap client in Unbound should generate
> some log messages, at least.
>
> > I spent a little time playing around with ktrace and dtrace but I haven't
> > yet really figured out what is going on or why it is not writing out
> logs.
> >
> > Any pointers for debugging why messages don't seem to be getting sent to
> > the domain socket?  Thanks,
>
> You might also ask on the unbound-users mailing list if we can't get
> your problem solved here :-)
>
> --
> Robert Edmonds
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20161026/5fd8e36b/attachment.html>