Windows DNS server query and response logging
Posted by vortexisat@reddit | sysadmin | View on Reddit | 12 comments
I’m looking logging DNS queries and responses being processed be Windows DNS servers. It looks like there a three main options. Firstly debug logging, second packet capture and third DNS analytic logging using Event Tracing for Windows (ETW). AD team won’t allow debug logging on permanently as they had issues with disk I/O performance in the past and they won’t allow drivers like npcap for packet capture to be installed. ETW option looks good but it would see you need to parse dns messages yourself. Looking for what others have done and any gotchas/experience. Thanks
ballkali@reddit
ETW is the way to go given your constraints. One gotcha nobody mentions until they hit it: the DNS analytical log channel has a default max, size of 4MB which sounds insane but it's true, you'll lose events constantly until you bump that up. Run wevtutil sl Microsoft-Windows-DNSServer/Analytical /ms:524288000 to set it to 500MB or whatever fits your retention needs.
xxdcmast@reddit
I’ve run dns debug logging at pretty much every company I’ve been at over 20 years. From old spinning hard drives, to modern virtualization. I have never seen dns debug logging cause I/O problems on a system.
vortexisat@reddit (OP)
Yep, I get that :( Problem I have is once it’s a standard it’s a standard, I have no hope in changing it. I have looked at the debug log and it does look a little difficult to work with. I imagine it’s a solved problem parsing that file though. There was mention of rather large memory usage related issues when using Beats to tail files, even for a modest 1k DNS QPS. I see it’s written in Go (or looks to be) so imagine garbage collection could explain that. Thanks
wastewater-IT@reddit
We use ETW into elastic stack; it's super noisy and may take quite a bit of space to store long-term, but so far we haven't seen a major impact to performance on the DCs.
vortexisat@reddit (OP)
Are you doing anything with the PacketData field, such as parse it to get answer DNS records?
wastewater-IT@reddit
We're letting the Elastic-provided integration do that work, it even comes with a nice dashboard where you can view the top question names, event types, etc. We can view the question name, response code, etc. https://www.elastic.co/docs/reference/integrations/microsoft_dnsserver.
vortexisat@reddit (OP)
Ah okay, it looks like it doesn’t actually parse the PacketData field and just includes it. It mean you don’t get access to answer records for dns responses. Also, those events look massive :(
Existing-Seaweed-178@reddit
Be carefull, if disk I/O is an issue, when you enable DNS Analytic events as per the Elastic docs, then you are going to be sending all DNS queries and responses to an event log on disk basically - this is what the Beats agent will be tailing essentially. It doesn't use a real-time ETW consumer which wouldn't use any disk I/O and would be completely memory bound. I am not aware of anything that consumes the ETW DNS analytic events in real-time, i.e. operating only out of memory without writing anything to disk, and parses the PacketData field of these events before forwarding to a SIEM/log system. You'd have to put together a pipeline of sorts to do this.
pdp10@reddit
Everyone converts Microsoft ETL files to PCAP format and then uses an open-ecosystem tool. We once used to preinstall PCAP drivers on Windows so they'd be pre-emplaced with no reboot.
Another option is a flow-exporter (protocols: IPFIX, sFlow, Cisco NetFlow) from an adjacent network box to a flow logger, e.g.
pmacct.For ad hoc discovery and validation, e.g. before decomming a DNS server, just a mirror/span port to an adjacent box running
tcpdumpor Wireshark.iamMRmiagi@reddit
For capturing and forwarding logs, use NXLog CE with DNS module. This formats it for syslog to your SIEM.
This does require debug logging, but maybe you can convince your AD team by customizing the debug options to reduce IO load and amount of details logged.
We have our DC's are spec'ed as D2as in Azure, with 'standard' ssds and a temp drive - you could just redirect the log to that storage which would reduce the IO load on system drive. As long as you forward the logs off host, having these on a temp disk should be fine...
Alternately, you could restrict at the firewall to only approved DNS servers, and use those events instead. It's not the same I know, but it's an option!
Our EDR tool captures DNS queries on endpoints and servers, so we have up to 3 DNS events in the SIEM for each query
- one for the query on the client.
- one for the server lookup on the DCs
- one for the firewall inspecting DNS traffic on the way out (I've actually disabled this now, and only non-sanctioned DNS traffic is logged)
Calm_House8714@reddit
What queries are you trying to track?
If you're logging queries from end user devices then log on endpoints instead? Most EDRs log DNS queries, pump that to your SIEM.
You could also log in your firewall and pump to siem if it's outgoing queiries you're looking for...
Our Falcon instance is set up to log dns requests on the DNS server as well.
Witty-Culture-5978@reddit
Security onion on a span port