Boulder: Support back DNS DNAME records

[sblaisot]

[_Moderator’s note: If you want this issue fixed, use the :thumbsup: emoji reaction on the first post. All “me too” and similar comments will be deleted_].

I heavily rely on DNAME for all my secondary domains.
I has certs with alternate subjects that are DNAME domains.

I had no problem doing that way for monthes (if not years) but since #3082 has been merged, I can not renew my certs anymore.

Please bring back the support of DNS DNAME records.

[sblaisot]

Please note that this regression happen without any CAA record. It is now impossible to issue or renew a certificate for a domain that is a DNAME for another domain.

[jsha]

When was the last time you received an error on your DNAME domains? Since we rolled back legacy CAA support on Thursday, this shouldn't be an issue anymore.

[sblaisot]

My certs are renewed every week on sunday at 6am CEST. Last error of this automatic renew was this morning.

Later this day, I tried to renew manually and got this error again at 3pm CEST today.

So rollback doesn't seems complete.

[jsha]

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.

[Cybso]

I have the same problem since a few days for www.asta.uos.de. The SLD uos.de is DNAME'd to uni-osnabrueck.de. I have no control over the second level domain so I'm not able to change the entry (and since that domain does have literally hundreds of subdomains I bet that the organisation is not willing to change that, too).

[Cybso]

I think this bug should be escalated quickly. The longer this exists, the more valid certificates of DNAME'd based hosts will expire. If necessary the original patch #3082 should be reverted until this thing has been fixed.

[cpu]

If necessary the original patch #3082 should be reverted until this thing has been fixed.

@jsha explained the context of #3082 in the community forums. We can not revert this change without dispensation from the major browser root programs or we risk being in violation of the baseline requirements under a strict reading of the CAA RFC. We're in the process of requesting this dispensation but have not yet received positive acknowledgement from all of the parties required.

[Cybso]

I understand that this is not a technical but a juridical problem. On the other side the suggested workaround to add complementary CNAME records will just not work for large setups or when the nameserver is not under your personal control as in my case.

So, what might be the expected time to collect the dispensations and fix the problem? Is it a matter of days (which means that I can lean back and just wait for the problem to disappear by itself) or by month (which means that I should start to get certificates from another CA by now)?

[jsha]

We've got dispensation from 3 of the 4 major root programs. If we hear back from Microsoft by Monday, the revert can make it into next week's deploy, which should land on Thursday. This is all subject to the potential for unexpected problems like rollbacks which could delay rollout.

[feldi-online]

@jsha Since Monday is over, are there any updates regarding this issue?

[jsha]

Someone from Microsoft wrote back to say they'd check around internally and get back to me, but no time guarantee. I'd definitely recommend putting in place CNAMEs instead of DNAMEs for any domains whose certificates are expiring soon, so you can continue to renew.

[Darkfish]

I have another example where the DNAME exists at the registry between an IDN and non-IDN variant both of which are in the Public Suffix list. I guess I'm waiting this out.

[cyper85]

How much time do you need to implement the change on the productive servers?

[jsha]

We're targeting a week from today.