Solved SIP Trunk & DNS

[sandrews]

I am having the same issue as another user had posted where my SIP trunk (Flowroute) entry is not resolving unless changed to an IP address. I am running on Windows Server 2016 (VM under Hyper-V) and have just applied the newest version / patch in hopes of resolving the problem, but no luck. All 3CX services are starting after a reboot. The dashboard will show green / checkmark for Trunks, but the SIP Trunks menu shows it red. Flowroute shows no Active SIP Registrations. Once I change to an IP address, everything comes up and I see the registration in Flowroute's dashboard as well. Any thoughts?

 

[dmayer]

Are you seeing abnormally high CPU usage when using the DNS name vs IP address?

 

[Alphabetic]

Hi

3CX released an update to address this for Windows installations. I would log in to 3CX and check updates.

 

[JohnS_3CX]

Hi,

You should update to 16.0.5.612 from the management console, and let us know how it goes

 

[sandrews]

I have upgraded to 16.0.5.612 this morning in hopes that it would fix the issue and it did not. I am not seeing abnormally high CPU usage when using DNS name.

 

[JohnS_3CX]

Ok in this case it would a good idea to troubleshoot it from scratch. What DNS server are you currently using, and would it be possible to switch it to 8.8.8.8 for example and restart so the change applies across the whole OS ?

 

[sandrews]

I was using internal DNS. Switched to 8.8.8.8 and it was down after restart (services all running). Used the Disable / Enable All option and it went to green status, but I cannot make outbound calls. Pretty much the same issue I have been seeing. And yes, outbound rules are OK. Everything worked fine before an update that was auto-applied over the weekend (had been 16.0.4.x I think).

 

[JohnS_3CX]

I will PM you shortly

 

[sandrews]

Followup: My problems were being caused by something on my server and / or network. Although I had set a static IP and DNS servers on the NIC, the server was still querying the DNS server(s) that they would get by way of DHCP. The DHCP-provided DNS server(s) on our network were not returning complete records, most likely due to our filtering. Queries via nslookup would look fine, hitting the DNS servers set on the NIC (8.8.8.8). But, wireshark packet captures revealed DNS queries (SIP trunk, etc.) going to the old DHCP-provided DNS server(s) on our network.

I've not seen this behavior before with Windows (server2016 in this case). The resolution in my case was to change the DHCP-provided DNS servers to 8.8.8.8 / 8.8.4.4 and reinstate DHCP settings on the NIC. My server was in it's own subnet so not a big deal to make the changes to the DHCP for it. Makes me wonder if switching to Debian Linux to run 3CX on would be better down the road...

My thanks to JohnS_3CX for helping me figure this out.