Wildcard DNS and automatic certificates

Every new project here gets a subdomain — preview.waterside.work, whatever-next.waterside.work — without anyone touching DNS. Two records make that possible.

The two records

waterside.work      A   <server IP>
*.waterside.work    A   <server IP>

The first covers the bare domain. The second, the wildcard, answers for any name directly beneath it that does not have its own record. Ask for anything.waterside.work and DNS replies with the server’s address.

So DNS stops being a step. It always says “that server”; deciding what actually lives at a name is moved entirely onto the server, where Traefik matches the hostname against its routing rules.

Note what the wildcard does not do: it covers one level only. a.b.waterside.work is not matched by *.waterside.work.

How the certificate arrives

The first time Traefik has a rule for a new hostname, it asks Let’s Encrypt for a certificate using the HTTP-01 challenge:

1. Let’s Encrypt hands Traefik a random token.
2. Traefik serves it at http://<hostname>/.well-known/acme-challenge/<token>.
3. Let’s Encrypt fetches that URL over the public internet. If the token is there, the hostname must point at this server — so it signs a certificate for it.

That is why port 80 stays open even though every site redirects to HTTPS: the challenge itself has to arrive over plain HTTP.

Why not a wildcard certificate?

A single *.waterside.work certificate would need the DNS-01 challenge instead — proving control by creating a TXT record — which means giving the server API credentials for the DNS provider. One certificate per hostname over HTTP-01 needs no credentials at all, and Let’s Encrypt’s limits are far above what a handful of projects will ever touch.

The trade-off: every certificate is published in the public Certificate Transparency logs, so each subdomain’s name is discoverable. That is fine for anything that is either public or behind a login — and nothing here relies on an obscure hostname for its security.