We dont run rpz on the resolver nodes, hopefully when we clear the backlog of things we want to fix/tweak/finish we can get around to dropping some docs on the cool stuff we built/did, and why. #todolist
I hope you succeed. Filtering out bad actors via DNS is a good idea, you will have to be very careful about false positives, though. ;-)
I think a similar approach is already being used for mail servers to detect spam... but I am short on details, because the only mail server I have ever taken care of is the Exchange server at work, and Exchange is not all that proactive when it comes to spam.
DNSBLs [0] are very popular. Pretty much anyone running a mail server that accepts connectiona from the public Internet use them -- you have to! I manage several mail servers and I use many different DNSBLs, including one of my own.
The best anti-spam advice I could give WRT your Exchange box (I've managed those too) is to put another box in front of it to handle the spam filtering (Postfix + SpamAssassin + friends in my case, but you have many options), though IIRC even Exchange can directly use these blacklists nowadays.
This is a byproduct of edns not being transmitted on 9.9.9.9 resolutions for privacy reasons. 9.9.9.10 will transmit edns, but has no blocking. Soon we will release another ip that will have blocking+edns transmission on it, as well as documentation outlining all this and the differences. We just ran out of time for all that and focused on 9.9.9.9. Sorry for any inconvenience on your end. (Also sorry if my response latency is high, im a big fan of this community so im focusing my attention here as best i can)
Thank you for responding. I think four different DNS IPs on your side could be a little overkill for the standard user in terms of choosing the 'right' one. Apart from that, good luck with the product!
Totally understand, we are trying to find the right balance for those that need options. We can always shift how we present things, configurations, technologies implemented etc based on end users feedback. We really do want folks to help us make this system better.
So a quick explanation of what we do. (Its on the website as well, sorry if my response latency is high)
We do for a short period of time have the ip address in memory, it is very quickly used to do a geo location look up, that data (the geo location data) then essentially replaces the src ip in the data structure that is used in our logs and telemetry. We can of course as outlined in that page during times of ddos or troubleshooting enable a higher level set (thing router/infrastructure) set of logging that could provide that data to the infrastructure operator (pch). When that occurs that data is not mixed with the “daily operational data” that is generated by the normal functioning of the system. This is/was the best balance we could come up with to maintain privacy and ability to mitigate/resolve technical issues with infrastructure and the operation of what we do with telemetry around blocks in the system.
So quick recap, even when things go sideways and we need to mitigate a ddos or trouble shoot weird routing/anycast/other issues and enable the capture of ip/asn’s that data is generated/processed/used seleratley than the telemtry data we store, generate, and share. (On the sharing side we only share telemetery with the to vendors who gave us data to produce those blocks, so its segmented as well).
And i think thats perfectly normal. People basically demanding free public services and the operator of that service can't log anything.. thats what i have problems with :)
Hey guys sorry for lag in response, a bit slammed right now on our side.
9.9.9.10 does not have blocking, it also has edns enabled (so assume less privacy than 9.9.9.9 given edns will be transmitted on 9.9.9.10)
We will make sure to push out some documentation on the different services on each ip. The launch we focused on 9.9.9.9. There will be a blocking +edns ip soon we just dodnt get it done in time. :(
