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