V18 to Simplify DNS Config. with its DNS Helper
Until now, 3CX has required the use of both a local and external IP in the case of unmanaged networks. Thanks to a new “DNS Helper”, which will be part of V18, we will be able to rely solely on the FQDN. This will simplify the way admins provision endpoints (e.g. IP Phones and 3CX apps), and the way users can access the web client and video conferencing.
Your 3CX FQDN will be automatically configured like this, you won’t have to do anything. If you are using a custom FQDN then you can configure it like that manually.
It’s already possible for knowledgeable administrators and sophisticated networks to allow internal DNS configuration (“Split-Brain DNS”). However, it’s not possible to achieve this for “unmanaged” networks, networks where the router is also the switch, DHCP servers, DNS servers and WiFi Access Points. V18 will unify this for any type of network.
Better usability. One profile for both in/out of office
Thanks to this change, the user will no longer need to switch between an “in” or “out of office” profile / bookmark in the Web Client, nor will it be necessary to restart the Google extension. The clients would auto register to the other IP/URL but it would cause some delay.
You will also be saying goodbye to the multiple URLs we email users upon provisioning an extension or for them to download their reports.
Simplified phone provisioning
There will be no more dropdown to select which interface a device should be provisioned to. It will always be your installation‘s FQDN!
This allows for a simpler relocation of 3CX to a new network, a change of IP address or even a move from on-premise to the cloud. The endpoint will always connect to 3CX via the FQDN, and will obtain new provisioning and configuration commands from the admin.
It also lays the groundwork to unify “Local LAN” and “STUN” provisioning in the future, whilst moving to a default secure SIP implementation for endpoints.
Furthermore, v18 will support AAAA DNS records (IPv6) for 3CX FQDNs when enabled and configured on the host.
How it will work
To achieve the above, the administrator will have the choice of publishing an internal IPv4 address into our public hosted DNS server for 3CX FQDNs. To be clear, RFC 1918, which defines private IP addresses, states that private addresses “Should Not” appear in a public DNS server. Should not, does not mean “must not” – it is a recommendation. It’s very true for SMTP servers (MX records) to ensure deliverability of emails, but in this case it’s different.
With the introduction of IPv6, where a PC/Server has the same IPv6 address internally and publicly masqueraded networks are becoming obsolete anyway, networks can return to their intended design prior to NAT. (Did you know that NAT was an “emergency” solution for the unforeseen popularity and shortage of IPv4 addresses?)
We want your feedback
We are releasing this information before the release of version 18 for the following two reasons:
- To give administrators time to determine which route they would like to go. i.e. Use the DNS Helper service or prepare the network for the change.
- To check that we did not miss a network configuration at customer premises which could lead to inaccessibility of the service once we introduce the change.
To illustrate the difference between enabled and disabled DNS Helper refer to the below two network diagrams. First, let’s determine when the helper service should be enabled or when a local DNS server should be configured. Following v18 you will be able to change your choice whether to use the service or not.
When to enable
Enabling the DNS Helper service should be done if you have internal and external users but a network which does not have an internal DNS server you can control and modify. Please do not just install a DNS server in your network just for this reason! In this case, all users, internal and external, will contact the public DNS server to retrieve both IP addresses of the system. Browsers, IP Phones and our Mobile apps will probe and attempt to connect to any of the IP addresses in a round-robin manner. In case a connection can be established, they will use the successful connection to gain access to 3CX.
When to disable
You should disable the DNS Helper service if you have a network in which you can manage your internal DNS server. Internal users will contact your local DNS server and retrieve the local IP of your 3CX, while external users will contact the public DNS server and receive the external IP. In this way, there is no probing on the client-side as there is only one IP address listed. The same is true if you only have an installation which is in the cloud* and users’ devices connect via STUN or SBC to the service.
We have a guide outlining how to create an additional DNS Zone Record in a Windows DNS server here.
* If you connect your users via a site-to-site VPN to a cloud-hosted instance, then internal and external DNS resolution applies. An internal DNS must be configured to return the internal 3CX address to the VPN endpoints in the remote network!
Custom FQDN
While using a custom FQDN you are already in the command of managing the public DNS entry for customers. You may follow the same approach outlined for 3CX provided FQDNs with the difference that the system cannot do it for you.
