As I've alluded to previously, the use of DNS 'black holes' or 'sink holes' is a pretty common use case for DNS policy as far as I can tell, it's second only to support requests for Split Brain configurations. Also, for those wondering, yes, in the build process, I did enable the DNS Analytical log - I'd have a hard time writing the rest of this blog if I didn't.
In my scenario though, I have one domai n p er QRP (you aren’t limited to that, that’s just what I did), and t hose domains include ones that host ads, collect telemetry / tracking data, malware, and other unwanted domains. A topic that I may or may not discuss in the future. That limit is 500K, however you can have more than 500K policies, and they will still work, but o nce you hit that threshold, you’ll need some custom code (fear not, I've already written it and can share to those that are interested) to get past that limit for collecting information about those policies (though Get- DNSServerQueryResolutionPolicy still works fine i f you’re querying for a specific policy ). Note: An important side note for those that have a similar configuration to mine – there is a hard limit of how many policies you can ‘Get ’, using Get- DNSServerQueryResolutionPolicy.
At the time of this writing the server ha s over 5 5 0 K Query Resolution Policies to deny query attempts to domains listed within thos e Q RPs.
This was implemented on a non-domain joined physical server using Windows Server 2019. I did this using PowerShell, DNS policy, and some block lists from GitHub. Time is money!įor this scenario, I've developed a customized Windows based version of the popular Pi-Hole, just without the pretty GUI. In order to do this, I'll share some examples of how you can parse the DNS Analytical Log to find possible items of interest, since just scrolling through literally, what can be millions of lines of events, just doesn't sound like a fun time to me Nor is it really feasible. In this edition and in some future editions of the series, I'll be focusing on collecting data from the DNS Analytical Log, based on ce rtain use cases and presenting it in a more concise and useful manner. Now, I ga ve you gu ys a b re ak in Part 2 of the series an d kept that one s hor t, but br eak time is over, team I'm going back to a bit of a m ore in-depth discussion today, so buckle up and ge t comfortab le. Hi Team, it's Eric Jansen again, and as al ways, I'm excited to show you guys what I ha ve in store for y ou.
0 kommentar(er)
