# DNS Challenge vs HTTP **URL:** \ **Category:** Help\ **Created:** [December 6, 2022, 4:58pm UTC](https://community.letsencrypt.org/t/dns-challenge-vs-http/189051 "2022-12-06T16:58:35Z")\ **Posts on this page:** 3\ **Page:** 2
**Author:** ![Nummer378](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/nummer378/32/49862_2.png) [@Nummer378](https://community.letsencrypt.org/u/Nummer378)\ **Post date:** [December 6, 2022, 9:56pm UTC](https://community.letsencrypt.org/t/dns-challenge-vs-http/189051/21 "2022-12-06T21:56:43Z")
> [@Nummer378](#): > > I also looked at the spec right now and I don't see an obvious problem with restricting issuance via CAA in this case. RFC8659 simplified the path traversal algorithm, which previously required checking both the original FQDN tree and all CNAME trees. Checking the CNAMEs is now optional, but you always have to check the FQDN tree of the original, "before CNAME", domain. This is both in RFC6844 and 8659. > > As I understand OP, they have to point `_acme-challenge.www.example.com` to an external hosting provider. They might also have to point `www.example.com` via CNAME to the hosting provider, @gsloop has not clarified this as I understand this thread. However, even if that is the case it is still possible to put a CAA record on the SLD `example.com`, which is very likely not CNAME'd. > > A `CAA issuewild ";"` on either `www.example.com` or `example.com` prohibits any CA from issuing a wildcard for the corresponding FQDNs and subtrees of it. This applies independently of whether `www.example.com` (or a subtree of it) is pointed via CNAME to someone else. The CAA climbing algorithm always checks up to the TLD of the FQDN to be validated. I just realized a possible issue with this: While the CAA checker algorithm in RFC 8659 does walk up the original FQDN tree, it does stop at the first found CAA record. In addition, it does assume that resolvers follow CNAMEs during existance checking of a CAA record. This creates a potential problem: If `www.example.com` is CNAME'd to `evil.com`, the operator of `evil.com` can set a malicious CAA record on `evil.com`, which will be found before the CAA of `example.com` is checked. CAA checking stops on the first result. A CAA record on `www.example.com` is impossible due to the CNAME. Therefore, in this case a restriction via CAA appears to be indeed impossible and @rmbolger is right. (IIRC, this used to be catched by the old RFC 6844 algorithm, but the newer one doesn't seem to support this use case anymore) (If there is no CNAME on `www.example.com` all of this does not apply) * * * > [@gsloop](#): > > I don't have a need right now, but it's possible I'd want to issue a wildcard certificate _myself_ for the root (\*.example.com). If I setup a CAA then I can't do that, right? The specifics really depend on your exact setup, which CAA record is where. A domain can have much more than one CAA record and they allow for various settings. In particular, there's an extension to the CAA specification (RFC 8657), which allows for restrictions by ACME accounts. Let's Encrypt does not currently support this, but [has plans to do so](https://community.letsencrypt.org/t/rfc-8657-caa-extension-in-production/154552). With this feature, you can forbid anyone but yourself from issuing wildcards. Without the extension, you can still play around with various combinations of CAA records, which might allow what you are looking for. In particular with a CAA record set only on `www.example.com` it does not apply to `example.com`. ---
**Author:** ![gsloop](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/gsloop/32/66220_2.png) [@gsloop](https://community.letsencrypt.org/u/gsloop)\ **Post date:** [December 6, 2022, 10:10pm UTC](https://community.letsencrypt.org/t/dns-challenge-vs-http/189051/22 "2022-12-06T22:10:25Z")
> [@Nummer378](#): > > (If there is no CNAME on `www.example.com` all of this does not apply) Or (provided I'm understanding this right) if the CNAME doesn't point somewhere that a "rogue" CAA record might get set up that short-circuits the CAA at the original domain. i.e. There no ban on having a CNAME, it just can't/shouldn't point to somewhere where a hostile actor can setup a short-circuit CAA record themselves. (Point to somewhere we control, rather than [evil.com](http://evil.com)) Do I have that right? ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [January 5, 2023, 10:11pm UTC](https://community.letsencrypt.org/t/dns-challenge-vs-http/189051/23 "2023-01-05T22:11:08Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. [Previous page](https://community.letsencrypt.org/t/dns-challenge-vs-http/189051.md?page=1)