Hide menu Last updated: Apr 18 2017
Area: Episerver DXC Service Applies to versions: Not applicable

Going live

This topic describes some typical actions such as mapping host names in the DNS and restricting edit access, when going live with sites in Episerver Digital Experience Cloud Service

Mapping domain host names (required)

Environments in DXC Service are accessed using a set of dxcloud-URLs that are set up and verified according to platform requirements. Examples: http://appname123inte.dxcloud.episerver.net, http://appname123prod.dxcloud.episerver.net

Before going live, you need to apply and verify the same DNS settings for the domain(s) that you intend to use with your DXC Service. This includes creating an awverify record used by Azure, and a CDN-verify record to confirm that you own the domain. 

Usually these DNS records are modified:

  • CNAME - creates an alias for a host name.
  • A-record - maps a host name to an IP address.

Follow the instructions below to modify the DNS settings. You can use for example Microsoft DNS Manager if you host your own name servers, or the web interface of your DNS service provider. Or, contact your DNS service provider if you are unsure how to change these settings.

Modifying the DNS settings

Note: The steps below must be done for all the domains that your application should be associated with. 

Before going live

  1. Ensure your Episerver CMS is configured to respond to the incoming host names you plan to use, for example www.domain.com. You also need to configure some default URLs like host name using "*" (prefered), or alternatively appname123.dxcloud.episerver.net, appname123.azurewebsites.net and appname123-slot.azurewebsites.net. The "appname123-slot.azurewebsites.net" address is used to validate the site during deployments.
      
    Mapping of host names and URLs is done in the Episerver CMS admin view under Manage Websites.


       
  2. When the mapping is done, contact Episerver to inform about which URLs you will use.
  3. You will receive an email from Episerver containing:
    1. Verification information for CDN and Azure (cloudflare-verify and awverify, these are standard TXT DNS records).
    2. The A-record pointer to be used later when going live.
  4. Do the following to verify your ownership of the domain and/or subdomain for the CDN and in Azure:
      
    1. CDN: Create a record in your DNS using this format:
      cloudflare-verify.DOMAIN.COM IN TXT XXXXXXXXX-XXXXXXXX (the unique numeric value for the TXT record provided by Episerver).
       
    2. Azure: Create a record in your DNS using this format:
      awverify.SUBDOMAIN.DOMAIN.com IN TXT appname123.azurewebsites.net.
      Example: awverify.www.episerver.net IN TXT dxcwebapp.azurewebsites.net

      Note: You need to verify the settings for Azure and CDN for each domain and/or subdomain that you want your DXC environment to respond to.
  5. When done with the DNS updates, contact Episerver again to finalize the verification procedure, and have your verified domains added to the production environment.

When going live

To send traffic from your custom URL to the DXC Service, you need to create CNAME records in your DNS,  pointing to the corresponding DXC Service endpoint. 

  1. Update the A-record at domain.com so that it points to the IP number you received in step 3 above. 
  2. Add "dxcloud.episerver.net" to the URL you want to target with CNAME.
    Example: www.DOMAIN.com IN CNAME www.DOMAIN.com.dxcloud.episerver.net
    More examples:
    • www.customer.com IN CNAME www.customer.com.dxcloud.episerver.net
    • beta.client.net IN CNAME beta.client.net.dxcloud.episerver.net
    • prod.company.com IN CNAME prod.company.com.dxcloud.episerver.net
    • country.charity.org IN CNAME country.charity.org.dxcloud.episerver.net
  3. When this is done, the site is live.

Redirecting to secure URLs

HTTPS is the secure version of HTTP, adding encryption to the communication between the browser and the editing environment. Redirect in DXC Service follows industry standard best practices, allowing you to redirect from a non-secure www URL to a secure www URL through configuration (see below).

The service supports:

  • Redirect of non-secure www URL "http://www.domain.com" to a secure www URL "https://www.domain.com"
  • Redirect of non-secure root domain "http://domain.com" to www URL "http://www.domain.com"

You can add a redirect rule by modifying the Web.config file of your Episerver solution.

Example: HTTP to HTTPS redirect rule.

<rule name="Redirect to HTTP" stopProcessing="true">
<match url=".*" negate="false"/>
<conditions>
<add input="{HTTPS}" pattern="OFF" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent">

The service does not support the following by default:

  • Using the root domain "domain.com" as the default domain for the site.
  • Redirect of TLS/SSL secured root domain "https://domain.com" to another URL. 
    Note: In many cases this is not needed since it is not common that a site visitor would manually enter for example, https://domain.com and start by typing "https". Rather they would just enter domain.com, which will redirect to the secure URL at https://www.domain.com as expected.

Support for the above can be added if Episerver manages and hosts the DNS zone for that domain. The configurations can be requested  during onboarding or through Episerver.

Restricting log in access (optional)

To ensure that editing environment is only accessed from approved locations, you can restrict the login to only apply to specified "whitelisted" IP addresses. Refer to the Restricting environment section in Environment configurations, for more information on how to do this.

Related topics

Comments