Some DNS hosts offer a way to have an A record that serves an IP address which is determined on-the-fly (or frequently enough via scheduled job) by resolving some other hostname behind the scenes. This is used when example.com (and not a subdomain like www.example.com) MUST point to a host whose IP address changes from time to time, without requiring human intervention every time it changes. The result is that resolving example.com produces an A record, where that A record's IP address is determined by the nameserver dynamically by looking up the IP address of another.example.com which itself could be a CNAME.
DNS Made Easy and easyDNS call it an "ANAME record", Route 53 calls it an "alias resource record", CloudFlare calls it "CNAME Flattening", DNSimple calls it an "ALIAS record". Regardless of what they call it, a standard A record is returned when resolving the hostname.
I haven't come across a publication on how one might implement this, although it's a fairly obvious concept. I intend to replicate this behavior in my nameserver, which is the DNS Manager in Windows Server 2012 R2. Does a plugin for DNS Manager exist for doing this?
EDIT: To avoid the XY problem I'm going to provide full background, starting with The Problem in terms of symptoms, and traversing back through the dependencies since they are an indication of what solutions have and haven't been tried.
SSL/TLS connections to the apex domain (example.com) generate a certificate mismatch. Such connections are not attempted very often, but increasingly so, due to things such as automatic host detection by email clients. For example, we just put in Exchange as our client-facing mail server, and when adding email@example.com as an Exchange account in Android or Mac Mail, the auto host discovery apparently derives "typical" hostnames such as example.com, mail.example.com, exchange.example.com, etc., and gives the user a Big Scary Warning that the CN on the certificate at example.com is not example.com. We actually use exchange.example.com which has a matching cert, but the auto detection must be trying example.com first.
The mismatch warning also occurs when a web browser is pointed to https://example.com, but this is mitigated by the fact that most people type example.com into their address bar, not prefixed with https://, so they end up being upgraded to https://www.example.com with a redirect when necessary. Since www.example.com has a CNAME, so it is able to point to a host where there is no CN mismatch.
Why is there only a matching cert at www.example.com and not example.com?
The server with our matching cert (which, by the way, can easily have SAN entries to match both example.com and *.example.com, no trouble there) is located on an AWS ELB (elastic load balancer) for which Amazon warns that the IP address may change at any time. Due to the dynamic IP address, the ELB is only to be referred to via its hostname, which means a CNAME/ANAME/Flattening/etc. That's why we are able to point www.example.com to the ELB, but not example.com. Amazon suggests using Route 53 to overcome any limitations. When that is not possible, the only solution is to have example.com's A record point not to the ELB, but instead to the upstream server to which normally the ELB reverse proxies.
Why not put the matching cert on that upstream server?
Only the ELB itself is dedicated to me, so only the ELB can have my wildcard cert installed. The upstream server is shared among the hosting provider's clientele. I could have the hosting company add example.com to their laundry list of SANs on their certificate and there wouldn't be a mismatch, but instead I am interested in making full use of the ELB for various reasons.
We are fixed on running DNS in-house on Win2012R2, while all WWW hosts must be on AWS for resiliency.