Paypal error (6) Couldn't resolve host 'api-3t.paypal.com'

Worm? no.

Unique to the servers you're using? Yes.

shags38:

here is an update - my host and PayPal technical support are pointing to it being a script problem with ZenCart

Typical. :(

shags38:

from my host only minutes ago -

As for the issue yourself, I really don't think migrating is going to solve the problem.

It is waaay too early in the diagnostics to make this assumption. In fact, I'll even disagree with this persons way of thinking and will offer a 100% guarantee that I can direct you to several hosts that you can migrate to where you'll not have this problem.

shags38:

We've shown that DNS lookups are working

You have shown that at the error reported at that particular time was indeed DNS lookup error. At this point of time it was also probable that there were other connectivity issues that you wouldn't/couldn't be aware of until the DNS resolvers were working again. It isn't uncommon for the DNS resolvers to appear to be intermittent whilst connectivity to the actual servers being constantly at fault. The two different symptoms having a common cause, typically a firewall misconfiguration/fault.
DNS typically uses a protocol called 'UDP'. Curl uses TCP. The packet data is quite likely to follow different paths.

shags38:

looks good so far. But its definitely not on our Site the issue. I checked again with our network Team.
You are not blocked. Manually you can connect.

Experience tells me that you can trust PayPal when they say you've not been blocked, and if it is a problem from PayPal's site of things I will be very surprised.

shags38:

Being able to resolve our domain (either www.paypal.com, api-3t.paypal.com or otherwise) via manual tools such as 'host' or 'dig' indicates that DNS resolution works and that our nameservers are properly propagating the A-record for our domains.

This would/should never have been in doubt. If the paypal servers didn't resolve from the paypal servers it would probably make world headline news.

shags38:

every test known to man has been done over the past 5 days now - tracerts from different servers at the host, and other route traces, API checks etc - I wont add them to this post as it would take up page after page. Essentially my host is resolving to PayPal.

Perhaps someone is mis-interpreting the results they are seeing?

Besides, it wasn't only a few days ago you posted:
'This response from host only a minute ago "I have tried pinging the site for a response from both our servers and our separate internet connection, and the request is timing out, showing me that it's an issue with PayPal."'

The fact that they even expect a ping response from paypal is indicative that they aren't thinking the problem through.

shags38:

an error message that is similar to the wording of the error (6) but doesn't use that terminology "Error An error occurred when we tried to contact the payment processor.

One thing you should know about error messages. Even though it is sometimes near impossible to know exactly what they mean, whenever you get a different error message it is always because the fault itself has somehow changed. A possible scenario is that initial rules blocked both UDP and TCP, the UDP rules have been relaxed to allow the DNS stuff, but TCP is still blocked (or partially) blocked somewhere.

shags38:

Through doing this I discovered all 9 of my eCommerce sites (all ZC) on the server were affected and had been since Friday 14th.the day the problems started

Factors that don't quite fit the ZC script thing - not that it should arbitrarily be discounted - (a) Host migrated all their servers to a new platform on 14th June,

This is way to much of a coincidence to ignore.

shags38:

one ZC domain on the hosts U.S.A. server works fine, no problems and it is a 100% 'clone' of one of the sites on the Australian server - copied from a .com.au

This has taken me by surprise. I was actually expecting the other way round, with the USA server having a problem (my line of thinking is that this is/was another case of AT&T blocking)

Mind if I ask who you are hosting with? Bigpond are notoriously unreliable, even though among the most expensive.

shags38:

I am having some of my sites migrated to their U.S. server to see if that solves the issue - their operation in the U.S. is using a different platform.

I wish you gave more info here. If your Australian servers are running Windows..... Hhmmmmm... lets leave that for the time being... it opens a different can of worms.

shags38:

The other issue is if I move these particular domains to another cPanel host will they have a different version of CURL operating or does cPanel upgrade every client globally simultaneously ?

cPanel has nothing to do with cURL.
No, cPanel doesn't upgrade every client globally simultaneously. No software does.

shags38:

If there are specific tracert or other reports you want to see please let me know.

I wouldn't mind having a quick look at the tracert output from your hosting site to api-3t.paypal.com

shags38:

as much as I am doubtful there is a ZC scripting issue is there any tests that can be done to determine this?

If it were a zen cart scripting issue, it would be well known (and fixed already), so for this to be a possibility means that one or more of the relevant files have been altered/edited.

shags38:

In my admin on one site only I deleted PayPal and reinstated it to see if that made a difference but it didn't.

Worth trying, but not a surprise it made no difference.

Cheers
Rod

Update: I have migrated a number of the problematic sites to the hosts U.S. server (from Australia) - reason being one site which is a clone of a site in Oz was / is working fine so thought was different server may solve the problem. WRONG !!

Moving to different server and different IP address(es) hasn't made a difference. If it is a CURL issue then they both use cPanel and same version of CURL.

• the 'clone' site on the U.S. server is STILL WORKING FINE so it can't be CURL. Let me explain 'clone' - I built one site and copied it then made only text modifications, nothing else, so by rights the ZC install is exactly the same.

As much as to this point I have not believed this issue had anything to do with ZC script I desperately need to try something (PayPal tech did point to script as I indicated in previous post).

So I need some help with the following please!

** here is what I want to try (1) - I want copy all the files from the clone that is working that have anything to do with PayPal and 'login' (when fault occurs it then defaults to login) and then copy those files to at least one other site overwriting existing files. So I need to know which files / folders I need to copy please.

*** I will also download a new copy of ZC and copy these files you mention above and use them to overwrite on another site.

Hopefully one or the other will work.

Looking forward to some help here please.
cheers,
Mike

p.s. I am more than happy to give you Doc and You RodG the ftp access to one of the sites if you want to test the script - just let me know.

if you wish you can try two sites, one that works and one that doesn't, by putting something in the cart and going through the checkout process up to but not including 'confirm' on the one that works - you won't get that far on the one that doesn't - I have been using pay using PayPal account, not credit card (should not be a difference in the result as it all goes through the same gateway).
http://www.sterlingsilver-rings.com (works) and http://www.silver-rings.com.au (fails)

Put your PayPal module into debug-log-to-file mode and start a test transaction (just enough that it attempts to take you to PayPal ... don't need to complete a sale). Then look in the /logs/ (v1.5.1) or (v1.5.0 or older) /includes/modules/payment/paypal/logs/ folder and post the PayPal_CURL_xxxxxxx.log files that it generates.

shags38:

p.s. I am more than happy to give you Doc and You RodG the ftp access to one of the sites if you want to test the script - just let me know.

Thanks, but no thanks. I prefer not to have access to a site unless I absolutely need too.

FWIW, at this point in time, I'm now starting to think that you may be suffering an account related issue rather than a network/connectivity issue. I'm not seeing what else it could be really. OTOH, if the USA site really is a clone of the AU site, using the same paypal account, etc, then this idea doesn't hold water either.

In fact, if all the details presented are accurate, you won't be having a problem.

The original report "Couldn't resolve host 'api-3t.paypal.com'" has turned out to be a red herring that seems to have been of a transient nature. The fact that it occurred merely attracted your attention to this current issue, which could have been occurring for long before resolver problem.

As usual, follow DrBytes advice... debug-log-to-file.... lets see whats really going on.....

Cheers
Rod.

shags38:

http://www.sterlingsilver-rings.com (works)

Not properly. For whatever reason, the product data and costs aren't being sent to paypal.

shags38:

and http://www.silver-rings. com. au (fails)

This site needs to fixed ASAP. It is currently sitting there waiting for someone to click the button to start the installation process.

Cheers
Rod