So even though “DNAMEs are extremely rare”, I for example use them for domains. With the result that I’m having 14 days left on my current cert and can’t renew it.
I love Letsencrypt but how can you just remove something like DNAME support, say “they are extremely rare” and not think about people who are using them right now? Did you try to get statistics about how many currently used certs are affected by this? Was any effort made to inform people beforehand?
I’m opening this topic to maybe have you reconsider how you implement these kind of changes before something like this happens again in the future. Also of course I’d like DNAME support back or I’ll have to get some sort of workaround for this before the cert expires.
I have worked with multiple CAs who have done just that.
Changes are inevitable in the field of IT
Looks at how companies like Facebook, Google, Amazon and Microsoft deal with change (theirs are much more sudden)
I would suggest you look around for other services that offer free certificates such as Comodo (90 days) or symantec as a short term fix and wait for comments from those who look after boulder
@ahaw021’s reply here is perhaps a little glib; we always do our best to give as much advance warning as possible on changes like this.
This change was pushed out without sufficient advance warning in part because it was a last minute rush. Shortly before the CAA enforcement deadline came up, Andrew Ayer pointed out a problem with RFC 6844: https://www.rfc-editor.org/errata/eid5097. Under one interpretation, it could be saying DNAMEs should be treated like aliases themselves, rather than as alias generators as they are used in the rest of DNS. This would have meant that our code, which relies on our DNS server to resolve aliases, would be interpreting DNAMEs wrong.
Clearly, the possibility of this interpretation was not intended by the authors of RFC 6844; it was an accident of drafting. However, around the same time, we received feedback from some root programs that they would be taking a strict interpretation of the provisions around alias chasing. See this announcement. The main issue was around tree-climbing on alias targets; that’s been resolved. However, the DNAME question still stands. While we’d like to just interpret DNAMEs in the way obviously intended, that’s a compliance risk for us.
I’ve emailed the IETF LAMPS mailing list seeking consensus on adopting Andrew Ayer’s erratum, which would be the first step in fixing the spec issue. In the meantime, my suggested workaround would be to replace your DNAMEs with equivalent CNAMEs. I realize this is a hassle, and I’m sorry. We’ll post here again once the issue is resolved.
We’ve gotten approval from the various root programs to continue with a natural interpretation of DNAMEs: https://github.com/letsencrypt/boulder/pull/3188. This change should land this week, but we’re not planning a deploy next week, so the change should go live November 2.
Changes are inevitable in the field of IT
Looks at how companies like Facebook, Google, Amazon and Microsoft deal with change (theirs are much more sudden)
One of the stated reasons for the short life of letsencrypt certs is to force people to automate their infrastructure so everything just magically works.
I can certainly understand the frustration when a unilateral decision is made (and not communicated) to break peoples' automation. You buy into the logic and method, and then the rug is pulled out from under you.
If suddenly certs stop validating due to this, it's a bit of a rude awakening for some users. Automation makes it easy to break lots of things really fast, which has always been the biggest pain point. This is a great example of that.
I'm very happy to see that they seem to have taken the issue seriously.