First, let me clear that this isn't a duplicate of Does deliberately wrong information from a DNS server violate standards generally accepted good practices? thread, as I'm not interested in legal aspects or
DNS standards, nor
ISP best practices. That is not my concern at this moment, and while mentioned post is somewhat relevant in terms of discussing same techniques, it doesn't provide much insight into what I'd like to ask you. Which brings me to my question:
What I would like to know is your opinion on blocking web server requests (and thus delivery of requested contents) to those clients whose forward DNS look-up table does not contain the request originating IP. Or, to put it differently, clients that fail a forward-confirmed reverse DNS check.
The way I see it, there are three different categories of clients failing forward DNS checks:
Non-existing DNS PTR. These are clients that would resolve to an IP of 0.0.0.0 with my Socks library when doing a forward DNS look-up and would include most IPv6 clients tunneling through IPv4 brokers where any intermediary IPv4 PTR would be pointless, and those IPv4 clients that have misconfigured DNS records (intentionally or otherwise). My library is capable of distinguishing one from another and I'm not looking to block out IPv6 clients sending requests through an IPv4 broker. I'm not quite sure about the latter though and would appreciate your thoughts on them.
A record pointing to AAA record, or vice versa. These are clients that have possibly intentionally misconfigured DNS records, be it for security reasons, VPN or Proxy setups, but resolve to the same ASN. For example, an IP of 22.214.171.124 has a name crawler.someserver.xxx but this name resolves with a forward DNS look-up to IP 126.96.36.199 that is named (r-DNS) someserver.xxx and both IPs are part of same ASN. While a bit costly to check against so many DNS records with each request, I'm able to cache results and also query IANA registered ASN ranges via a local and regularly updated database. Such clients are, as far as I'm concerned, acceptable but will have their requests more often looked into just in case.
Spoofed DNS records. These clients are my primary concern and the main reason for my question. They would include any IP addresses that completely fail a forward DNS check and have obviously spoofed DNS records where PTR returns an out of ASN range IP and r-DNS look-ups don't even remotely resemble one another (or wouldn't even have assigned names, which is also often the case). Honestly, I have no sympathy for these types and would like to know if you think there's any reason I should reconsider blocking them out as soon as they appear.
I'm currently running services whose policies do not include any such client testing, but have enforced certain blocks manually to a handful of such clients so far. All of these clients (that failed
FCrDNS test) are blacklisted due to other violations of my TOS as well, and I have yet to see a legitimate use of my services by any clients that do fail the
FCrDNS test and spoof their DNS records.
For example, one of such blocks I'm enforcing is on an IP 188.8.131.52 that resolves to nlnd02.xsltel.com. Forward look-up table only contains an IP of 184.108.40.206 that doesn't resolve using r-DNS. This IP of 220.127.116.11 was listed in my blacklist for
HTTP Proxy probing and is currently also listed in some other honeypots (AHBL and UCEPROTECT) but the IP 18.104.22.168 that it resolves to using
FCrDNS test isn't listed anywhere, except that some honeypots report
DNS problems, as they should. From that I gather that this client intentionally masks
DNS records to avoid detection by certain honeypots.
I guess my question is, are there any legit uses for masking
DNS records, or should I update my web-application services to automatically block any such incoming traffic (in terms of content delivery) and change TOS accordingly. Technical implementation of such testing is not a problem, nor are there any other legal concerns, at least not that I'm aware of. If you can think of any that could apply, don't hesitate to mention them, though.
These FCrDNS checks would be implemented at the web-application level. They're not supposed to be the only security measure, so think of them as an addendum to lower level checks, mostly in a bid to stop content scrappers, forum spammers, and similar network feces dead in their tracks.
Additionally, if you have any TOS examples where such filters and the reasoning behind them would be properly described, the better.
Thanks in advance for all your contributions!