DNS and TLS — Automatic Certificates, Verified DNS Records
What does the DNS & TLS integration do?
zopdev installs cert-manager on every cluster it prepares and issues Let's Encrypt certificates from 2 HTTP-01 ClusterIssuers, adding a DNS-01 issuer when wildcard certs are needed. DNS records stay yours: you point a host at the space entry address and zopdev verifies the record resolves there.
Coverage by category
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:ChangeResourceRecordSetsandroute53: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.
DNS & TLS integration: 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.
No active rule family targets DNS and TLS — Automatic Certificates, Verified DNS Records today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.