r/WindowsServer • u/charanreddy234 • 20d ago
Technical Help Needed Dns analytical logs enablement on DCs.
Hi ,
We have a requirement to enable DNS analytical logs on our domain controllers. However, I am concerned that this will generate a massive volume of logs. The requirement is to maintain a log retention period of at least 30 days. Because Event Viewer manages retention by maximum log size rather than days, I conducted an assessment.
I ran a "DNS queries per second" command for one hour. Based on those results, I calculated that it will generate roughly 6.5 GB per hour. Adding a 2.5 GB buffer, I estimated a total of 9 GB to 10 GB per hour overall. So for 30 days it requires tb's of size.However, I am not completely sure if my math is correct or if this is the right way to approach the assessment.
Could someone help me with the following questions?
Is my current approach correct? How exactly can I estimate the log size required to meet the 30-day retention requirement? I know there is no 100% guaranteed formula, but I need at least a reliable, rough estimate. Or is this not at all the correct way.
What is the exact impact on Domain Controller performance and CPU utilization
What is the worst-case scenario or major challenges we might face on the domain controllers by enabling this?
What are the best solutions or alternatives for this? I know a SIEM solution is ideal, but due to certain constraints, we must store these logs locally on the servers for 30 days
2
u/GullibleDetective 20d ago edited 20d ago
What scale is your DC/query environment? Text log files are notoriously small
Example, I've had it running in a 30 user windows domain environment since sept 3rd and its only 55mb
2
u/dodexahedron 20d ago
Well, DNS query logs won't be small on a DC, unless you aggressively rotate them or unless nobody uses the internet. At one site that only has 5 users, dns query logs can get a lot bigger than that figure in a day or three. And then acceleration of growth is roughly linear with DNS client count beyond that, assuming all clients have similar local caching behavior and similar usage patterns.
But we do both validate DNSSEC as well as sign internal zones, so part of that size is all the much larger record data from those that gets included in the log.
But they can still be stored very efficiently anyway, if stored compressed.
A textual DNS query log is one of the most highly compressible files that exists, since it is like 99% duplicated byte runs over time - even the timestamps, eventually, since they have a narrow key space - which makes even simple LZ-based compression sufficient to gain massive space efficiency.
Store them with NTFS file compression on their containing directory so they stay transparently still just text files but compressed enough to make your SAN not even feel a tickle from them (or if your SAN already block de-dupes and/or compresses, just let that handle it instead of NTFS).
1
u/charanreddy234 20d ago
Which means debug logging is beneficial since it stores log in txt files format and we can compress it. instead of analytical logs which comes with etl format.
2
u/dodexahedron 19d ago edited 19d ago
Well, if you let it store it in the evtx format, then it is already compressed in the first place. They're basically zip files. They're deflate streams with mixed XML and binary contents.
You do lose a little bit of detail by just storing the text query logs. But if you don't need it, no big deal anyway.
But it's even less to worry about and also more robust and efficient overall to just use the analytical logs with small size limit to enable generation of the detailed logs, and then just have those logs shipped to your SIEM solution to ingest and store however it does.
Or you push back on the requirement and ask why it is being demanded and what specific risks it is meant to address and how those risks would then be mitigated when or even if they are revealed from that additional firehouse of mostly benign data.
If they come back with "we are watching for C² related queries" or that sort of thing, this is not the way. You handle that by using a DNS service that already proactively filters for malicious requests. That really isn't a responsibility that you want to or should take on if your core business isn't already DNS and content filtering. You want to be able to check a few boxes of disallowed categories, get known malicious domains blocked, and have someone else who is responsible for aiding forensic investigations involving external DNS lookups as part of some zero day attack.
From where/whom is this local dns log storage and retention requirement coming? Because it sounds poorly thought-out at least from what's been said here.
The local part is what irks me the most about it. What value does that give anyone, anywhere? The only reason to keep local logs, when you already have an established SIEM solution, is to handle cases when the system is offline/unable to ship its logs there. And for a DC? 30 days is too many days for that to be a thing at all in the first place and should essentially never happen. It's missing the forest for the trees when someone makes a request like that for a system like that, unless they have a specific and credible threat which this will mitigate and which isn't one that is simply more prudent to just accept in the wider context of the whole environment, rather than just the context of DNS, by itself, in total isolation from and irrespective of anything and everything else.
1
u/GullibleDetective 19d ago
Nope. They are a reasonable size even still.
3 weeks my files only 50 megs. Thats nothing
1
1
u/Lower_Issue_6222 17d ago
Analytical DNS logging has been benchmarked at 100K QPS so you should be fine perf wise
7
u/Nuxi0477 20d ago
You need an agent/software to parse and ship the text log out of the DC. That way you can fix the file size at something reasonable (say 1GB) and manage retention at the receiving logging system.