Using Your Own Domain with Inuatek DCC Cloud
This guide explains how to configure your own domain (such as cloud.acme.com or acmecloud.com) for use with a branded login page on the Inuatek DCC Cloud. It also describes the DNS steps required and how Inuatek manages HTTPS certificates on your behalf. This guide does not describe the landing page and branding setup.
Prerequisites
This feature is available with the DCC Extended Feature Package. You will need access to your DNS provider unless you use an Inuatek-provided URL.
Overview
The DCC provides the possibility for a custom-branded landing page, where users log in to the DCC platform under your own company identity - for example, “Acme Cloud”.
In the following, Acme is used as a sample company name, and cloud is the subdomain used for the branded DCC access point.
The branded landing page requires a unique URL that reflects your company branding.
On a Shared DCC, the credentials entered on this landing page will log the user into your DCC environment - the same as via the default address:
https://dcc.inuatek.com.
You may choose one of the following URL types for your branded DCC landing page:
| Option | Example | DNS Action Required | Recommended |
|---|---|---|---|
| 1 | https://acme.inuatek.com | None | Yes |
| 2 | https://cloud.acme.com | CNAME | Yes |
| 3 | https://acmecloud.com | CNAME flattening or A-record | Yes |
The hosting platform for the DCC may be either:
- Shared DCC (
dcc.inuatek.com). Your instance runs on a shared Inuatek environment (fully separated from others). - Own DCC (
acme.inuatek.com). You have a dedicated DCC instance hosted in Inuatek’s or your own Azure tenant.
Both support automated certificate generation via HTTP-01 validation.
Recommended Setup for Subdomains (CNAME)
For any subdomain (such as cloud.acme.com, dcc.acmecloud.com, or www.acmecloud.com), the preferred configuration is a CNAME record.
CNAME Example
| Type | Name / Host | Value / Target | TTL |
|---|---|---|---|
| CNAME | cloud.acme.com | dcc.inuatek.com (Shared DCC) | Default |
| CNAME | cloud.acme.com | acme.inuatek.com (Own DCC) | Default |
After the CNAME is created:
- Inuatek monitors DNS propagation
- Validates the domain
- Issues an SSL/TLS certificate
- Enables HTTPS
- Renews certificates automatically
Important Note About "www"
www.acmecloud.com is a subdomain — not the same as acmecloud.com (the root domain).
This means:
www.acmecloud.comcan use a CNAME without restrictionsacmecloud.com(root) cannot use a CNAME unless the provider supports flattening
If you configure only www.acmecloud.com, users must type www explicitly.
Using Root Domains (acmecloud.com)
In some circumstances, the CNAME method is not possible or preferred. For example if you want to use your root domain, e.g. acmecloud.com, rather than a subdomain (cloud.acme.com).
Root domains behave differently because DNS standards normally do not allow CNAME records at the root level. To support custom domains on a root domain, you have two options.
1. CNAME Flattening (Preferred If Supported)
Some DNS providers offer CNAME flattening or equivalent ALIAS mechanisms, which allow a root domain to behave like it has a CNAME record.
If supported, configure your DNS like this:
acmecloud.com → CNAME → acme.inuatek.com
This setup supports:
- Automated HTTPS certificate generation
- Automated certificate renewal
- Authentication domain consistency
- Long-term maintainability
DNS Providers That Support Flattening or ALIAS
- Cloudflare (CNAME Flattening)
- DNSimple (ALIAS)
- Akamai DNS
- NS1
- Amazon Route53 (ALIAS for AWS endpoints; applicability may vary)
Cloudflare documentation:
https://developers.cloudflare.com/dns/cname-flattening/
2. A-Record Fallback (If Flattening Is Not Supported)
If flattening is not available, the root domain must use an A-record:
acmecloud.com → A → <Inuatek public IP>
This still supports automated certificate generation via HTTP-01 validation.
Inuatek fully supports:
- Automated certificate generation
- Automated certificate renewal
- HTTPS hosting on your domain
Downside: If Inuatek changes its public IP address in the future, the A-record must be updated manually.
Quickguide for Choosing Between Root Domain and Subdomain
-
If you want to use the root domain (
acmecloud.com):- Use CNAME flattening if supported
- Otherwise use an A-record
-
If you want to use a subdomain (
cloud.acme.com,www.acmecloud.com,dcc.acmecloud.com):- Always use a CNAME
In all cases, Inuatek will automatically manage HTTPS certificates once the DNS is correctly configured.
Typical Timeline
| Description | Responsible | Timeframe |
|---|---|---|
| Create DNS record | Customer | 5–10 minutes |
| DNS propagation | Internet | Up to 24 hours |
| Certificate issuance | Inuatek | ~15 minutes after propagation |
| HTTPS activation | Inuatek | Immediate |
Summary
| Domain Type | Preferred Method | Alternative | Auto TLS Supported |
|---|---|---|---|
Subdomain (cloud.acme.com) | CNAME | A-record | Yes |
| Root domain with flattening | Flattened CNAME | — | Yes |
| Root domain without flattening | A-record | — | Yes |
Supplemental Info: Why Forwarding (Redirecting) Cannot Be Used
Some DNS providers offer different types of forwarding, such as:
- Standard redirects (301/302)
- Masked redirects / “URL frame masking”
- Options like “display acmecloud.com in the browser’s address bar”
Although these may appear convenient, forwarding cannot be used for DCC custom-domain integration.
1. Standard redirects change the visible domain
Example:
www.acmecloud.com → 301/302 → acme.inuatek.com
After the redirect, the visible URL becomes:
https://acme.inuatek.com
This removes the customer-owned domain from the login flow and breaks the intended white-label behavior.
2. HTTPS certificates cannot be issued or renewed
Automated TLS validation (HTTP-01 challenge) requires the DCC to receive traffic directly on the customer domain.
With redirects:
- DCC never receives requests on
www.acmecloud.com - Certificate validation fails
- Renewal fails
- Full HTTPS cannot be supported
3. Masked redirects (frame-based forwarding) are incompatible with modern web apps
Some DNS providers offer a “keep your domain visible” option using an invisible iframe.
This approach breaks DCC for several technical reasons:
- The certificate on the framed content (
acme.inuatek.com) does not match the masked domain (acmecloud.com), causing HTTPS errors - Cookies cannot be set reliably inside a cross-domain iframe
- OAuth/OpenID Connect flows block authentication inside iframes
- Modern browser security headers (CSP, X-Frame-Options) often prevent login pages from being framed at all
- SPA routing and API requests often fail due to origin mismatch
In practice, masked redirects almost never work for secure, authenticated applications.
4. Authentication flows require a stable domain
Redirecting—whether standard or masked—introduces a cross-domain transition that can break:
- Session cookies
- OAuth/OIDC callback validation
- CSRF and origin checks
- Secure cookie handling (SameSite, Secure, HttpOnly)
Conclusion
To use a customer-controlled domain with DCC, the domain must be mapped using DNS:
- CNAME (recommended), or
- A-record (fallback)
Redirecting or masking cannot provide the stability, HTTPS support, or authentication compatibility required by DCC.