Cloud services

Blog post

Sometimes the right DNS automation is a handoff

A platform can belong to the same enterprise as a domain and still have no authority to change its records. We designed onboarding so another DNS team can participate without joining our subscription or learning our cloud.

A platform team hands ownership and traffic record cards to a DNS operator, who activates a certified custom-domain gateway

Visitor certificates are managed by Azure Front Door. The handshake policy is chosen once for the site and applied to every hostname on that site; by default it offers TLS 1.2 and TLS 1.3 with current GCM suites. The separate encrypted hop from Front Door to the storage website endpoint is origin TLS and is not controlled by that visitor setting.

The tenant publishing workflow never updates a custom domain, certificate, or DNS record. Those are provisioning concerns. And when a leaf is marked external_dns, “external” simply means this stack must not write the zone—it may still belong to another team in the same organization.

The two-apply handshake

Delegated zones, affiliated top-level domains, and registrars run by another group are expected, not edge cases. We split provisioning at the exact point where their authority is required:

  1. First apply Create the Front Door domains so Azure emits each _dnsauth token. Identity, prefix, and access controls may also be created, but routes wait.
  2. Record sheet Give the DNS operator one TXT record plus a traffic CNAME or apex alias. They need no Azure login. Recreating a domain rotates this token.
  3. Public proof Once the TXT answer matches Azure, set dns_ownership_txt_published to record that the handoff is complete.
  4. Second apply Attach routes with fixed originPath /<PROJECT_ID>/<fqdn>/public while inbound matching remains /*. Sibling state/ is outside the tenant hostname's route. Front Door can approve the domain and finish its managed certificate.

When this stack is authoritative for the zone, one apply writes both the traffic and validation records and the published flag is irrelevant. In either mode, live validation tokens stay out of git.

Choosing the visitor TLS policy

Leaf-wide choiceWhat it means
Current TLS 1.2 + 1.3, GCM-only for 1.2Our product default and the right answer for most sites.
Older TLS 1.2 set with CBCBroader compatibility for older clients in exchange for weaker suites.
Minimum TLS 1.3A stricter posture that intentionally drops TLS 1.2-only devices.
TLS 1.0 values still enumerated by ARMNot a product promise: Microsoft documents that this Front Door tier does not support client TLS 1.0/1.1.

One last distinction saves a surprising amount of confusion: the traffic CNAME or alias sends visitors to the edge; the _dnsauth TXT proves control of the name. The traffic record is not the validation gate, and a portal showing “DNS configured” is not the same as Front Door reporting the domain Approved.

Continue to what happens at the edge and origin, or return to all posts.