From stephen.vickers at telemity.com  Mon May 25 14:16:48 2026
From: stephen.vickers at telemity.com (Stephen Vickers)
Date: Mon, 25 May 2026 14:16:48 +0000
Subject: [dnstap] Windows DNS ETW to dnstap interoperability
Message-ID: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>

Hi all,
I?ve been working on a Windows DNS telemetry collector called DnsStream which captures DNS telemetry directly from the native Windows DNS server ETW provider and now emits standards-compatible dnstap over TCP/TLS using fstrm.
One of the motivations was enabling Windows DNS infrastructure to participate in existing dnstap-compatible pipelines and tooling without relying on packet capture or Windows DNS debug logging.
The implementation currently maps Windows ETW query/response events into generated CLIENT_QUERY and CLIENT_RESPONSE dnstap messages while preserving the original DNS packet bytes from ETW.
I noticed Windows does not currently appear in the ecosystem/platform listings around dnstap and was interested in whether this kind of interoperability work would be considered useful/relevant to the wider dnstap ecosystem.
Would also be very interested in any feedback around interoperability expectations, field semantics, or implementation details that people think are important for ecosystem compatibility.
Thanks
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20260525/f5cfd87a/attachment.htm>

From m3047 at m3047.net  Mon May 25 20:01:58 2026
From: m3047 at m3047.net (Fred Morris)
Date: Mon, 25 May 2026 13:01:58 -0700 (PDT)
Subject: [dnstap] Windows DNS ETW to dnstap interoperability
In-Reply-To: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>
References: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>
Message-ID: <alpine.LSU.2.21.2605251247150.12318@flame.m3047>

I'd love to know more! "I don't do windows", and what I personally use is 
BIND, and it only writes to a file or a unix socket. That's a problem for 
containerization, especially microkernels which only run one image. I've 
wished since the beginning that it supported TCP. I don't view this as a 
replacement, what I'm interested in is who / what are the consumers for 
this (already built to consume fstrm over TLS)? I am familiar with SIE. 
;-)

I don't know why you put fstrm in front of it. I seem to extract what I 
need and then send that as multicast datagrams (JSONified in what I give 
away publicly).

Feel free to contact me offlist (I'll give you a Trualias) or to hunt me 
down on LinkedIn.

--

Fred Morris, internet plumber

On Mon, 25 May 2026, Stephen Vickers via dnstap wrote:
> 
> Hi all,
> I?ve been working on a Windows DNS telemetry collector called DnsStream which captures DNS telemetry directly from the native
> Windows DNS server ETW provider and now emits standards-compatible dnstap over TCP/TLS using fstrm.
> [...]


From paul at redbarn.org  Tue May 26 06:23:41 2026
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 26 May 2026 08:23:41 +0200
Subject: [dnstap] Windows DNS ETW to dnstap interoperability
In-Reply-To: <alpine.LSU.2.21.2605251247150.12318@flame.m3047>
References: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>
 <alpine.LSU.2.21.2605251247150.12318@flame.m3047>
Message-ID: <70979567-14c2-465d-b628-0575b728af49@redbarn.org>

Fstrm is vital for reliable transports like tcp. It is how dnstap prevents blocking on the transmit side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20260526/83f2eb9d/attachment.htm>

From stephen.vickers at telemity.com  Wed May 27 13:12:40 2026
From: stephen.vickers at telemity.com (Stephen Vickers)
Date: Wed, 27 May 2026 13:12:40 +0000
Subject: [dnstap] Windows DNS ETW to dnstap interoperability
In-Reply-To: <alpine.LSU.2.21.2605251247150.12318@flame.m3047>
References: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>
 <alpine.LSU.2.21.2605251247150.12318@flame.m3047>
Message-ID: <PR3PR09MB429948ED3FE35885A435215D88082@PR3PR09MB4299.eurprd09.prod.outlook.com>

Initially, DnsStream forwarded DNS data as ISC BIND style querylog style messages over Syslog (with a similar response format created - https://telemity.com/dnsstream/docs/administration/event-and-output-formats.html#client-response-event) or new-line delimited JSON.  The aim is high-fidelity data and operational safety - no detection, no analytics, etc., just accessing and moving the data without demanding huge amounts of CPU, memory or any disk IO.

The next component in the suite of tools is going to process dnstap data over TCP/TLS (at least that's the plan) which is why I added dnstap - it was remarkably easy to add dnstap over fstrm.  This allows for receiving data to all the DNS servers which support dnstap, and for Windows DNS, DnsStream covers that off.

I've experienced the BIND UNIX file only dnstap issue myself, used socat to get it to a TCP destination. ?  I am looking to implement Linux support with UNIX file based dnstap in a very near release for this exact reason, not sure if you would be interested in taking a look at this when it's available?

So, the main consumer of this dnstap implementation was the next tool, which I don't want to talk about here, yet (things change and it may never materialize ?), and the side-effect of this allows data from Windows DNS servers to feed directly into an existing dnstap based system.

Many thanks
Steve

________________________________
From: Fred Morris <m3047 at m3047.net>
Sent: Monday, May 25, 2026 21:01
To: Stephen Vickers <stephen.vickers at telemity.com>
Cc: dnstap at lists.redbarn.org <dnstap at lists.redbarn.org>
Subject: Re: [dnstap] Windows DNS ETW to dnstap interoperability

I'd love to know more! "I don't do windows", and what I personally use is
BIND, and it only writes to a file or a unix socket. That's a problem for
containerization, especially microkernels which only run one image. I've
wished since the beginning that it supported TCP. I don't view this as a
replacement, what I'm interested in is who / what are the consumers for
this (already built to consume fstrm over TLS)? I am familiar with SIE.
;-)

I don't know why you put fstrm in front of it. I seem to extract what I
need and then send that as multicast datagrams (JSONified in what I give
away publicly).

Feel free to contact me offlist (I'll give you a Trualias) or to hunt me
down on LinkedIn.

--

Fred Morris, internet plumber

On Mon, 25 May 2026, Stephen Vickers via dnstap wrote:
>
> Hi all,
> I?ve been working on a Windows DNS telemetry collector called DnsStream which captures DNS telemetry directly from the native
> Windows DNS server ETW provider and now emits standards-compatible dnstap over TCP/TLS using fstrm.
> [...]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/dnstap/attachments/20260527/eb5abb79/attachment.htm>

From jerry at dns-oarc.net  Thu May 28 13:19:29 2026
From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=C3=B6m?=)
Date: Thu, 28 May 2026 13:19:29 +0000
Subject: [dnstap] Windows DNS ETW to dnstap interoperability
In-Reply-To: <PR3PR09MB429948ED3FE35885A435215D88082@PR3PR09MB4299.eurprd09.prod.outlook.com>
References: <PR3PR09MB429952BA6364D653040FD845880A2@PR3PR09MB4299.eurprd09.prod.outlook.com>
 <alpine.LSU.2.21.2605251247150.12318@flame.m3047>
 <PR3PR09MB429948ED3FE35885A435215D88082@PR3PR09MB4299.eurprd09.prod.outlook.com>
Message-ID: <642a4d47-03ab-4b8c-b420-8c3d0d56fae5@dns-oarc.net>

Hi,

On 5/27/26 13:12, Stephen Vickers via dnstap wrote:
> 
> I've experienced the BIND UNIX file only dnstap issue myself, used socat to get it to a TCP destination. 
> 
> ________________________________
> From: Fred Morris <m3047 at m3047.net>
> 
> I've wished since the beginning that it supported TCP.
libfstrm has TCP support [1] (always did probably), it's might just be that BIND does not implement it.

Cheers,
Jerry

[1] https://github.com/farsightsec/fstrm/blob/master/fstrm/tcp_writer.c

