[dnstap] reading DNSTAP from a remote machine

[Joseph Gersch]

Hi Robert,

   I’m going to be sending you several replies to your earlier emails; I finally got a few hours to get my head above water and do some thinking.  Thank you for your patience.  

   There are some inline comments below.

- Joe Gersch
> On Feb 27, 2015, at 4:14 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> 
> Joseph Gersch wrote:
>>   Is there already a way to have a DNSTAP reader on a remote machine read the framestream from a network socket (IP, port)?  It looks like unbound writes to a LINUX socket, so maybe there is a way to just specify the IP and port # instead of a file path.  On the other hand maybe a reader process has to read the Linux socket and write to a network socket or use TLS.  Has anyone done this yet?  
> 
> Hi, Joe:
> 
> The technical term is usually "Unix domain socket" (or AF_UNIX /
> AF_LOCAL, to be really technical, and the SOCK_STREAM variant of AF_UNIX
> in particular); it's not Linux-specific.  The nice thing about Unix
> sockets is that they can be both plaintext and secure, as long as you
> trust Unix permissions, because the socket can only be connected by
> processes running on the same machine.
> 
> Being able to collect dnstap payload data from multiple remote machines
> over a TCP or TLS connection was definitely envisaged in the original
> dnstap design, and that was part of the reason for preferring a byte
> stream over a message stream; it makes it really easy to mirror the byte
> stream into a network connection.  (Since IP datagrams are limited to
> 64K, and a dnstap payload is potentially >64K, it would have been hard
> to use a message-based design over the network without adding our own
> custom fragmentation scheme.)
> 
> Unfortunately, this mirroring capability doesn't exist quite yet, but
> it's definitely planned, and the design accomodates it.  So the answer
> is, not yet.

OK.  So I built a little python proxy to read the AF_UNIX stream and just push it out to network sockets (I’m ignoring security for now).  Then I wrote several “receivers” that connect to the network socket, read the stream, and draw graphs of RCODES or a pareto of SERVFAIL names and other diagnostic info.  DNSTAP is going to be an incredibly useful tool.  

BTW, I dont know much about it, but what do you think of DNSFLOW?  Seems like it has the possiblity of sampling, and only sends client-responses.  It could be useful at some levels, but DNSTAP seems much more powerful.
> 
> BTW, the reason for using Unix sockets in the first place and using a
> helper utility to mirror data into a TLS connection is that it avoids
> the risk of directly exposing the DNS server implementation to an SSL
> implementation, which we originally concluded DNS server implementers
> would be averse to.  (Actually, I think Unbound uses SSL for its remote
> control socket, but I believe a patch implementing Unix sockets for the
> daemon's control socket was merged recently.)
> 
> -- 
> Robert Edmonds

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4124 bytes
Desc: not available
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20150310/b5d2184d/attachment.bin>