Closed johnhtodd closed 3 years ago
not hard to implement, have you some examples in server dns side of this behaviour (open source one) to test-it?
We (Quad9) have code that does this, and I know I've talked to others (sorry, I forget who) at dns-oarc who have implemented similar reversals of dnstap flow models internally. The code we have is heavily utilized in our network, but now that I look at our github account I don't see that we ever got around to committing it publicly. Let me see if one of the folks here can get something published. The short form is that it's an aggregator and data stripping/tagging tool for clusters of servers that allows "pipelining" of data into a single data feed with some additional features.
Thank you! This is very useful, and I see that the code base has had many features added since I last looked. This is quite useful, and is getting closer to what we have implemented ourselves.
feature added in release 4.0.0 but without any tests
There are instances where DNSTAP streams are on listener ports in our network, as part of a larger DNSTAP transport model that we have configured, and which I know is not entirely uncommon in larger DNS installations. This means that to access the stream of messages, the application (dnstap-receiver) would need to connect to an IP:socket to start the flow. We could write some sort of "shim" that created back-to-back port forwarding, but it would seem that this could be accomplished in a much cleaner way by being another method by which dnstap-receiver could connect to a stream - specification of a "host:port" pair as part of the config file or command line. This may also imply a flag to insist/not insist on TLS encryption for host:port connections.
PS: This is a really great tool - thanks for the code!