We have a domain (hemsida.eu) which we allow our customers to create subdomains under, as a preview-/(or live if they wish) domain. The root-domain (hemsida.eu) does not, and will never, have a DNS-zone because cPanel doesn’t allow a subdomain to be added for another users domain for security reasons (this is default and can be changed, but then, at the risk of users adding subdomains for other users).
This used to work fine (except that we constantly hit the rate limit, but customers who already had a certificate could renew fine), until the implementation with CAA-records. Now, anyone trying to renew a certificate for example.hemsida.eu will fail because Let’s Encrypt doesn’t get any response when trying to lookup the CAA-record for hemsida.eu.
I can imagine that there are other cases where you use subdomains but the “main”-domain isn’t used and doesn’t have any DNS-zone.
Is there any way of excluding a domain from this rule, or, change the policy regarding getting a SERVFAIL/REFUSED so that it would be the same as an empty response?
I don't believe that this is a valid DNS configuration because it is also not possible to get a SOA record for hemsida.eu. (I noticed that your primary nameservers for hemsida.eu literally don't answer any queries related to it, including SOA.)
Checking CAA is going to be made mandatory for all certificate issuance starting this autumn, so I think the answer is no.
I'm not sure about the DNS-part, I tried to look for an RFC describing this configuration but wasn't able to find anything, maybe you got some useful info?
I checked with the people at Comodo who authored RFC 6844 for CAA and got this back:
If there are no records in the zone, there are no CAA records so the discovery continues up to .com which will also have no CAA records and so there will be no constraints on issue.
If the zone is DNSSEC signed and the data is unavailable, the CABForum rules would require the CA to refuse to issue.
They're permitted to. They're also permitted not to, which is the more secure, simple and standards encouraging design.
Currently the validator has no information about why a query failed, if DNSSEC is in use, or how many times it was retried. Guaranteeing BR compliance while loosening requirements on compliant and functional DNS may require non-trivial architectural changes on Let's Encrypt's part.
I’ll second what other folks have said: we take a conservative approach to CAA lookup and do not treat repeated failure as success.
Your DNS setup seems really unusual, and I dont understand what problem you are trying to solve with it. It’s common for a parent domain to allow creation of subdomains and still have its own DNS records. Maybe if you can provide more details on that we can give you some ideas about solving?