3CX reports DNS error, but host machine resolving fine

[redgoblet]

After a planned maintenance session and reboot, we started experiencing failed SIP trunk registrations.
3 different trunks (different providers) all failed, each reporting DNS/network issues.

However, pinging the registration servers by hostname from the 3CX machine produced a correct IP resolution and ping response.

Only by using the IP addresses of the SIP carriers' servers were we able to successfully register a trunk. Not ideal, but functional.

I have not found any unfamiliar or incorrect IP addresses in Settings>Advanced>Customer Parameters (another user reported this issue and attributed it to an old, incorrect local IP address buried within one or more of the parameter fields)

DNS is working fine both on the 3CX box and elsewhere throughout the network. I have tried using public DNS servers on the 3CX box with no success.

I'm out of ideas now. All suggestions appreciated.

 

[leejor]

A Wireshark trace of a failed DNS request may help track down the problem, but beyond that, and the fact that a "manual" DNS query, from the same machine works...I don't know.

 

[ucs1]

Hi Red,

I've seen this happen rather frequently with our cloud servers.

DNS is never the issue for us from the OS so to speak.

Registration at UFONE has failed. Destination (sip:[email protected]:5060) is not reachable, DNS error resolving FQDN, or service is not available.

or service is not available

Could service not available be the key to this? If so are we referring to the 3CX Service as we are also the SIP Provider and ISP we have access to monitor all our connections and servers and haven't had any issues on the network.

As our clients are built within their own standalone container on our servers we require unique realms to auth for every trunk / customer so we don't have the luxury of just using the IP Address to authenticate to without me bastardizing the sip servers to allow this if we are experiencing issues.

I normally have this occur on the first tenant in our Cloud Instance, and after this has occurred, restarting the first tenant causes every tenant to have the same problem.

Then I have to troll through and restart each tenants services individually. Obviously I got sick of this and built an automated routine to check and restart based on event log.

Does anything other than registering to the IP Address bring the service back up for you?

 

[redgoblet]

The machine itself resolves just fine, and none of the advanced parameters are misconfigured. Most confusingly, it just broke after operating nicely for an extended period of time.

My options seem limited at this point. A rebuild is out of the question, and restoring from a backup is likely to reload the existing problem.

Nope, only using the IP for the trunk's address works.

 

[gbardissi]

We have seen this as well.

You could script a DNS cache flush or reboot windows on a more regular basis.

 

[ucs1]

You could script a DNS cache flush or reboot windows on a more regular basis.

A reboot of a cloud server will take 50 clients offline?? Not ideal in the slightest

Flushing the DNS has never rectified the problem for me personally.

Restarting the PS itself for us has rectified the problem previously but still no explanation as to what the root cause was.

 

[gbardissi]

You should be rebooting windows once every 30 days anyway as a best practice

 

[redgoblet]

Great news! After installing the latest patch, our system is now resolving properly.

Given the nature of the patch, I'm not sure of the correlation, but I'll take it. IPS issue? No idea. It works now.