cancel
Showing results for 
Search instead for 
Did you mean: 

Name lookup timing out

Hi all -

 

I'm having a issue where, all of a sudden, my shopping cart (Shopp) is spitting back an error saying "Authorize.net name lookup timed out".

 

There's no Auth.net response code (which the live chat people say they need in order to assist). This is what's showing up in my error logs:

 

[Sun Jun 03 09:30:01 2012] [error] [client MY.IP.ADDRESS] * name lookup timed out, referer: https://www.globalbeads.com/shop/confirm-order/

 

[Sun Jun 03 09:30:01 2012] [error] [client MY.IP.ADDRESS] * Couldn't resolve host 'secure.authorize.net', referer: https://www.globalbeads.com/shop/confirm-order/

 

It was working totally fine last week. There were no changes to the site that would have caused this.

 

Is something going on with the Auth.net DNS? Is there something new I need to set to "allow" transactions from my domain?

 

(MediaTemple shared server, PHP 5.2.17, Wordpress)

 

Thanks for your help.

junger
Member
10 REPLIES 10

The fix for this is frustratingly simple, ..add:

 

define(SHOPP_GATEWAY_TIMEOUT, 75); 

 

to wp-config.php ;) ....it is a timeout issue with mediatempleconnecting to the payment gateway, ...

 

MediaTemple ran several tests this past week and determined its on Authorizenet's end. However they weren't responsive.

 

The fix above basically commands Shopp to wait for an extended period of time for a response back from Authorizenet.

 

That is it, ..fixed, ..but if you wan the technical explanation from mt:

 

BEGIN -->

I looked into this and found something interesting. It looks like the timeout is actually occurring on the PTR record lookup for the IP that secure.authorize.net resolves too, not the domain itself. There seems to be an issue with the configuration of the '118.94.64.in-addr.arpa' sub domain that holds that PTR record.

The dns servers pointed too by the currently cached NS records that manage that /24's PTR records do not seem to respond with any results. They also do not respond properly with NS records for '118.94.64.in-addr.arpa' pointing to themselves. Even worse it also looks like the name servers for the parent sub domain are missing the glue records.

I can duplicate the slow response with any PTR record within 64.94.118.0/24, but not any IP outside of that. For now it looks like authorize.net is having some issues with the authoritative DNS for its PTR records and that is causing your slow curl times.

It should also be noted that secure.authorize.net resolves to two IPs, and the PTR record for one is currently cached on most of the local caches. However, if these issues aren't fixed then once that record drops of our caches this issue may become even more frequent.