Adventures in IPv6 Land: NuSOAP,CURL, and Nameservers on a VPS host.

As part of one of our data integration projects, we were asked to process some web form data through a third party webservice. The web form was built in PHP, and our standard PHP webservice library has always been to use NuSOAP tool kit (http://sourceforge.net/projects/nusoap/). It has always been easier to deal with and integrate and diverse hosting platforms, that is, up until this past project.

As usual, we developed the webservice integration application (a class object) on one of our virtualized test servers which closely mimics the customer’s hosting environment. We delivered the code and started integration and started running into some very interesting issues.

The target webservice server was hosted on an SSL environment, so we needed to ensure that OpenSSH was installed and CURL was functioning properly.

The problem was that initial call to the webservice worked great, but subsequent calls to the target would fail. Basically, it could find the target server the first time, but could not find it on a secondary call. This even affected command line calls of curl.

From the CLI on the virtual private server that was having issues (Hostnames faked to protect the innocent).

1.) Step one was to do a “curl” command

[root@ ~]# curl host.com
curl: (6) Couldn’t resolve host ‘host.com’

2.) Subsequent NSLOOKUP commands would fail right after the “curl” command as well.

** server can’t find host.com: NXDOMAIN

3.) A few minutes later it would reset and we could do a single “curl” successfully. It would then setup off the same chain reaction.

4.) After much back and forth, the hosting company attempted to blame the “host.com” dns servers for being incorrectly setup.

We had to show that it was in fact the hosting company’s nameservers that were having issues with curl.

5.) On the hosted server we need it to use other nameservers.

nano /etc/resolv.conf

Comment out ALL the nameservers by putting # in front of the lines that start with “nameserver”

Add Google’s public nameserver. “nameserver 8.8.8.8”

6.) With the new nameserver in place, re-run the “curl” commands. They worked flawlessly each and every time.

7.) Granted, we could have simply used the public DNS server and have been done with the issue.
Since our customer is paying to use the services that were advertised from the hosting company and public DNS’s have no guareentee of availability, this would not have been a valid solution.

Finally the hosting company figured out what we believed was the issue. CURL was doing the nameserver lookup on the first call and looking for the IPv4 response. That would work great. The second call, for some reason, would try and look up the IPv6 version of the name, which did not exist and returned the NXDOMAIN.

The NXDOMAIN was coming back and caching for the very next lookup to that domain.

So the issue turned out to be curl! Using the “curl -4” option (forces curl to use IPv4 only), we could continue to lookup the domain from the command line without any issues.

The reason that Google’s worked, is that they do not respond back to IPv6 requests (at the writing of this article).

We tried upgrading the VPS to the later version of PHP (5.3.3) and telling PHP CURL to only use IPv4 ($NuSOAPclient->setCurlOption(CURLOPT_IPRESOLVE,CURL_IPRESOLVE_V4);).

This unfortunately would not work. Another option was to recompile the Curl library and disable IPv6, but we could not do that on this VPS hosting package.

We built a test web service client using the PHP Soap client and this also was affected by the nameserver issue.

Using the public DNS servers were not an option either because they are out of our “sphere” of control (and could initiate IPv6 without notice, thereby causing the failure again).

We were unable to compile PHP to disable IPv6 (which would have worked) using the version of WHM that is on the VPS server.

The final solution, was to completely disable IPv6 on the actual VPS host itself, which thankfully was done by the VPS hosting company. This immedialy resolved any naming issues that we were experiencing.

In summary, if you are developing webservices in PHP you NEED to make sure that you develop a small prototype script that you can quickly test in both your development environment and the target system.

Make sure that the name of the webservice that you are going to consume resolves a FEW times in a row, to avoid any issues that you may have when you go to deploy your final solution.

This “adventure” has not made me a fan of IPv6, regardless of the arguments for why everyone needs to eventually move to use the system.