incrediBILL - 7:41 am on Jan 22, 2013 (gmt 0)
Problem with running rDNS requests against the IPs that do not have them is that the time to look up is USUALLY 4-5 seconds
That's not a problem if you cache the rDNS lookups for 24 hours like I do which means only the first hit from that IP causes a delay. If you run into any problem IP ranges that cause incredibly long delays you can drop them in a list to skip. Been doing this for years and survived many a DDOS so far.
Also, using the "one page free" theory you do the rDNS lookup post page processing so it doesn't hold up the page from being displayed and when you do get an answer you block subsequent page requests. Not a 100% solution, but it mixes the best of all solutions.
Additionally, you can set up an rDNS daemon that processes them in a dedicated multi-threaded process which takes up very little memory unlike a bunch of large scripts handing around. Subsequent page requests can query the daemon for results.
With good engineering practices you can always find suitable solutions ;)
hidden from view using a variety of CSS tricks.
Sites have natural honeypot pages such as legal.html, policy.html, terms.html. etc. which humans rarely ever look at but bots blindly crawl. Links like "dontcrawl.html" hidden with CSS are just gravy and confirmation it's not human. As a matter of fact, whether they honor it or not, a lot of bad bots access robots.txt which is another honeypot I use.
Visitors from Nebraska, The Dakota's Oklahoma, Colorado, Las Vegas, Oregon, Washington, in fact for me most everything west of the Mississippi. These folks are simply without interests in widgets.
Except the danger there is blocking travelers or people using services with IP pools that could be forward traffic from literally anywhere.
I use Comcast which is pretty static, even rebooting the modem doesn't tend to change the IP but when they do change the IP tends to remain from the same general region although sites like MaxMind and others can't seem to keep up. However, my mobile provider often uses landline IP addresses over 600 miles away! I could be in No. CA, AZ or NV and still be using an IP pool from Los Angeles.
My point is never assume where your customer is based solely on IP except within a country itself because it could literally be from anywhere these days, especially with large IP pools. Even country IP blocking isn't foolproof as IP blocks on border states could be in either country. Takes a lot of extra data to check for all those edge cases, beyond the score of simple blocking.
Anyway, country filtering is still close enough for me as long as you except some collateral damage will happen.