feat(dstack-ingress): delegate a wildcard's CAA too

Delegation left wildcards with an operator-managed CAA, on the reasoning
that RFC 8659 evaluates `*.example.com` at `example.com` and that is the
operator's own name. It is, but that does not stop it being aliased --
the CA follows a CNAME there like anywhere else.

Verified against the staging CA. With

    *.wb.kvin.wang  CNAME  wb.kvin.wang.bz.kvin.wang
    wb.kvin.wang    CNAME  wb.kvin.wang.bz.kvin.wang
    wb.kvin.wang.bz.kvin.wang  CAA  0 issuewild "example.invalid"

issuance was refused with `While processing CAA for *.wb.kvin.wang: CAA
record for wb.kvin.wang prevents issuance` -- the CA following the base's
alias into the delegated zone and honouring what it found there.

So dnsguide asks for a fourth CNAME on wildcards, aliasing the base, and
the container publishes the CAA with the issuewild tag instead of
skipping it. A wildcard deployment now needs no DNS work after setup
either.

The base has to be aliasable, which a zone apex is not, so a wildcard
served straight off its own zone is not a fit for delegation. Anything a
label down is.

Author: kvinwang

custom-domain/dstack-ingress/README.md

@@ -209,8 +209,8 @@ privilege than you want.
 Set `DELEGATION_ZONE=<delegation-zone>` to move every name this deployment
 needs into a zone your token controls. You create three CNAMEs in the served
 domain's zone **once, before deploying**, and then never touch DNS again — not
-when the app id changes with the compose, not when the ACME account is
-recreated, not when the gateway moves:
+when the app id moves, not when the ACME account is recreated, not when the
+gateway moves:
 
 ```
 svc.example.com                      CNAME  svc.example.com.deleg.example.net
@@ -251,25 +251,21 @@ A wildcard and its base name share a delegated target: both `*.example.com` and
 is fine, since it publishes the same values twice. Two deployments pointing at
 different gateways are not — give them separate delegation zones.
 
-**Wildcards keep an operator-managed CAA.** RFC 8659 evaluates `*.example.com`
-at `example.com`, which is your own name and cannot be aliased away, so for a
-wildcard the container prints the CAA and verifies it rather than publishing it.
-
-> **Security note.** The `accounturi` CAA restricts issuance to this enclave's
-> ACME account and is the control that prevents forged certificates. In
-> delegation mode dstack-ingress cannot set it for you (no token for the served
-> zone), so it prints the record and verifies it. **A CAA that is confirmed
-> absent stops issuance** — set `ALLOW_MISSING_CAA=true` to downgrade that to a
-> warning. Without this CAA, anyone who can satisfy the delegated challenge
-> could obtain a certificate for the domain.
->
-> Use a **dedicated** delegation zone and scope the token to only that zone — a
-> zone shared with other tenants lets anyone with write access to it complete
-> the challenge. `SET_CAA` does not affect delegation mode (this CAA path always
-> runs). If a certificate was previously issued with the standard DNS-plugin
-> authenticator, delete `/etc/letsencrypt/renewal/<domain>.conf` before enabling
-> delegation, otherwise `certbot renew` reuses the old plugin (which needs the
-> production-zone token this mode avoids).
+**A wildcard needs a fourth CNAME.** RFC 8659 evaluates `*.app.example.com` at
+`app.example.com`, so the base gets its own alias and the container publishes an
+`issuewild` CAA behind it:
+
+```
+*.app.example.com                            CNAME  app.example.com.deleg.example.net
+app.example.com                              CNAME  app.example.com.deleg.example.net
+_dstack-app-address-wildcard.app.example.com CNAME  _dstack-app-address-wildcard.app.example.com.deleg.example.net
+_acme-challenge.app.example.com              CNAME  _acme-challenge.app.example.com.deleg.example.net
+```
+
+The base has to be a name you can alias, which rules out a zone apex — an apex
+carries SOA and NS records and a CNAME excludes them. `*.example.com` served
+straight off the `example.com` zone is therefore not a fit for delegation; a
+label down, `*.app.example.com`, is.
 
 The records above are checked the same way tls-alpn-01 checks its own: two DoH
 resolvers, both CAA wire formats, and `DNS_SETUP_MODE` deciding what happens

custom-domain/dstack-ingress/scripts/dns01.sh

@@ -175,21 +175,20 @@ delegation_publish() {
     dnsman.py set_txt --domain "$txt_name" --content "$(txt_record_value)" || return 1
 }
 
-# The accounturi CAA goes on the delegated name, beside the address record.
+# The accounturi CAA goes on the delegated name, beside the gateway pointer.
 #
-# Not for a wildcard: RFC 8659 evaluates `*.example.com` at `example.com`, which
-# is the operator's own name and cannot be aliased away. Wildcards keep the
-# operator-managed CAA.
+# A wildcard is evaluated at its base (RFC 8659), so it needs the `issuewild`
+# tag and it needs the operator to have aliased the base as well -- dnsguide
+# asks for that fourth CNAME. A base that is a zone apex cannot be aliased at
+# all, so such a domain is not a fit for delegation; the CAA check reports the
+# record missing rather than the container pretending to have set it.
 delegation_publish_caa() {
     local domain="$1" account_file account_uri
-    if [[ "$domain" == \*.* ]]; then
-        return 2
-    fi
     account_file=$(get_letsencrypt_account_file) || return 1
     account_uri=$(jq -j '.uri' "$account_file")
     dnsman.py set_caa \
         --domain "$(delegated_name "$domain")" \
-        --caa-tag issue \
+        --caa-tag "$(caa_tag_for "$domain")" \
         --caa-value "letsencrypt.org;validationmethods=dns-01;accounturi=$account_uri"
 }
 
@@ -252,17 +251,11 @@ set_caa_record() {
     # thing stopping anyone else who can satisfy the delegated challenge, so it
     # is not optional here.
     if [ -n "${DELEGATION_ZONE:-}" ]; then
-        delegation_publish_caa "$domain"
-        case $? in
-            0) return ;;
-            2) # Wildcard: RFC 8659 evaluates *.example.com at example.com,
-               # which is the operator's own name and cannot be aliased away,
-               # so ask for it instead of publishing it.
-               delegation_verify_caa "$domain" || exit 1
-               return ;;
-            *) echo "Error: could not publish the CAA record for $domain" >&2
-               exit 1 ;;
-        esac
+        if ! delegation_publish_caa "$domain"; then
+            echo "Error: could not publish the CAA record for $domain" >&2
+            exit 1
+        fi
+        return
     fi
 
     if [ "$SET_CAA" != "true" ]; then

custom-domain/dstack-ingress/scripts/dnsguide.py

@@ -413,11 +413,22 @@ def build_records(args: argparse.Namespace) -> List[Record]:
         # rather than as "does not resolve".
         base = args.domain[2:] if args.domain.startswith("*.") else args.domain
         alias = args.challenge_alias
-        for name, note in (
+        wanted = [
             (args.domain, "routes traffic for this hostname into the delegated zone"),
             (args.txt_name, "lets the container publish the gateway routing target"),
             (f"_acme-challenge.{base}", "delegates the ACME challenge"),
-        ):
+        ]
+        if args.domain.startswith("*."):
+            # RFC 8659 evaluates CAA for *.example.com at example.com, not at the
+            # wildcard, so the base needs its own alias for the CAA to be
+            # delegated too. Verified: with this in place the CA followed it and
+            # honoured an issuewild record in the delegated zone.
+            #
+            # The base has to be aliasable, which a zone apex is not (SOA and
+            # NS live there and a CNAME excludes them), so `*.example.com`
+            # served straight off its own zone is not a fit for delegation.
+            wanted.insert(1, (base, "delegates CAA, which a wildcard is evaluated at"))
+        for name, note in wanted:
             records.append(
                 Record(
                     type="CNAME",

custom-domain/dstack-ingress/scripts/tests/test_dnsguide.py

@@ -146,6 +146,29 @@ def test_absent_without_a_delegation_zone(self):
         self.assertEqual(dnsguide.build_records(self._args("svc.example.com", "")), [])
 
 
+class TestWildcardDelegation(unittest.TestCase):
+    """A wildcard is evaluated at its base, so the base needs its own alias."""
+
+    def _records(self, domain, txt):
+        import argparse
+        return dnsguide.build_records(argparse.Namespace(
+            domain=domain, alias_target="gw", txt_name=txt, txt_value="x",
+            caa_name="", caa_tag="issue", caa_value="", account_uri="",
+            challenge="dns-01", challenge_alias="deleg.net", include="delegated"))
+
+    def test_wildcard_aliases_its_base_as_well(self):
+        names = [r.name for r in self._records(
+            "*.app.example.com", "_dstack-app-address-wildcard.app.example.com")]
+        self.assertIn("app.example.com", names)
+        self.assertEqual(len(names), 4)
+
+    def test_plain_domain_does_not(self):
+        names = [r.name for r in self._records(
+            "svc.example.com", "_dstack-app-address.svc.example.com")]
+        self.assertNotIn("example.com", names)
+        self.assertEqual(len(names), 3)
+
+
 class TestExactCnameCheck(unittest.TestCase):
     """check_alias falls back to comparing addresses; a delegation target has none."""