Custom FQDN versus managed by 3CX?

[EscondidoAdmin]

3CX v20u3, on prem, Linux, Ent, 128sc

Trying to get failover working. I've come across a couple instances where there's a reference to a custom FQDN as opposed to one managed by 3CX. How do you use 3CX to manage your FQDN - do they need to host your 3CX instance? I reviewed all the installation screens and I don't see where there's a choice given.

I assume we're using a custom FQDN since we're on prem and using a FQDN like 3cxlab.ourdomain.org. What's weird is when we've forced a manual failover, we get emails from "[email protected] with the body specifying things like "3CX has switched from Passive Mode to Active Mode," "The following service(s) were interrupted," or "Trunk L:10000(Telnyx Lab) has changed status to registered." I read that if 3CX is managing our FQDN then it takes care of changing the public DNS changes for failover.

Question: why would 3CX.net (presumably the 3CX "mothership" have any visibility into our failover status given we're on prem and apparently using a custom FQDN?

Thanks,

 

[Evolute IT]

The 3CX FQDNs provide the DNS (TTL 6h for Pro, 5min for enterprise), and auto-SSL through Let's Encrypt. It is available on all systems, not just 3CX Hosted ones.

When using one, the failover server (passive) is the one doing the monitoring of the active server. When it detects it as down, it takes over and informs the 3CX DNS to update the IP address. The 3CX servers don't know until the passive informs them. It's not actively monitoring your system.

In the case of an on-premise system, the failover is local, so the external IP doesn't change. That is where the two scripts fields come into play. You can use those to update your local DNS (MS DNS for example) to the passive private IP so that your local phones and apps connect to it. You can also use this to update an external custom FQDN if desired, for example when doing a cloud-to-cloud failover with custom FQDNs.

 

[EscondidoAdmin]

The 3CX FQDNs provide the DNS (TTL 6h for Pro, 5min for enterprise), and auto-SSL through Let's Encrypt. It is available on all systems, not just 3CX Hosted ones.

When using one, the failover server (passive) is the one doing the monitoring of the active server. When it detects it as down, it takes over and informs the 3CX DNS to update the IP address. The 3CX servers don't know until the passive informs them. It's not actively monitoring your system.

In the case of an on-premise system, the failover is local, so the external IP doesn't change. That is where the two scripts fields come into play. You can use those to update your local DNS (MS DNS for example) to the passive private IP so that your local phones and apps connect to it. You can also use this to update an external custom FQDN if desired, for example when doing a cloud-to-cloud failover with custom FQDNs.

Thanks for the info.
How do you get a 3CX FQDN? I could swear that I once saw a prompt about this during the install but the last time through an install (yesterday), I didn't see it. Seems like if that's a free service it'd be the way to go.

We use Let's Encrypt - they make it super simple, made a wildcard cert for our 3CXs.

Our two servers are on separate Internet connections so each has a unique IP address. We use Route 53 for external IPs. They have an arrangement where you can designate a primary and secondary, and they do a healthcheck to determine if the secondary's IP needs to be made the active one.

Our internal DNS is handled by Windows AD DNS. I just posted a question about how to have a Linux-based 3CX change the DNS. Seems the solutions I found in a Google search require additional software on the Linux server..
Thanks again,

 

[SteveITS]

During install, step 2 here: https://www.3cx.com/docs/manual/install/#h.rxks23y6mp5a ("Choose a personalized domain (FQDN)"). If you use your own 3cx.example.com domain you need to manage the SSL cert. Otherwise for a 3CX-owned domain they will use an LE cert as noted.

 

[NicholasP_3CX]

Question: why would 3CX.net (presumably the 3CX "mothership" have any visibility into our failover status given we're on prem and apparently using a custom FQDN?

That would be because you are using the 3CX SMTP server, and that is used as the originating email address.

We are not listening in and monitoring your system, but you are using our SMTP service.