# DNS and TLS — Automatic Certificates, Verified DNS Records

> Let's Encrypt certificates issued and renewed by cert-manager on every zopdev cluster, with Route53, Cloud DNS and Azure DNS solvers for wildcards, plus live DNS record verification.

Source: https://zop.dev/integrations/dns-tls
Updated: 2026-08-20

---

## Common questions

### Does zopdev write records into my DNS zone?

No. Each space publishes a public entry address, you create the record aiming at it, and the Test action resolves your host and compares. Writing to a customer's production zone is a much larger permission than issuing a certificate, and it is not one zopdev asks for.

### Why is there no wildcard certificate option?

HTTP-01 cannot validate a wildcard, so the challenge has to be answered in DNS. The wildcard-capable DNS-01 issuer is emitted only once you supply enough solver configuration: a region for AWS, the Cloud DNS project for GCP, or subscription, resource group and zone name for Azure.

### My host shows pending rather than failed. What does that mean?

That it does not resolve yet. A record added thirty seconds ago has not propagated, which is the normal state rather than an error, so it is reported as pending. Lookups are bounded at five seconds so a hung resolver cannot hold the page open.

Two different things are usually bundled under "DNS and TLS", and zopdev automates exactly one of them. Certificates are fully hands-off. DNS records are not. The zone stays under your control, and zopdev's job is to tell you whether the record you created actually points where it should.

## What cert-manager does without being asked

Every cluster zopdev prepares gets cert-manager installed alongside ingress-nginx and Prometheus, as a required component rather than an opt-in. Straight after install, two ClusterIssuers are applied: `letsencrypt-prod` against the ACME production directory, and `letsencrypt-staging` against the staging one for when you are still testing and do not want to burn rate limits. Both solve HTTP-01 through the nginx ingress class.

From there, issuance is an annotation. When a route names an issuer, the generated Ingress carries `cert-manager.io/cluster-issuer`, and cert-manager takes over: requesting the certificate, completing the challenge, storing the secret, and renewing before expiry without anyone opening a ticket.

## Why a wildcard needs a third issuer

HTTP-01 cannot validate a wildcard. To prove control of `*.example.com` there is no single URL Let's Encrypt can fetch, so the challenge has to be answered in DNS instead. That is why a third, wildcard-capable issuer appears only when zopdev has enough configuration to build a DNS-01 solver for your cloud:

- **AWS** needs a region. cert-manager resolves the hosted zone from the DNS name itself, and the controller's IRSA role supplies `route53:ChangeResourceRecordSets` and `route53:GetChange`.
- **GCP** needs the project that hosts Cloud DNS.
- **Azure** needs subscription, resource group and hosted-zone name, plus an optional managed-identity client ID when the controller authenticates that way.

Supply nothing and the DNS-01 issuer is simply not emitted; the two HTTP-01 issuers render exactly as before. There is no half-configured state that fails at renewal time. Provider values are JSON-encoded before they reach the manifest, so a colon or a newline in a zone name cannot inject keys into the generated YAML.

## The record you create, and the check that confirms it

zopdev never writes to your DNS zone. Each space publishes a public entry address, you create the record aiming at it, and the Test action resolves your host and compares the answer.

The comparison handles the case that trips people up: when the entry address is itself a hostname, such as an AWS load-balancer DNS name, zopdev resolves that too and compares IP sets rather than strings, so a CNAME that is correct does not read as wrong. A host that does not resolve yet is reported as pending rather than failed, because a record added thirty seconds ago has not propagated and that is the normal state, not an error. Lookups are bounded at five seconds so a hung resolver cannot hold the page open.

## Where this leaves you

Certificates: automatic, renewed, nothing to schedule. DNS: one record per host, created by you, verified by zopdev before you rely on it. The split is deliberate. Writing to a customer's production zone is a much larger permission than issuing a certificate, and it is not one zopdev asks for.