SIM Relay Response Timeout

[pat1234]

I am encoutering an issue in which a user receives a timeout error about 1 out of 10 transactions.   The response form only returns a simple html page with success or failure message.  There are no links to javacsript/css/images in the response page.   I checked the server logs and there isn't any record in the apache logs of an attempted post request.   I have tried processing credit card transactions myself on the live site and get a response from 1-2 seconds.

I looked through knowledge base and made some changes based on suggestions but still receiving the occasional timeout error.

Any suggestion?  Maybe Apache/PHP post settings for faster response?

Thanks,

Pat

[joatmon]

I experience this problem ocasionally also, one on the Dec 1st and 2 on the 4th most recently. There is never any server log entry for the relay response from Authorize.net when the error occurs. Although they have always denied it, I also am sure this is an Authorize.net issue.

[frudesigner2010]

I have also started having trouble with clients receiving this error. I confess that I don't understand how you changed the DNS lookup so it does not time out. Can anyone help a newbie?

Our site is hosted with 1and1 if that tells you anything.

thanks

Chris

[TSdotNet]

Of course if we could get someone to test it using an IP based wed address - therefore not requiring DNS, it would really help diagnose if the TTL is the issue.

Anyone out there have their own dedicated IP?

 ___________________________________
<-- Kudos is always welcome....
TSdotNet

[TSdotNet]

Chris, somewhere in your 1and1 control panel, presuming they hold the DNS records for your domain name, you will get access to the aname and mx records etc for your address.

In layman terms (and Im sorry if this is insultingly basic) its usually where you can configure subdomains - like developer.authorize.net as opposed to just authorize.net.

Within that area there should be a TTL specified against your records - that is a length of time in seconds that afterwhich the record is to be considered out of date, and therefore needing refreshed. A low TTL means that other DNS servers will constantly be contacting your hosting DNS server, needing refeshed. A high one means a low level of related traffic.

It also means though, that the external DNS servers refering to your domain (such as Authorize.net's) will be forced more regulary to update the records to your site - it is this effect that appears to be helping resolve the problem.

Here is a question for all you Jedi-server-admins out there - if we were all to set our TTLs to 1 sec (or at least a significant number of users) wouldn't that eventually cause more problems? If the DNS server being used to lookup the relay response domain started to grumble under heavy updating traffic - wont it impact just the same? (presuming this is the actual issue)

___________________________________
<-- Kudos is always welcome....
TSdotNet

[bob_b]

TSdotnet,

What I found was that increasing the DNS timeout made things work better -- I changed from 1 hour to 1 week.  It seems that the problem is related to the first lookup after the cached DNS times out.  The first lookup takes too long and the relay timeout error occurs.  Subsequent lookups are from the cached value, so they are much quicker.  I have not had a timeout error for several days now after making the DNS change.  Still haven't heard back from authorize.net support after providing them with the details they asked for.

[TSdotNet]

Bob,

that was exactly the direction I was thinking - and not that Im a DNS Guru by any means, but it seems very plausable that the update process could be 'limping' - so this would ease the pain. In my experience with clients and their websites, they have been very prone to abusing the TTL - for a number of reasons - setting it to 1 believing they can see their site go live asap - or whatever - and never  changing it after its launched.

Kudos to you though for finding this!

[milleamy]

Bob,

We have been having the exact same issue.  I am happy that you found something that could make it better, and I really appreciate your detailed post.  We will see if increasing the TTL time will help.  I think that Authorize.net really needs to address this problem, since it seems to be something that multiple users are experiencing.

[frudesigner2010]

Thanks for the reply (and the basic information) tsdotnet. Unfortunately, 1 and 1 doesn't allow me to access the TTL (I called and spoke with a spectacularly unhelpful young lady). Is there a scripting method to change it on the fly?

Has anyone heard anything from Authorize.net?

[TSdotNet]

Unfortunately TTL is something that can only be set on the DNS server itself - have you considered moving where your domain name's authorative DNS servers? All you need is an external facing DNS server - doesn't matter who owns it - you then add the related DNS records to that server, and adjust your configuration on the domain itself to reflect the change. It really is not a hard one to do - as long has you know all the subdomains(if any) and related IP address(es) for the site itself.

Anyone here got their own DNS server?

___________________________________
<-- Kudos is always welcome....
TSdotNet

[milleamy]

Hello everyone--

I just thought I'd let you know that we changed the TTL setting from 3 hours to two weeks and that does help.  Before, if three hours had elapsed since the last test it would time out.  This morning when I tried it after an elapsed time of about 7 hours, it worked fine.  So this does seem to be the key.

Does anyone know why Authorize.net's server is not able to do a domain name lookup in a timely fassion?