Raart
commented
2 years ago By looking at reverse with more attention, it appears to me that a selection has to be made by band as far as a proper algorithm has to be found. Some IPaddr. have no reverse resolution so they would remain out of blocking by pDNSf if its sole function stuks at domain name lists. In my opinion the real scope of this nice and handy tool is to stop all that mess generated mainly by commercial entities and derivates. So, as they counter our tries to stop them by using IPaddresses we should add IPaddresses lists to our tool (even if this is not directly related to the DNS approach of Ingo's tool). Therefore I think, the decision to implement something new in pDNSf being a strategy change in his product is up to Ingo himself as owner and ideator. Otherwise as is used here on github and with open source projects, I'd ask him permission to work on a fork of his repo and go further following a different way with no interest on money, and to make something more complete for the pleasure of who wants to navigate excluding ADV, and all what is connected to this, in the meanwhile becamed, excessive time, money and privacy consuming activities on our behalf (without asking us if we are accepting all this).
IngoZenz
Hi Ingo, contributors, during the last two years I had time to investigate on new strategies adopted by companies to supersede countermisures like pDNSf is. New trend is direct IP number addressing for accessing hidden data gathering services. Our next move should be, I'm confident on this, to reject traffic to/from this servers. It is not a simple task, as many servers are simply behind a NAT and a firewall. Therefore we can start by creating some sort of lists containig names:ports obtained by capturing outbound packets and requesting reverseDNS resolved data by presenting IPAddresses. So lists of verified to be blocked IPaddresses have to be supported either. This while studying further strategies observing what exactly is in progress. My 10 cents.