DNS weirdness from www.ads-software.com?

I was trying to figure out why Akismet, RSS feed from www.ads-software.com on my dashboard, updates, and other things stopped working

That will almost certainly be a server issue – commonly caused by a failure to implement cUrl in PHP on the server.

That’s what I thought, too, but I haven’t changed anything, and it was working great until yesterday. Still investigating…

Just checked and all of those dashboard feeds are working fine for me on my development server.

Curl is implemented … again haven’t changed anything.

cURL support 	enabled
cURL Information 	7.15.5
Age 	2
Features
AsynchDNS 	No
Debug 	No
GSS-Negotiate 	Yes
IDN 	Yes
IPv6 	Yes
Largefile 	Yes
NTLM 	Yes
SPNEGO 	No
SSL 	Yes
SSPI 	No
krb4 	No
libz 	Yes
CharConv 	No
Protocols 	tftp, ftp, telnet, dict, ldap, http, file, https, ftps
Host 	x86_64-redhat-linux-gnu
SSL Version 	OpenSSL/0.9.8b
ZLib Version 	1.2.3

I did notice this … if I try and fetch the feed manually from the command line:

$ wget https://www.ads-software.com/development/feed/

It eventually works, but takes forever. Hangs for quite some time on trying to resolve www.ads-software.com. Still kinda coming back to a DNS issue in my mind. Although if I dig or nslookup www.ads-software.com, it resolves very quickly lol.

Could it be a local DNS issue at your ISP’s end?

Possibly, but if I ping, dig, or nslookup, it resolves super fast. wget hangs a while, and it uses curl, I believe …

Other than a purely local issue, I have no idea why this is happening only on your site.

Yeah, it’s definitely something local to the environment, or possibly upstream at my provider (it’s a dedicated server in a colo). Making me crazy though lol, as I’ve had to temporarily disable comments due to the flood of spam that Akismet isn’t able to pick up now.

Akismet status shows all servers green, but I get the dreaded “can’t connect to Akismet” message. Which is probably due to a timeout in cURL, I would imagine.

If it’s local DNS, it should resolve all by itself in a few hours – assuming the DNS servers update correctly this time, yes?

Okay, I think I’ve found something here. If I use the -4 command line switch to cURL, it works lightning fast. So this means it is trying to resolve it first as an IPv6 address, then falls back. And in looking at my phpinfo() output, it seems that the cURL extension is configured to look for IPv6 as well. Need to figure out how to do that without having to build the cURL extension manually (since I use yum).

I know we’re all down to the last few thousand IPv4 blocks but has someone been jumping the gun making IPv6 the default for cURL? I couldn’t claim to be anything near an expert but surely it make sense to keep IPv4 the default with a fallback to IPv6 for the next couple of years at least? Weird…

If I spot one of the more server-orientated forum regulars around, I’ll try to flag them down and point them in this direction.

I’m running PHP v5.3.3, so I’m pretty sure I could go in and edit class-http.php and functions.php, and anything else that calls curl_setopt() and add in the CURL_IPRESOLVE_V4 option, but I’d rather not hack core lol.

I’m running PHP 5.3.3 myself but I’m not having the same problems.

I installed Dion Hulse’s most excellent core control plugin, and disabled cURL as a valid transport, and things are good. But still … lol.