[dnstap] reading DNSTAP from a remote machine
joe.gersch at secure64.com
Tue Mar 10 19:54:55 UTC 2015
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...
Size: 4124 bytes
Desc: not available
More information about the dnstap