carlos / platform Public

What

wildcardManager.obtain now asks the DNS provider, before it talks to the CA, whether it can publish the _acme-challenge record for a parent at all.

• The check is an optional zoneChecker interface. DNSimple implements it with its zone suffix walk and Route53 with its hosted-zone lookup, the same lookups present makes.
• A miss is errNoZone. No order is placed, and pass backs the parent off for 12h (noZoneRetry) instead of 1h. It is still re-checked, so a zone added later is picked up without a restart.

Why

Once a box has a DNS provider, it tries wildcard certificates for every per-account platform parent (*.<sqid>.<apps-domain>), as well as the static and delegated ones. On carlos.exciting.io the DNSimple account holds only the Jelly zones, not exciting.io. Before this change, every such parent placed an ACME order each hour, failed at present with "no zone found", and deactivated its authorization. That was harmless to the rate limits, because the authorization is never validated and the wildcard flow uses its own ACME account. But it meant a pointless CA round trip and a journal line per parent per hour, forever.

This came up while preparing a *.letsjelly.dev wildcard certificate for the managed-Jelly testbed (see #233). It is independent of the instance-catchall branch.

Testing

• New tests in internal/edge/wildcard_zonecheck_test.go and dns_test.go: - no CA request for a parent with no zone; - the order still goes ahead when the zone is writable; - the 12h back-off; - DNSimple checkZone writes nothing and reports errNoZone.
• The two behaviour tests were watched to fail with the check removed.
• gofmt, go vet ./... and go test ./... are clean, with all 59 packages passing.