It looks like ANAME is just a standard-sounding name made up by DNS Made Easy to describe a service offering of theirs that is extremely similar to what a Route 53 Alias does.
I described the differences betweeen an Alias and a CNAME recently on Stack Overflow, but to summarize here:
A DNS server provisioned with a CNAME for a given host hands out a referral indicating the canonical name of the host being looked up, often requiring a second query by the origin resolver to look up that alternate name; an Alias (and from the looks of it, an ANAME) uses internal information the DNS server knows about the "true" destination to simply respond directly to the request, without the need for a second lookup and without any visibility of the intermediate information in the DNS protocol exchanges.
What an Alias provides, in addition to this, is the ability to use information that Route 53 has in its possession about currently valid IP addresses for S3 website endpoints, ELB, and Cloudfront, to respond to A-record queries with authoritative information that is accurate in near real time, which, if you are using those services, is not something any other provider will have at their disposal; of course, the opposite is also true, a Route 53 Alias can't be used to find and return information that isn't intrinsically available to Route 53. You can't just use "any" target for an alias -- only the endpoints of the three services I mentioned above, or other records in the same hosted zone within Route 53.
In this sense, an ANAME and an Alias are not equivalent, depending on what service is providing the back-end... unless the ANAME is pointing (internally) to information that is static.
An ANAME record on another DNS host's service would not be able to provide the same capabilities as Route 53 if the destination is S3, ELB, or CloudFront, in the same way that an Alias on Route 53 would not be able to return answers pointing to another CDN provider's edge locations using internally-available information, because the information isn't internally available to the provider's infrastructure. Otherwise the functionality seems largely the same.
If you want to run you own DNS Server, you can have a look at PowerDNS on Git.
https://github.com/PowerDNS/pdns/tree/alias
You need to build it yourself but in the "alias" Branch is their current implementation of ALIASRR
and it works fine.
Best Answer
No, as those are not actual record types outlined by a standard defining document. All dynamic apex functionality is implementation specific, as there is not a standardized way of dealing with the problem. Fake record types like "ANAME" and "ALIAS", and buzzwords like "CNAME flattening" are all product specific solutions to apex aliasing.
Unless it has changed in recent history, BIND does not have a feature that allows the server software to synthesize an apex A/AAAA record based on a record outside of the zone. You will have to rely on webserver redirects, or execute a hard change to the records yourself as needed. (manually, DDNS, etc.)