• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

Solved hi i got the dns issues dns resoles fine on the machine but 3cx cant resolve fqdns

Status
Not open for further replies.

vcccdell

Joined
Apr 23, 2018
Messages
10
Reaction score
0
i get this
Registration at gv_254-340-7844 has failed. Destination (sip:[email protected]:5060) is not reachable, DNS error resolving FQDN, or service is not available.

and this
Call or Registration to 2544633366@(Ln.10003@Anveo 254) has failed. 0.0.0.0 replied: 503 DNS Timeout; internal

both of the domains are resolving fine from the machine itself
 
Hello @vcccdell

Are you trying to register a provider and you are seeing this message? If so there could be a number of things wrong as you can see from the message.
Firstly did you pass the firewall checker? Is this a local server or hosted? Have you tried using DNS 8.8.8.8 as you primary for a test?
 
yes, i use 8.8.8.8, firewall check passes all green, the fqdn resolves fine via nslookup on that machine (windows 7 pro 64bit) windows firewall is disabled, no antivirus is installed. on anveo trunk i can receive incoming calls just fine outgoing calls fail with this Call or Registration to 2544633366@(Ln.10003@Anveo 254) has failed. 0.0.0.0 replied: 503 DNS Timeout; internal

gvgw.simonics.com does not register with the error in the first post

both trunks work fine if i use ip address instead of fqdn
 
From what i can see from the registrar the provider has SRV records for TLS, TCP and UDP. Since the PBX prioritises TLS over TCP and UDP it is probably trying to connect via TLS which is failing for some reason (could be the certificate or any other reason). I would recommend connecting to the provider with TCP. To force that you need to use the registrar "transport-tcp.gvgw.simonics.com".
Let me know if that works
 
thank you, i tried it here is what i got in the log
Registration at gv_254-340-0044 has failed. Destination (sip:GV12543400044@tcp.gvgw.simonics.com:5060) is not reachable, DNS error resolving FQDN, or service is not available.

i am not able to resolve
tcp.gvgw.simonics.com on any machine, gvgw.simonics.com resolves fine on the server but not on 3cx
 
Interesting...when i do a tracert to gvgw.simonics.com, it resolves to 45.55.163.124 , but i get 30 lines of "Request Timed out".

So something is not quite right.
 
This time i get a different IP
 

Attachments

  • trace.jpeg
    trace.jpeg
    121 KB · Views: 12
I have done hours of searches on this matter, a lot of people have this problem and all of them seem to be the ones who tries to use a trunk that is not officially listed by 3cx as "approved" provider. Feells like 3cx is pushing clients to use Voip providers that they promote. i have an older 3cx debian setup without latest updates and it resolves fqdns and works just fine on the same network. This was confirmed by a few people on 3cx own forum also that older versions of software don't have this issue
 
As i have mentioned above the PBX can now choose what transport to use based on SRV records.
Previous versions could not do that.
The order of preference is TLS (secure), TCP (reliable) and then UDP (least reliable). The provider you are using has SRV records for all 3 transport types. That means that the PBX will try to connect using TLS. The way around this is to use transport-tcp. in front of the registrar so the PBX is forced to use TCP. The reason it works with IP is because the PBX cannot query the SRV records so it defaults to UDP.
If your provider has SRV records but cannot process TLS or TCP then you might have an issue with registration.

The reason why people have issues with un-supported providers is because they have not been tested by us so the way they work is unknown. A supported provider is tested and keeps getting tested with every new release and changes are performed in the templates included in the PBX accordingly.
The tested and working settings are included in the provided templates for each supported provider so the issues are a lot less. We do the testing so you don't have to.
By using an un-supported provider you are forced to do the testing and adjust the configuration accordingly your self.
 
  • Like
Reactions: vanguard08
adding transport-tcp.gvgw.simonics.com have not resolved anything, from the post above i see confirmation that 3cx is not trying to build a system that will work with most popular VOIP providers but instead, promotes a group of providers that are loyal to 3cx. So i guess what i get from it is, if my VOIP provider does not care what 3cx plans are, my options are to stick with an older version of 3cx or move to asterisk based PBX. Too bad i just paid for a license in april 22. I wish i could get my money back and go back to elastix.
 
here is what i get in wire-shark, can you look at it and may be give me a clue


No. Time Source Destination Protocol Length Info
79306 1080.655386 10.0.0.210 8.8.8.8 DNS 87 Standard query 0x042f SRV _sip._udp.gvgw.simonics.com
Frame 79306: 87 bytes on wire (696 bits), 87 bytes captured (696 bits) on interface 0
Ethernet II, Src: Vmware_94:0f:8b (00:0c:29:94:0f:8b), Dst: Sonicwal_08:1c:30 (18:b1:69:08:1c:30)
Internet Protocol Version 4, Src: 10.0.0.210, Dst: 8.8.8.8
User Datagram Protocol, Src Port: 57118, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x042f
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
_sip._udp.gvgw.simonics.com: type SRV, class IN
Name: _sip._udp.gvgw.simonics.com
[Name Length: 27]
[Label Count: 5]
Type: SRV (Server Selection) (33)
Class: IN (0x0001)
[Response In: 79312]
No. Time Source Destination Protocol Length Info
79312 1080.661665 8.8.8.8 10.0.0.210 DNS 516 Standard query response 0x042f SRV _sip._udp.gvgw.simonics.com SRV 0 0 5060 gvgw16.simonics.com SRV 0 0 5060 gvgw14.simonics.com SRV 0 0 5060 gvgw13.simonics.com SRV 0 0 5060 gvgw21.simonics.com SRV 0 0 5060 gvgw12.simonics.com SRV 0 0 5060 gvgw11.simonics.com SRV 0 0 5060 gvgw10.simonics.com SRV 0 0 5060 gvgw15.simonics.com SRV 0 0 5060 gvgw17.simonics.com SRV 0 0 5060 gvgw20.simonics.com SRV 0 0 5060 gvgw18.simonics.com
Frame 79312: 516 bytes on wire (4128 bits), 516 bytes captured (4128 bits) on interface 0
Ethernet II, Src: Sonicwal_08:1c:30 (18:b1:69:08:1c:30), Dst: Vmware_94:0f:8b (00:0c:29:94:0f:8b)
Internet Protocol Version 4, Src: 8.8.8.8, Dst: 10.0.0.210
User Datagram Protocol, Src Port: 53, Dst Port: 57118
Domain Name System (response)
Transaction ID: 0x042f
Flags: 0x8180 Standard query response, No error
Questions: 1
Answer RRs: 11
Authority RRs: 0
Additional RRs: 0
Queries
_sip._udp.gvgw.simonics.com: type SRV, class IN
Name: _sip._udp.gvgw.simonics.com
[Name Length: 27]
[Label Count: 5]
Type: SRV (Server Selection) (33)
Class: IN (0x0001)
Answers
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw16.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw14.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw13.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw21.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw12.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw11.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw10.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw15.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw17.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw20.simonics.com
_sip._udp.gvgw.simonics.com: type SRV, class IN, priority 0, weight 0, port 5060, target gvgw18.simonics.com
[Request In: 79306]
[Time: 0.006279000 seconds]
 
above was query and response that 3cx did and received here is one that is done vial nslookup on the server itself, and it gets clear that it receives back all needed IPs, But when 3cx does it it gets nothing back. So apparently 3cx fails to put correct DNS query


No. Time Source Destination Protocol Length Info
1407 12.003821 10.0.0.210 207.200.0.230 DNS 77 Standard query 0x0002 A gvgw.simonics.com
Frame 1407: 77 bytes on wire (616 bits), 77 bytes captured (616 bits) on interface 0
Ethernet II, Src: Vmware_94:0f:8b (00:0c:29:94:0f:8b), Dst: Sonicwal_08:1c:30 (18:b1:69:08:1c:30)
Internet Protocol Version 4, Src: 10.0.0.210, Dst: 207.200.0.230
User Datagram Protocol, Src Port: 62834, Dst Port: 53
Domain Name System (query)
Transaction ID: 0x0002
Flags: 0x0100 Standard query
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
gvgw.simonics.com: type A, class IN
Name: gvgw.simonics.com
[Name Length: 17]
[Label Count: 3]
Type: A (Host Address) (1)
Class: IN (0x0001)
[Response In: 1408]
No. Time Source Destination Protocol Length Info
1408 12.010382 207.200.0.230 10.0.0.210 DNS 349 Standard query response 0x0002 A gvgw.simonics.com A 45.55.163.124 A 104.236.102.59 A 159.203.110.178 A 159.203.184.149 A 159.203.186.242 A 162.243.0.242 A 162.243.1.217 A 162.243.107.101 A 162.243.210.200 A 165.227.196.211 A 198.199.84.66 NS ns4.he.net NS ns5.he.net NS ns1.he.net NS ns2.he.net NS ns3.he.net
Frame 1408: 349 bytes on wire (2792 bits), 349 bytes captured (2792 bits) on interface 0
Ethernet II, Src: Sonicwal_08:1c:30 (18:b1:69:08:1c:30), Dst: Vmware_94:0f:8b (00:0c:29:94:0f:8b)
Internet Protocol Version 4, Src: 207.200.0.230, Dst: 10.0.0.210
User Datagram Protocol, Src Port: 53, Dst Port: 62834
Domain Name System (response)
Transaction ID: 0x0002
Flags: 0x8180 Standard query response, No error
Questions: 1
Answer RRs: 11
Authority RRs: 5
Additional RRs: 0
Queries
gvgw.simonics.com: type A, class IN
Name: gvgw.simonics.com
[Name Length: 17]
[Label Count: 3]
Type: A (Host Address) (1)
Class: IN (0x0001)
Answers
gvgw.simonics.com: type A, class IN, addr 45.55.163.124
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 45.55.163.124
gvgw.simonics.com: type A, class IN, addr 104.236.102.59
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 104.236.102.59
gvgw.simonics.com: type A, class IN, addr 159.203.110.178
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 159.203.110.178
gvgw.simonics.com: type A, class IN, addr 159.203.184.149
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 159.203.184.149
gvgw.simonics.com: type A, class IN, addr 159.203.186.242
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 159.203.186.242
gvgw.simonics.com: type A, class IN, addr 162.243.0.242
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 162.243.0.242
gvgw.simonics.com: type A, class IN, addr 162.243.1.217
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 162.243.1.217
gvgw.simonics.com: type A, class IN, addr 162.243.107.101
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 162.243.107.101
gvgw.simonics.com: type A, class IN, addr 162.243.210.200
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 162.243.210.200
gvgw.simonics.com: type A, class IN, addr 165.227.196.211
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 165.227.196.211
gvgw.simonics.com: type A, class IN, addr 198.199.84.66
Name: gvgw.simonics.com
Type: A (Host Address) (1)
Class: IN (0x0001)
Time to live: 900
Data length: 4
Address: 198.199.84.66
Authoritative nameservers
simonics.com: type NS, class IN, ns ns4.he.net
Name: simonics.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 75431
Data length: 12
Name Server: ns4.he.net
simonics.com: type NS, class IN, ns ns5.he.net
Name: simonics.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 75431
Data length: 6
Name Server: ns5.he.net
simonics.com: type NS, class IN, ns ns1.he.net
Name: simonics.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 75431
Data length: 6
Name Server: ns1.he.net
simonics.com: type NS, class IN, ns ns2.he.net
Name: simonics.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 75431
Data length: 6
Name Server: ns2.he.net
simonics.com: type NS, class IN, ns ns3.he.net
Name: simonics.com
Type: NS (authoritative Name Server) (2)
Class: IN (0x0001)
Time to live: 75431
Data length: 6
Name Server: ns3.he.net
[Request In: 1407]
[Time: 0.006561000 seconds]
 
adding transport-tcp.gvgw.simonics.com have not resolved anything, from the post above i see confirmation that 3cx is not trying to build a system that will work with most popular VOIP providers but instead, promotes a group of providers that are loyal to 3cx. So i guess what i get from it is, if my VOIP provider does not care what 3cx plans are, my options are to stick with an older version of 3cx or move to asterisk based PBX. Too bad i just paid for a license in april 22. I wish i could get my money back and go back to elastix.

Please note that 3CX is adding functionality with each release that improves security and enables the users to connect through TLS or TCP if the provider supports this and as you can see this is enabled for all providers,not only supported.
As you can understand there are thousands of providers out there, each working slightly differently and without testing all of them there is no way to have them all working out of the box.

Back to the issue at hand. What you have posted above is the 3CX server's SRV query for _sip._udp.gvgw.simonics.com and it gets the correct answers back. You can get the same answers from nslookup if you query for SRV records and not only A records.
The PBX also queries for _sip._tcp.gvgw.simonics.com which is for TCP SRV records and queries
_sips._tcp.gvgw.simonics.com which is for TLS SRV records and it gets answers for all of them.
Additionally the PBX will also check for NAPTR records and AAAA records which your provider does not provide. The PBX will also search for A records.

Since the PBX gets answers for all SRV types back it will prioritise them as stated in my previous replies. Using transport-tcp.gvgw.simonics.com will force the registration to TCP however it is not clear if the provider supports this.

So we are left with UDP. In your case to force UDP registration try setting the registrar gvgw.simonics.com to both the registrar field and the Outbound proxy field with port 5060 as per screenshot below. Let me know if that works.

2018-04-26_10h55_50.png
 
Please note that 3CX is adding functionality with each release that improves security and enables the users to connect through TLS or TCP if the provider supports this and as you can see this is enabled for all providers,not only supported.
As you can understand there are thousands of providers out there, each working slightly differently and without testing all of them there is no way to have them all working out of the box.

Your solution unfortunately did not resolve the issue. When you are saying that 3cx query gets correct reply, if you look in the reply it does not have any single IP address returned, when i do nslookup from the server itself i get multiple ip addresses returned. I dont know how you see it as a correct response. If 3cx does not have IP there is no registration. You are saying there are thousands of providers, yes but they all use same protocols and this is not related as we have an issue with 3cx not sending correct DNS query that does not resolve FQDN into IP address thus failing to register. NSLOOKUP returns a group of IP addresses and works correctly. Mentioned above security improvements do not justify cutting out thousands of providers with the reason "we do not know how they work" since you new how they worked before in older releases of 3cx. It would be nice to give users a choice to disable those "security improvements" if they want to stay with their provider
 
Your solution unfortunately did not resolve the issue. When you are saying that 3cx query gets correct reply, if you look in the reply it does not have any single IP address returned, when i do nslookup from the server itself i get multiple ip addresses returned. I dont know how you see it as a correct response. If 3cx does not have IP there is no registration. You are saying there are thousands of providers, yes but they all use same protocols and this is not related as we have an issue with 3cx not sending correct DNS query that does not resolve FQDN into IP address thus failing to register. NSLOOKUP returns a group of IP addresses and works correctly.

Please note that SRV lookup and nslookup are not the same thing. The SRV lookup will give back SRV addresses and not IPs. What you posted from the PBX was the SRV lookup. The PBX will also perform an nslookup in addition to the SRV. Since the PBX uses uses the DNS server of the NIC of the machine it is installed on the results should be the same.

Mentioned above security improvements do not justify cutting out thousands of providers with the reason "we do not know how they work" since you new how they worked before in older releases of 3cx. It would be nice to give users a choice to disable those "security improvements" if they want to stay with their provider
I have given you the option to force the PBX to register with TCP and UDP which is the way bypass the security improvements. Now we need to see what is not working with these settings as i have tried the suggest settings and the PBX behaves as expected (sending a UDP register request to the correct IP address)

Please do the following test so we can check if the behaviour of the PBX is the correct one.
Make sure the registrar of the provider is set as per screenshot
Then Navigate to Dashboard / Activity Log / Settings and set the logging level to Verbose.
Then start a wireshark capture on the server and restart the 3CX PBX services. Leave the capture running while the PBX is restarting and wait for 2 minutes. Once the 2 minutes are up stop and save the capture. Also generate the support info files from the support tab on the top right of the management console. Once you have both files send me a p.m. so i can take a look at the files.
 
Here is what happened per your suggestion, I had it all done as you directed, trunks came up working for about 20-30 minutes and the went down, so i had to keep capture up for about 40 minutes. Please remove the links once you are able to get the files so i dont share my network info to the public
 
Please remove the links once you are able to get the files so i dont share my network info to the public
You should never post these kind of information in public forums, this is why i suggested you send me a p.m. (private message) on my response.

From the provided data i can see that the PBX resolves the IP addresses of the provider normally and registers successfully to one of the resolved IPs. There is no SRV lookup in this instance as we forced the PBX to use UDP with the proxy. This works as described and the PBX only resolves the providers A records.

2018-04-27_10h34_31.png


The PBX stays registered to both trunks of the provider and it is still registered to the provider until the end of the capture. As you can also see from the screenshot the PBX is using UDP.
2018-04-27_11h08_15.png
I can see however that outbound calls fail at one point but this is not a registration issue as Invites are sent to the Provider. The provider responds with 500 Internal Error to the Invites of the PBX as you can see from the attached screenshot. The Invites are sent to the provider and the provider requests Auth. which means that the Invite was received and the PBX responds.

2018-04-27_11h04_04.png

With that in mind i would recommend contacting your provider and ask them why they are responding with the error. As the issue was that the PBX does not register to the provider i am setting the thread as Resolved and locking it as clearly the PBX now resolves and connects to the provider using the expected transport.
 
  • Like
Reactions: vanguard08
Status
Not open for further replies.

Getting Started - Admin

Latest Posts

Members Online Now

Forum statistics

Threads
141,622
Messages
748,858
Members
144,737
Latest member
damiano giannini
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.