DNS & TLS

Admin guide

Greenlight uses one delegated DNS zone for the control plane and every app. You make a single change in your parent DNS — delegating that zone to Greenlight’s Azure DNS — and Greenlight owns every record inside it from then on. There is no per-app DNS step, ever.

The one thing you do: delegate the zone

At install you chose a control-plane host, for example greenlight.acme.com. That host is the delegated zone: the control plane lives at the zone apex, and apps live one level down at <app>.greenlight.acme.com.

To delegate it, create NS records for that zone in your parent DNS (the zone for acme.com), pointing at the four Azure nameservers the wizard shows you:

greenlight.acme.com.   NS   ns1-NN.azure-dns.com.
greenlight.acme.com.   NS   ns2-NN.azure-dns.net.
greenlight.acme.com.   NS   ns3-NN.azure-dns.org.
greenlight.acme.com.   NS   ns4-NN.azure-dns.info.

Tip

The wizard reads the exact nameservers live from your zone and renders them with copy buttons on the DNS setup step. Copy them from there rather than transcribing the example above.

This NS delegation is the only manual DNS action. Wait about 5 minutes after adding the records before verifying — public resolvers cache “this name doesn’t exist yet” answers for a short while.

The records Greenlight creates for you

As soon as the zone exists and the ingress load balancer has an IP, Greenlight writes the platform records itself — it does not wait for your delegation to propagate, so they are in place the moment the referral goes live:

Record	Points at	Covers
greenlight.acme.com A (apex)	Traefik load-balancer IP	the control plane
*.greenlight.acme.com A (wildcard)	the same IP	every deployed app

You never hand-create the control-plane A record or any per-app record. The wildcard already resolves every app host.

The certificate: one DNS-01 wildcard

Because the whole zone is delegated to Greenlight, a single Let’s Encrypt wildcard certificate secures everything:

dnsNames: [ greenlight.acme.com, *.greenlight.acme.com ]

• ACME is the protocol cert-manager uses to request and renew the certificate.
• DNS-01 is the challenge it uses: cert-manager writes a temporary _acme-challenge TXT record into the delegated zone, which is possible precisely because Greenlight controls the zone. The challenge never touches the edge proxy.
• HTTP-01 is not used in this model. It returns only for custom domains in your own un-delegated zone Deferred.

How the wizard verifies it

The wizard’s HTTPS readiness step runs four checks, in order, and only enables the identity-provider and GitHub App steps once they pass:

1. NS records resolve — the zone’s NS records resolve through a public resolver and match the Azure nameservers. This catches “you haven’t created the NS records yet” early.

2. Delegation confirmed — the apex A resolves to the ingress IP through a recursive resolver. Because the zone is public, this only succeeds once delegation is actually live.

3. Certificate ready — cert-manager reports the wildcard Certificate as Ready (the DNS-01 challenge succeeded end-to-end).

4. HTTPS healthz — an HTTPS request to https://greenlight.acme.com/healthz returns 200 over a valid Let’s Encrypt chain.

Locked-down egress

Verification needs outbound DNS, and cert-manager needs egress to Let’s Encrypt and the Azure DNS API. If a VPC egress policy blocks these, verification stalls — the wizard flags an egress-blocked check distinctly from “delegation not done” so you know which to fix.

Before the control plane has a name

Until the apex A resolves and the certificate issues, https://greenlight.acme.com is unreachable, so you run the wizard on the raw Azure bootstrap URL (http://<label>.<region>.cloudapp.azure.com/install). Once HTTPS verifies, the wizard hands you off to the final HTTPS URL, and the bootstrap URL is dropped.