We have to handle the disappearance of OS1 anyway :-/.

We could use let's encrypt for both vhost indeed. Nevertheless, Python 2.7 is not available, so I guess using the certtoll-auto script would help (using pip I guess). This is not gonna be the clean install we're used to.

Thank you for the explanation! So to have this working normally we can try moving the website to a less dynamic location at some point. We should also manage the https://ovirt.org redirect (using Let's Encrypt maybe?)

IIRC this is related to the SOA A record being used when there is no MX, but it's true we have proper MX so it should not be a problem. Nevertheless this is not possible to do what seem logical at first glance because this is related to the protocol itself, as explained in RFC1912 chapter 2.4: « A CNAME record is not allowed to coexist with any other data. ». The rest of the chapter explain you cannot combine CNAME and MX or NS, so this is de facto not possible on the SOA RR.

Doesn't this only affect MX records?
I mean MX records must point to A records (true in our case as the MX points to lists.phx.ovirt.org) but this has no relation to other records in the zone file. I do not think the master A record is used anywhere in the SMTP process - it all works over MX.

Not even mentioning that the A record for ovirt.org now points at the wrong server (MM3) which is not used for anything at the moment and not participating in mail exchange.

Here is some documentation with RFC numbers: http://cr.yp.to/im/cname.html

My original comment by mail follows:

I would rather let it like this because:
www.ovirt.org is an alias for beta-ovirtweb.rhcloud.com.
beta-ovirtweb.rhcloud.com is an alias for ex-std-node798.prod.rhcloud.com.
ex-std-node798.prod.rhcloud.com is an alias for
ec2-52-23-162-8.compute-1.amazonaws.com.
ec2-52-23-162-8.compute-1.amazonaws.com has address 52.23.162.8

So I don't think we can count on the node to never change, and that's
the magic of the cloud in fact. We cannot have a CNAME for the domain,
only a A record, so a permanent redirect is fine I think.