Support

First of all, you are misunderstanding how Project Honeypot works. Please look at https://www.projecthoneypot.org/httpbl_api.php As you can see there is a DNS lookup request made in the form of yoursecretkey.4.3.2.1.dnsbl.httpbl.org where 1.2.3.4 is the IP address of the visitor (with the octets written in the reverse order) and yoursecretkey is your HTTP:BL secret key. Project Honeypot's DNS server API replies with an IP which is NOT a valid IP address and must NOT be treated as such.

Incidentally, using dig to find out the IP address of the DNS server being queried never comes back with the IP address you mention – at least not from where I am now. Since this seems to be a networking issue between your server and Project Honeypot I suggest that you talk with them. All we can do on our end is verify that our code uses their API based on the information they publish (see the link above). I did that just now and I can tell you with absolute confidence that we do follow their API to the letter. A few examples I ran also verify that the data we are receiving is valid and parsed correctly. So, all that's left is you contacting Project Honeypot I'm afraid :(

Our next step will definitely be to work with Honeypot but hey, wouldn't you want to be aware of issues with one of the products you've built into yours?

I'm pretty sure that Project Honeypot doesn't have issues. I don't want to sound arrogant saying this. I am basing it on observation. Our site uses this feature with a minimum delay (in the order of 5 msec). Thousands of our users also use it on tens of thousands of servers without a problem. That's why I'm inclined to say that this is a server issue.

This definitely appears to be a problem with the project honeypot ISP or at least last hop(s).

I'm telling you that I'm also querying the same servers and have no such results. For example, let's check the following dig command I issued on my computer for a suspicious IP address:

09:13 $ time dig MYKEYHERE.18.169.57.45.dnsbl.httpbl.org

; <<>> DiG 9.8.3-P1 <<>> MYKEYHERE.18.169.57.45.dnsbl.httpbl.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42965
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
; MYKEYHERE.18.169.57.45.dnsbl.httpbl.org. IN A

;; ANSWER SECTION:
MYKEYHERE.18.169.57.45.dnsbl.httpbl.org. 300	IN A 127.1.31.5

;; Query time: 223 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Oct 27 09:14:57 2015
;; MSG SIZE  rcvd: 76


real	0m0.245s
user	0m0.005s
sys	0m0.015s

If you want me to run a trace:

09:14 $ dig MYKEYHERE.18.169.57.45.dnsbl.httpbl.org +trace

; <<>> DiG 9.8.3-P1 <<>> owcotclsshuk.18.169.57.45.dnsbl.httpbl.org +trace
;; global options: +cmd
.			482948	IN	NS	a.root-servers.net.
.			482948	IN	NS	m.root-servers.net.
.			482948	IN	NS	c.root-servers.net.
.			482948	IN	NS	g.root-servers.net.
.			482948	IN	NS	i.root-servers.net.
.			482948	IN	NS	h.root-servers.net.
.			482948	IN	NS	j.root-servers.net.
.			482948	IN	NS	d.root-servers.net.
.			482948	IN	NS	b.root-servers.net.
.			482948	IN	NS	l.root-servers.net.
.			482948	IN	NS	e.root-servers.net.
.			482948	IN	NS	k.root-servers.net.
.			482948	IN	NS	f.root-servers.net.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 45 ms

org.			172800	IN	NS	a0.org.afilias-nst.info.
org.			172800	IN	NS	a2.org.afilias-nst.info.
org.			172800	IN	NS	b0.org.afilias-nst.org.
org.			172800	IN	NS	b2.org.afilias-nst.org.
org.			172800	IN	NS	c0.org.afilias-nst.info.
org.			172800	IN	NS	d0.org.afilias-nst.org.
;; Received 462 bytes from 198.41.0.4#53(198.41.0.4) in 67 ms

httpbl.org.		86400	IN	NS	amy.ns.cloudflare.com.
httpbl.org.		86400	IN	NS	lee.ns.cloudflare.com.
;; Received 113 bytes from 199.19.57.1#53(199.19.57.1) in 233 ms

dnsbl.httpbl.org.	300	IN	NS	ns3.httpbl.org.
dnsbl.httpbl.org.	300	IN	NS	ns1.httpbl.org.
dnsbl.httpbl.org.	300	IN	NS	ns2.httpbl.org.
;; Received 162 bytes from 173.245.58.101#53(173.245.58.101) in 62 ms

MYKEYHERE.18.169.57.45.dnsbl.httpbl.org. 21600 IN A 127.1.31.5
;; Received 76 bytes from 81.17.242.92#53(81.17.242.92) in 74 ms

I don't see any issues.

Please note that if you do a traceroute on httpbl.org OF COURSE you are going to get timeout errors. If you observe the dig results closer you'll see that the nameserver is sitting behind the CloudFlare CDN for performance and attack mitigation reasons. In other words, ICMP ping will fail as soon as you try hitting the CloudFlare edge node. In my case this happens as soon as the packet are about to exit Level3's Detroit network.

So, to put the final nail to this issue with your server and nothing but YOUR server: everyone else says and proves it works. It only does not work for YOUR server. We are not your host and we are not paid to do systems administration. Unfortunately the only thing we can do for you is what I did above: prove that the problem lies outside our software and definitely not in the service we are using, a service that works for everybody else except you. Think about it. If you are the only one having problems while thousands other people don't what are the chances that you found a global problem? Zero. Nada. Zilch. For this reason I'll have to close this ticket now.