"end in a dot (.)" requirement for CNAME record data is breaking DNS-validated ACME for cert issuers that use CNAME instead of TXT records.

[dolled-possum]

The caddy-dns/digitalocean provider plugin works beautifully for DNS validation required by wildcard certs, as long as the cert issuer uses TXT records. letsencrypt is a good example. As letsencrypt is the default issuer for caddy server, a relevant Caddyfile snippet would look like this:

*.liam00048.staging.kinode.net {
  tls {
    dns digitalocean dop_v1_REDACTED
  }
  reverse_proxy 127.0.0.1:8080
}

and the requested wildcard cert is automatically acquired without difficulty. However, with a certificate issuer who uses CNAME records like ZeroSSL, things are not as smooth. Here is the relevant Caddyfile snippet:

*.liam00048.staging.kinode.net {
  tls {
    issuer zerossl 1bREDACTED {
      dns digitalocean dop_v1_REDACTED
    }
  }
  reverse_proxy 127.0.0.1:8080
}

and here is what is output:

Jun 05 21:30:44 initial-kinode-base1716565637796 caddy[3134455]: {"level":"info","ts":1717623044.6407695,"logger":"tls.obtain","msg":"obtaining certificate","identifier":"*.[liam00048.staging.kinode.net](http://liam00048.staging.kinode.net/)"}
Jun 05 21:30:44 initial-kinode-base1716565637796 caddy[3134455]: {"level":"info","ts":1717623044.6414008,"logger":"tls.issuance.zerossl","msg":"creating certificate","identifiers":["*.[liam00048.staging.kinode.net](http://liam00048.staging.kinode.net/)"]}
Jun 05 21:30:45 initial-kinode-base1716565637796 caddy[3134455]: {"level":"info","ts":1717623045.8740065,"logger":"tls.issuance.zerossl","msg":"created certificate","identifiers":["*.[liam00048.staging.kinode.net](http://liam00048.staging.kinode.net/)"],"cert_id":"4982e51a96c32907eac6556543fd7d78”}
Jun 05 21:30:46 initial-kinode-base1716565637796 caddy[3134455]: {"level":"error","ts":1717623046.0922966,"logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"*.[liam00048.staging.kinode.net](http://liam00048.staging.kinode.net/)","issuer":"zerossl","error":"creating CNAME record: adding temporary record for zone \"[staging.kinode.net](http://staging.kinode.net/).\": POST https://api.digitalocean.com/v2/domains/staging.kinode.net/records: 422 (request \"1abc4790-c36a-443b-8778-8f2b7c0ff413\") Data needs to end with a dot (.)"}

The problem stems from the mismatch of the challenge CNAME target URL sent back from the issuer, a comodoca.com URL that does not end with a dot (.), and your API's requirement that CNAME record_data must end with a dot.

I don't believe your API's requirement that CNAME record_data must end with a dot is unreasonable; after all, the actual format of a CNAME record in an ANSWER SECTION does end in a dot. But I will also note that DigitalOcean does not enforce this requirement on CNAME targets added via DO's Networking->Domains->[domain]->Create New Record UI, while still correctly saving the data with the dot appended:

Would you consider aligning your API functionality with your UI functionality with regard to CNAME record data input requirements? If it's good enough for the UI, it should be sufficient for the API as well, and it would allow DigitalOcean to serve as a DNS validator for ACME wildcard cert issuers that prefer CNAME records to TXT records for their validation.