Our DBA just approached me and said that it appears as though CF11 is not cooperating with reverse DNS lookups. She says that it's not Apache, and there are no errors appearing in any logs or emails - it just isn't doing any reverse DNS lookups; as if the code just isn't executed when it gets to that point.
Has anyone, here, heard of or experienced this kind of issue with CF11? I am at a total loss.
Could you provide more info. A reverse DNS lookup on a webserver doesn't involve ColdFusion at all... it should be a routing issue and handled by your network administrator.
If you are attempting to use ColdFusion to perform a reverse DNS lookup, here's some sample code on how I perform reverse look-ups on GoogleBot/Bingbot useragents to determine if they are fake or not.
This script uses InetUtil.cfc and is available for download at:
It's part of our webmetrics. We are collecting cgi.REMOTE_HOST and cgi.REMOTE_ADDR as part of webmetrics, and the Apache logs are showing that both are being collected by Apache, but somewhere in the hand-off between Apache and Tomcat, or between Tomcat and ColdFusion, the cgi.REMOTE_HOST is coming up blank.
This started happening when we upgraded both ColdFusion (to CF 11) and Apache (to 2.4.25). This was working fine under CF10.
Our SA and DBA have been looking at some of the mod files to see if anything there might be preventing REMOTE_HOST from being passed, but aren't seeing anything out of the ordinary.
I wonder if there's a better java-level variable you can access. ColdFusion attempts to collect all CGI variables and doesn't get it right sometimes. We use IIS, wanted to log CGI.LOCAL_ADDR and found it to be inconsistent and often completely random.
Please note that there may be times when an IP is unresolveable. In this case, the IP is returned. Not all hosts have properly configured hostnames and it can cause time-outs when performing look-ups.
I started performing separate reverse DNS calls afterwards (using InetUtil.cfc) to update unknown hosts that are logged.
We were always successful getting cgi.REMOTE_HOST under CF10. And, like I stated, Apache has been successfully getting REMOTE_HOST with CF11 - the Apache logs show that Apache is getting REMOTE_HOST, so these aren't situations where the IP isn't resolvable. Why CF11 suddenly is seeing occasional blanks is what has me confuzzed.
As far as better Java level variables are concerned, if anyone knows of any I'm open to suggestions; but I work for USG DoD, and they tend to restrict accessing Java anything as a security measure.
Do you have enableLookups enabled in the CF server.xml?
I think the default behaviour is as follows:
CGI.REMOTE_HOST - Hostname making the request. If the server does not have this information, it sets REMOTE_ADDR and does not set REMOTE_HOST.
Without enableLookups enabled it wont do the lookup on the host and probably sets it as empty.
I notice in IIS though that its always set to the same value as remote_addr when lookups are disabled.
Our DBA searched the CF11 server.xml for "enableLookups". IT WASN'T THERE!!! Adobe didn't just set the value to false, they completely removed it!
DBA searched server.xml on a CF10 install, and found it, and it was set to true. So she added it to the CF11 server.xml, reboot, tested, and whaddayaknow.. IT WORKS! (Thank you, haxtbh!!)
<RANT> WHY, ADOBE?!?!?!? Why???? Why would you remove enableLookups from CF11 server.xml?????? WTF is wrong with you? What is your major malfunction? I will spend the rest of my life encouraging my employer to switch to Lucee.</RANT>
What is the performance hit if "enableLookups" is enabled in the "cfusion\runtime\conf\server.xml" configuration? I'm using CF10 and noticed that it's not included in any of the <connector> nodes. (I'm guessing that the default is "disabled" if the attribute is not included.)
It is disabled by default as it has a performance impact. There has been bugs raised about this kind of stuff in the past and they will not enable it be default for this reason.
If it was in a previous configuration it would have been put there manually. rDNS lookups obvious take time and this effects the loading times. This all depends on what the request is doing though.
I recently discovered a better way to perform reverse DNS look-ups. Normally when attempting to look up a IP that doesn't have a reverse DNS name, it could take 4+ seconds for a ColdFusion response to exit/return.
I was researching a method to identify ServerMania, ColoCrossing & IPVanish-owned IP addresses (due to abuse from their networks) and discovered IP-API.com. In addition to reverse-DNS, it returns the following data:
country, countryCode, region, regionName, city, zip, lat, lon, timezone, isp, org, as, (reverse, mobile, proxy = upon request)
To retrieve all data in JSON format, use the following URL:
You'll note that there isn't any associated reverse DNS name if the "reverse" key is empty.
JSON API requests will return the following JSON response:
"as": "AS13364 Jive Software Inc.",
"city": "Palo Alto",
"country": "United States",
"isp": "Jive Software",
"org": "Jive Software",
The free API includes:
A "pro" subscription for commercial usage is only €13 per month and includes:
I work for US DoD, and unfortunately they block that URL. Don't know why, but unless it's mission critical they will not unblock it.
Hopefully, others can benefit from it.
^ _ ^
ok... They probably do that because they don't want desktop IPs to be logged by third-party websites. I use uMatrix & AdBlock extensions and this 3rd-party API is blocked too (and I prefer that it be blocked). However on the server, I need to determine the "network of origin" so I can block non-consumer fraudulent web requests. If you need a commercial API-only (non-blocked) service, you could consider using Apility. (I believe they use IP-API as the source of their data.)
As a workaround, you could try using the direct IP. (NOTE: This may change. However if use the hostname and the IP changed and you use CFHTTP, you'd have to restart CF to clear the forever-cached DNS name. We use CFX_HTTP5 to honor DNS TTL so we don't have to force a server restart.)
Here's an API request using their IP. (Hopefully DOD hasn't specifically blocked access based on IPs.)
Or you could set up your own custom HOSTNAME record on the server's "HOSTS" files. (You should be able to make up any hostname you want to use.):
... and then perform the web request using the localized hostname:
Or you could work with a third-party host (or a commercial provider like Apility) to proxy the API and return the same results.
I would expect that DoD blocks outgoing requests from web servers because, all things being equal, it's good for security to do so. Your web servers shouldn't be able to send outbound requests to random machines on the internet. I don't think using IP addresses instead of hostnames will make any difference here.
I have no idea how they have things set up, but it can be frustrating, at times. Trying to access information when I encounter an issue with code usually doesn't give me any issues, except for slack.com - blocked.
Thankfully, Adobe forums isn't blocked.
^ _ ^
Just a quick performance follow-up regarding IP-API.com, response times for an API request (+minor overhead to store results to a database) are:
38 - 229 ms (higher times are rare)
... and you can perform multiple IP look-ups in a single API request too.
DISCLAIMER: I'm using CFX_HTTP5 to perform the API requests.
When I use using CFX_EXEC (C++), CFX_HTTP5 (C++) or DNSJava (java) to perform these lookups, I would often receive time-outs. TIME-OUTS!!! And this becomes a really, serious issue when multiple hosts w/o reverse DNS names are performing requests. I wrote a "FakeBotCheck" custom tag that determines whether requests using GoogleBot, Bing, Yahoo, ShopWiki, Baidu ScanAlert or Applebot user agents are coming from IPs that have valid reverse IP names.
I'm now in the process of identifying all our scripts & libraries that use DNS look-ups and am switching them to use the API (w/local cached data) instead.
I written a global function that identifies all contact form-type posts and saves them to a global database in a JSON packet. We're building an admin tool to display these (blocked & valid) messages to our website clients and are mapping the IPs using the lat/lon values from the API. We started logging out of frustration because we've encountered multiple issues where CFMail occasionally doesn't deliver a message... in fact, it wouldn't be logged by CF or logged in our SMTP server. Even when sent via SMTP, there are times that the client's email server will reject or mark it as spam due to content. So our internal logging w/IP data is going to be a huge benefit to us (in terms of blocking) and to our clients (in terms of determining where their customers are.)