Yes, Ably provides an option with our Enterprise packages to have custom CNAME endpoints. Customers who want this feature are often interested in our white-label client libraries as well. Customers using our CNAME feature can also benefit from our Active Traffic management service.
Currently, all of our Ably client libraries connect to two endpoints by default:
- rest.ably.io - this endpoint is used for all REST based requests and is optimised for all standard HTTP-based request types including all REST library requests, Authentication requests, and Comet and JSONP fallback when WebSockets cannot be used.
- realtime.ably.io - this endpoint is used all WebSocket and other realtime protocol connections from our client libraries.
Additionally, if an Ably client library is unable to connect to a data centre due to a network partitioning, DNS or routing issue, our client libraries automatically use fallback hosts to work around these types of issues and ensure that the client can still connect to an alternate data centre. In these cases, the client library will connect to a host name such as a.ably-realtime.com or e.ably-realtime.com.
There are two possible setups for implementing a Custom CNAME endpoint:
Custom domain is an Ably subdomain:
e.g. examplecompany-rest.ably.io, examplecompany-realtime.ably.io.
For these we use Ably's existing wildcard certificate supporting *.ably.io and *.ably-realtime.com.
Custom domain in a Customer subdomain:
We issue the certificate, based on you configuring a CNAME DNS record or other record on *.ably.examplecompany.com being added that authorises issuing a certificate for that subdomain. That means that the setup only needs to be done once, and doesn't require any additional manual intervention each time the certificate needs renewal.
This approach is also much less risky than handing out the wildcard *.examplecompany.com certificate.
As an example, here is how this would work:
- realtime.ably.examplecompany.com is used for the primary endpoint
- [a-e]-fallback.ably.examplecompany.com is used for the fallback domains
- We issue a cert for ably.examplecompany.com and *.ably.examplecompany.com, and it's a CNAME DNS record set up by the customer for that subdomain.
In addition, we then handle all renewals of certs, rolling out to our global endpoints, load balancers etc, without ever having to coordinate with you manually to get new certs issued. This works well for both parties.
Note: By default, Ably serves fallback traffic under the *.ably-realtime.com domain which is managed separately to the main *.ably.io domain. This means even problems at the DNS or registrar level on the primary ably.io domain can be routed around using the fallback mechanism.
When using your own custom domain, we provide these DNS records for you to CNAME to. Whilst we recommend you implement a similar architecture by using CNAMEs under two different domains (e.g. ably.example.com for your primary traffic and ably.fallback-example.com for your fallback traffic, with the latter hosted with a different registrar and using different name servers to the first), that is not required. Therefore, the decision as to whether you need that extra level of redundancy within your own DNS system is your choice.
Please get in touch with us if you would like a custom CNAME end-point for your company so that we can create a premium package for you and advise on pricing.