DNAME support removed without notification

Hello,

support for domains which use DNAME was removed in https://github.com/letsencrypt/boulder/pull/3082.

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.

1 Like

i would change the tone

i understand you are upset however as a service and a CA Let’s Encrypt is entitled to do as they see best without any obligation to inform users etc.

Would you use a CA that removes a feature that prevents you from renewing your certificate without communicating it beforehand? If so, why?

Hi @gpf,

Take a look to this open issue https://github.com/letsencrypt/boulder/issues/3130

@jsha comments:

Since we rolled back legacy CAA support on Thursday, this shouldn’t be an issue anymore.

Ah, rechecking the code, I see that the DNAME-rejection code was not covered by the flag. We’ll discuss what to do here. Thanks for the report.

So, as far as I know, seems they are working on a fix.

Cheers,
sahsanu

1 Like

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

Andrei

For now, adding (redundant) CNAME records to cover everything necessary ought to work.

1 Like

I have worked with multiple CAs who have done just that.

Can you give a concrete example?

Looks at how companies like Facebook, Google, Amazon and Microsoft deal with change (theirs are much more sudden)

These are not CAs (in the sense that you can get your own certificates from then without using their server/cloud infrastructure).

@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.

5 Likes

Thank you for your reply. I understand the reasons and I’ll see what I can do with CNAMEs.

3 Likes

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.

1 Like

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.

Thanks, team!

FTR: it was indeed populated but then reverted back on Nov 3 according to let’s encrypt status.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.