1. Validating Domain Ownership via CNAME Records

Symptom

Incompatibility between the requested TXT record validation method and the specific environment workflow prevents successful domain ownership verification during the Go-Live process.

Root Cause

The domain validation workflow for certain edge configurations requires a CNAME record instead of a TXT record to successfully complete the Domain Control Validation (DCV) process.

Resolution

To validate domain ownership for the Launch project, the following DNS configuration must be implemented:

  1. Identify Validation Type: Confirm that the specific domain validation workflow requires a CNAME-based ACME challenge rather than a standard TXT record.
  2. Configure CNAME Record: Add a CNAME record at your authoritative DNS provider for the _acme-challenge subdomain.
  3. Point to Validation Endpoint: Direct the CNAME record to the platform’s designated validation URL (e.g., _acme-challenge.www.[domain].com CNAME www.[domain].com.[unique-id].dcv.cloudflare.com).
  4. Refer to Documentation: Consult the platform’s Go-Live instructions for the specific unique identifier and endpoint required for your custom domain.

Verification

The issue is resolved when the DNS configuration allows for proper domain validation and the SSL certificate provisions automatically.


2. Serving Assets via Custom Domains

Symptom

Standard asset delivery utilizes default platform domains, which may not align with organizational branding requirements. This necessitates a technical configuration to serve asset public URLs through a custom branded domain.

Root Cause

Default platform URLs are used for standard asset delivery. Masking these with a custom domain requires additional network configurations, such as DNS or proxy layers.

Resolution

Two supported approaches exist for serving assets via a custom domain:

  1. Implement a Web Proxy: Configure a web proxy server to act as an intermediary that rewrites asset requests to utilize the custom domain.
  2. Reverse Proxy Setup: Implement a reverse proxy configuration to direct traffic from the custom domain to the platform's asset origin.
  3. Configure CNAME Record: Establish a CNAME record at the authoritative DNS provider to map the custom domain to the platform's asset delivery endpoint.
  4. Refer to Documentation: Consult official guides for specific reverse proxy configuration logic and DNS mapping details.

Verification

The issue is resolved when asset public URLs successfully resolve and serve content through the configured custom domain.


3. Managing SSL Provisioning and Redirections for Large Domain Sets

Symptom

The inability to effectively provision SSL certificates and manage redirections across a large volume of domains can lead to site unavailability and certificate provisioning failures.

Root Cause

Attempting to manage a very large set of domains under a single service can exceed standard manageability thresholds, complicating the SSL SAN (Subject Alternative Name) update process and certificate issuance.

Resolution

  1. Segment Domain Groups: Split large sets of domains into smaller, manageable groups across separate services to facilitate better processing.
  2. Configure Service Redirections: Set up the necessary redirections between the split services to ensure all traffic points to the primary domain.
  3. Implement CNAME Records: Add the required CNAME records for each domain at the authoritative DNS provider to trigger validation.
  4. Automate SSL Provisioning: Once CNAMEs are verified, allow the platform to automatically provision certificates for the newly added domains.

Verification

The issue is resolved when all domains are successfully added, redirections are functional, and SSL certificates have provisioned automatically across both groups.


4. Configuring Custom Hostnames and Increasing Domain Limits

Symptom

Subdomain traffic is failing to reach a Launch application despite having valid CNAME records in a DNS provider. Additionally, the user is unable to add the necessary domains to the Launch UI due to reaching a project-level limit.

Root Cause

Launch requires every domain intended to receive traffic to be explicitly registered as a "Custom Hostname" in the UI. Furthermore, projects have a default cap on the number of domains allowed, which requires manual intervention to increase.

Resolution

  1. Log in to the Launch dashboard and select your project.
  2. Go to Settings > Domains and click Add Custom Hostname.
  3. Enter the subdomains (e.g., blog.axonius.com) to link them to your application.
  4. If you receive an error stating the domain limit has been reached, contact Contentstack Support to request a limit increase.
  5. Once the limit is raised, complete the addition of the domains.
  6. Verify that your DNS CNAME records point to the correct Launch target.

Verification

After the domains are added and the limit is increased, navigate to the subdomains in a web browser. If the traffic is correctly routed to the Launch application without "Domain Not Found" or limit errors, the issue is resolved.