• David Vasek's avatar
    doc/dnstap: remove a dead link to Bugzilla at nlnetlabs.nl · 7e306eb0
    David Vasek authored
    An important comment from the page that has been removed from the web:
    
    -----------------------------------------------------------------------------------------------------
    From the following page (Bugzilla at NLnet Labs), which isn't available anymore.
    https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?format=multiple&id=741.
    -----------------------------------------------------------------------------------------------------
    
    Bug 741
    
    [...]
    
       Comment 10 Robert Edmonds 2016-01-27 17:15:04 CET
    Hi, Igor:
    
    The dnstap code in the DNS server (like Unbound), functions as a client rather than a server. It
    needs a server on the other end of the socket to accept connections. I did it this way instead of
    the other way around so that a single socket could be used to accept messages from several dnstap
    senders. This is similar to how a syslog daemon listens for log messages from multiple processes at
    a well-known AF_UNIX socket like /dev/log.
    
    The server has to handshake with the client so that the client knows it is connected to the right
    kind of server before it will begin sending frames. You cannot use mkfifo because the connection is
    not a named pipe, and unless you can send the binary sequences used for the handshake frames I doubt
    socat will work that well either.
    
    If the AF_UNIX socket is not present, or the connection fails somehow, the connection will
    automatically be reattempted, no often than every 5 seconds. (This is the default, but can be
    changed with fstrm_iothr_options_set_reopen_interval(), though the Unbound dnstap implementation
    just uses the default and doesn't expose this as a configuration knob.)
    
    In the fstrm distribution is a utility called fstrm_capture that can be used to serve a capture
    socket (it uses libevent and can multiplex traffic from multiple connected clients). Usage looks
    like:
    
    "fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/dnstap.sock -w /tmp/dnstap.out -ddddd"
    
    Run this command before you start Unbound, otherwise if you start it after Unbound you may need to
    send queries to the Unbound server (to force data into the fstrm queue) and wait for the reopen
    interval to expire before Unbound attempts to reconnect.
    
    This will listen on /tmp/dnstap.sock for connections of type "protobuf:dnstap.Dnstap" (the type used
    by dnstap) and write the output to /tmp/dnstap.out. "-ddddd" will produce very high verbosity trace
    output.
    
    There is some more relevant info to setting up Unbound and dnstap in the comment on this bug report,
    when dnstap was originally integrated into Unbound:
    https://open.nlnetlabs.nl/bugs-script/show_bug.cgi?id=621#c1.
    (The step #5 is obsolete now, since the dnstap patch is in the mainline source tree.)
    
    There was also a very nice webinar produced last month by Carsten Strotmann and Men and Mice that
    covers using dnstap with Unbound and a few other servers, available here:
    
    https://www.menandmice.com/resources/educational-resources/webinars/dnstap-webinar/
    
    Hope this helps!
    
    -----------------------------------------------------------------------------------------------------
    7e306eb0
Name
Last commit
Last update
..
cookies Loading commit data...
dnsproxy Loading commit data...
dnstap Loading commit data...
geoip Loading commit data...
noudp Loading commit data...
onlinesign Loading commit data...
queryacl Loading commit data...
rrl Loading commit data...
stats Loading commit data...
synthrecord Loading commit data...
whoami Loading commit data...
static_modules.h.in Loading commit data...