Yes and no. A
CNAME record by that name exists. You can’t have a
CNAME record and a
CAA record with the same name.
91App’s DNS provider (Amazon Route 53) supports an “alias” feature. They should be able to work something out, if they want to. Doing it right would probably require some changes to their current DNS architecture, which they may not be eager to do. (They could probably lower their bills, though!)
Still, it may be a nice feature, but it wouldn’t help you get a Let’s Encrypt certificate.
For what it’s worth, there have been changes to CAA since the RFC was published, to correct errors and make other changes. If you want to read about how the current spec is deployed in practice, you should also read the official errata and the CA/Browser Forum ballots related to it.
Right. Let’s Encrypt isn’t behaving incorrectly.
When the CAA specification says an implementation should “search for” an alias, it’s not requiring the implementation to make extra DNS queries of different types, it’s just specifying how to examine the records it got in response to the DNS query of type
CAA that it did make.
Let CAA(X) be the record set returned in response to performing a CAA
record query on the label X
That’s how DNS resolution normally works. To give an example (while leaving out many steps), if you want the
A (IPv4 address) records for
www.example.com., the recursive DNS server makes an
A query for
www.example.com.. If any such records exist, the authoritative DNS server returns them. If instead a
CNAME record exists, the authoritative server returns it. If nothing at all exists, the authoritative server returns “nothing at all exists”.
When queried for
CAA, the authoritative DNS servers you’re using don’t return anything. Not
CAA records, not the
CNAME that exists (which is what they should return), not any sort of negative response, and not even an error, or something invalid.
That’s broken. As far as a normal DNS client knows, the servers are down, and it should behave accordingly.
Let’s Encrypt could make changes to work around this specific issue. They could make a query of a different type, like
CNAME, first, and cache it, so the following
CAA query would rely on the cached
CNAME and only send
CAA queries to its destination. They could do that always, or when there’s an error. Let’s Encrypt could patch the recursive DNS server to do it, or modify its configuration to increase caching and then patch the CA software to do it. In fact, they could simply ignore all sorts of errors and consider them permission to issue, as long as the zone doesn’t use DNSSEC.
Those types of changes would require some work, or a lot of work, and maybe increase maintenance burden, risk mistakes and compliance failures, and make the service less robust and secure, all for the sake of working around some (but not all) issues with a small proportion of broken DNS servers affecting a small proportion of (prospective) Let’s Encrypt users.
At this time, Let’s Encrypt’s policy position is not to implement hacks or exceptions to work around
CAA bugs in authoritative DNS servers. Some CAs (particularly more expensive and less automated ones) may make other decisions.
I can’t speak for Let’s Encrypt, but I don’t expect that policy to change. In most ways, there’s less justification to change it every day. CAA has been universally required for 3 months, and Let’s Encrypt has deployed it even longer (with, at times, certain exceptions for broken servers). Most widely used DNS implementations were fixed months or years ago. Any DNS provider still having problems has probably been getting yelled at by angry users for 3-4 months, if not longer. It was always hard to justify broken behavior, and it’s even harder now.
Well, I’m sorry to hear that. Sometimes, it is easy to switch DNS providers, or easy to convince them to fix important things they ought to have fixed long ago. Sometimes it’s not.
You say it would take a lot of effort, and that may be true, but… I don’t mean this to be rude, but it would take a lot of effort on your part, and on the part of your DNS provider. Changing Let’s Encrypt would most likely take more effort on the part of Let’s Encrypt’s engineers, and potentially many other people (if something goes wrong). A global cost-benefit analysis of this decision – and isn’t that a way to cause anxiety about everyday concerns, like what to eat for lunch – may not have a result you’d like.
I don’t know how to conclude this post. (Which I definitely need to do before I say something even more ridiculous.) You should contact your DNS provider, but you may need to switch. I’m sorry.