<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 13 Apr 2018, at 22:27, Robert Edmonds <<a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a>> wrote:<br> The component doesn't even need to be on the same machine as the DNS server if you're using the 'next' branch of fstrm, which has TCP support, though BIND would probably need to be updated to allow configuring an fstrm TCP writer.</div><div><br></div><div>Sweet, I should have a look at that!</div><div><br></div><blockquote type="cite"><div><span></span><span></span><span>This is definitely one of the use cases I had in mind as something that </span><span>dnstap could support, with the right glue utilities, but nowadays I </span><span>wonder if the "keeping a standby cache hot" use case wouldn't best be </span><span>served by existing functionality in dnsdist, if you're using dnsdist to </span><span>front your recursive servers?</span><br></div></blockquote><div><br></div><div>We aren’t - dnsdist is undeniably cool, but I am a bit reluctant to have two layers of health checks / failover when one layer does the job, and we don’t have the amount of traffic or level of abuse that would make it compelling. I quite like being able to implement an optional extra like this off the critical path, so any breakage is decoupled from the main job of serving queries.</div><br><blockquote type="cite"><div><span></span><span>The only advice I can offer would be to watch out for Protocol Buffers </span><span>v2 versus Protocol Buffers v3 compatibility issues. dnstap was designed </span><span>using the Protocol Buffers v2 language, and v3 removes some v2 </span><span>functionality that the dnstap schema uses.</span><br></div></blockquote><div><br></div><div>I think the more interesting Lua implementations are plugins to protoc, which I hope means they will work OK!</div><br><blockquote type="cite"><div><span>One of the cool things about Frame Streams is that it's strongly layered </span><span>to the point that it doesn't care what is actually in the payloads that </span><span>it transports (other than carrying a "content type" for the user to </span><span>describe the type of payloads carried in the stream), so if you don't </span><span>actually need to edit or consume the dnstap protobuf payloads, you could </span><span>certainly write a fanout utility in Lua without needing a protobuf </span><span>dependency at all. Though for replaying, you would certainly need to </span><font color="#000000"><span style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);">deserialize </span></font>each payload to extract the query messages.</div></blockquote><br><div>Oh, right, I was vaguely aware of this layering but I thought the client/resolver/etc. query/response tag was in the protobuf blob rather than the fstrm metadata (it’s described in the dnstap.proto file) which would imply even a simple dnstap filter needs to know about protobuf...</div><div><br></div><div>Thanks for the tips about code to look at!</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span><div><span style="background-color: rgba(255, 255, 255, 0);">Tony.</span><div><span style="background-color: rgba(255, 255, 255, 0);">-- </span></div><div><span style="background-color: rgba(255, 255, 255, 0);">f.anthony.n.finch <<a href="mailto:dot@dotat.at">dot@dotat.at</a>> <a href="http://dotat.at">http://dotat.at</a></span></div><div><br></div></div></div><br></body></html>