Editing CNAME record (section)

== ANAME record ==

Several managed DNS platforms implement a non-standard ALIAS<ref>{{cite web |url=https://support.dnsimple.com/articles/alias-record/ |title=ALIAS Records |access-date=2019-07-26}}</ref> or ANAME<ref>{{cite web |url=https://dnsmadeeasy.com/services/anamerecords |title=ANAME Records |access-date=2022-09-24}}</ref> record type. These pseudo records are managed by DNS administrators like CNAME records, but are published and resolved by (some) DNS clients like A records. ANAME records are typically configured to point to another domain, but when queried by a client, answer with an IP address. While ANAME record types were submitted for standardization,<ref name="ietf-aname">{{cite web|url=https://tools.ietf.org/html/draft-ietf-dnsop-aname-04|title=Address-specific DNS aliases (ANAME)|date=2019-07-08|access-date=2019-07-26}}</ref> there are other non-conforming implementations, so they can do whatever the owner of the DNS platform chooses, including existing at the apex of a zone and existing for domains that receive mail.

The main advantage of ANAME records over CNAME records is that they can be used on a [[zone apex]], while a standards-following resolver will not treat domain names with CNAME records as a zone apex.<ref>{{cite web |last1=Goldlust |first1=Suzanne |last2=Almond |first2=Cathy |title=CNAME at the apex of a zone |url=https://kb.isc.org/docs/aa-01640 |website=ISC's Open Source Knowledgebase |publisher=Internet Systems Consortium |access-date=8 April 2023 |ref=isc_aa-01640}}</ref>
Also, while a DNS client requires at least two queries to resolve a CNAME to an A record to an IP address, an ANAME will shift the second and subsequent query to the server. If the DNS server can resolve the A record and cache the requested IP address more efficiently and with less latency than its DNS clients can, then the DNS client can resolve the query faster.

The ANAME record type was submitted as a draft standard to IETF. However, the latest draft document expired in January 2020<ref name="ietf-aname"/> and has been superseded by a series of proposals, the most recent of which is the one for the SVCB and HTTPS record types.<ref>{{cite web |first1=B. |last1=Schwartz |first2=M. |last2=Bishop |first3=E. |last3=Nygren|title=Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) |url=https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https|date=2023-03-11|access-date=2023-04-08}}</ref>