A root domain that does not contain a subdomain part e.g. website.com
Canonical Name Record or Alias Record – a type of resource record in the DNS, that specifies that one domain name is an alias of another canonical domain name. e.g. www.website.com or www.thewebsite.com
Domain Name System – connects URLs with their IP address e.g. 123.345.678.90 is www.website.com
Address Record – points a domain or subdomain to its IP address
Domain Information Groper – used to enter a host name and find out the corresponding IP address or DNS record.
Content Delivery Network – a highly-distributed platform of servers
Uniform Resource Locator – a web address, a reference to a web resource that specifies its location on a computer network
Fully Qualified Domain Name – www.website.com – CNAME will correspond to assigned WordPress Site Path
All DXM sites are given a unique hostname using a random string, such as the following example: abcdefghij-prd.ksysweb.com For the purposes of this document, this example will be used to represent the customer DXM site, but you should replace that name with your own if following any of the examples or steps. Also note this example uses a production DXM instance, which is distinguished with the -prd label in the name. All DXM sites also include a -dev (development) and a -stg (staging instance):
The instructions provided below can be applied to any of these instances’ associated hostnames. However, note that live production sites should only be served from the production instances. Some customers may want custom hostnames used against dev and staging instances also.
These hostnames above, are used by content builders to access the WordPress Admin interface and make changes to the site. These are also the hostnames to apply the CNAME for any customer hostname that is to be served through the DXM platform. If multiple names are to be served from the same DXM instance, the same target CNAME is to be used, and these names can be mapped to specific routes within the WordPress site via the DXM Domain Management | Mapping functionality.
A main www site and a blog, both being served via DXM:
www.example.com. TTL IN CNAME abcdefghij-prd.ksysweb.com
blog.example.com. TTL IN CNAME abcdefghij-prd.ksysweb.com
Any additional customer names that are to be served by the DXM site should use the same CNAME record. The same CNAMEs should be used for root/apex records:
Kurtosys recommend that a CNAME record is always utilized where possible since the underlying IPs used by the platform can and do change. Kurtosys utilizes the Cloudflare CDN network which in turn uses Anycast IP addressing. This means that the same IP addresses are used across the Cloudflare network for all geographic edge locations. However, these IPs are controlled by Cloudflare and can change without notice; whilst rare, this is possible.
We understand that there are scenarios where CNAMEs cannot be utilized, typically if your DNS vendor does not support it. The most common scenario encountered is that CNAMEs cannot be used for the root/apex domain (example.com). We strongly recommend you seek a provider that does provide full support. In the event that this cannot be done, A Records can be used with the understanding that the IP addresses used for the record can change. Kurtosys do monitor for changes and we will notify all customers in the event of a change as soon as is possible via our support team. We do not track which customers are using A records rather than CNAMEs.
To obtain the correct IP addresses to use, you can perform a lookup using the dig command against the DXM hostname:
dig help.kurtosys.com +short 126.96.36.199 188.8.131.52
This should return two IP addresses, we recommend an A Record is created for both, but at least one can be used. These IPs are the same for all customers on the DXM production platform, and do not change per site instance. Customer hostnames will be correctly directed to their instance through Cloudflare and DXM domain mapping config.
Taking the examples previously provided, the corresponding A Records would be as follows:
www.example.com. TTL IN A 184.108.40.206
www.example.com. TTL IN A 220.127.116.11
blog.example.com. TTL IN A 18.104.22.168
blog.example.com. TTL IN A 22.214.171.124
For root/apex names, the same process should be followed and the same recommendations apply with respect to the use of CNAMEs vs A Records. The snippet below outlines the configuration to be used when using CNAMEs or A records respectively.
example.com TTL IN CNAME abcdefghij-prd.ksysweb.com
example.com. TTL IN A 126.96.36.199 example.com. TTL IN A 188.8.131.52
Note some DNS providers who cannot support a CNAME for the apex record do alternatively provide a redirect service. In this scenario we would recommend that an A Record is used rather than the redirect service, unless the provider can also support TLS, otherwise requests to the apex name over https will fail.
During the process of transferring to Kurtosys DXM, we recommend that the TTL (time to live) value for the records in question is turned down to maximum 5 minutes. This should also take into account the current values and the amount of time required for the TTL change alone to propagate. Following a successful go live, the records can be turned back up at your discretion.
Testing that changes have been propagated correctly can be performed using a number of freely available tools. For example:
Also note that it is important all testers ensure that they do not have any custom host file entries on local machines or test servers pointing the hostnames in question to the DXM platform, since this will bypass public DNS records.