Address-specific DNS Name Redirection (ANAME)

Websites hosted by content distribution networks are often served by multiple IP addresses handling different geographic areas. In many cases, an initial query for a domain name returns a CNAME record whose <target> is a name served by the CDN, and which ultimately resolves to a different final answer depending on the client's IP address or subnet, geographic location, or other considerations. It is common practice for websites to publish content at their registered domain name (sometimes referred to as a "bare domain" or "zone apex": for example, "example.com" rather than "www.example.com"). However, forbids the use of CNAME records at the same node as any other record type. Zone apex nodes always contain SOA and NS RRsets, and frequently contain other types such as DNSKEY, MX, TXT/SPF, etc. Consequently, a CNAME record is not permitted at zone apex nodes. It should be noted that relaxed this restriction by allowing coexistence of CNAME with RRSIG and NSEC records, but such exceptions are not applicable to other resource records. RRSIG and NSEC exist to prove the integrity of the CNAME record; they are not intended to associate arbitrary data with the domain name. DNAME is also not a solution, as its function is to redirect all names in the namespace below the DNAME <owner>, not the DNAME <owner> itself. Redirecting website lookups to an alternate domain name via SRV or URI resource records would be an effective solution, but to date this approach has not been accepted by browser implementations. In addition, it is not possible to use SRV records with wildcard names. As a result of the above, the only widely supported and standards-compliant way to publish content at a zone apex is to to place A and/or AAAA records at that node. The flexibility afforded by CNAME is not available. This document specifies a new RR type "ANAME", which provides similar functionality to CNAME, but only for address queries (i.e., for type A or AAAA). The ANAME record can be present at any DNS node, and can coexist with most other RR types, enabling it to be present at a zone apex, or any other place where the presence of other records prevents the use of CNAME. Authoritative servers configured with ANAME records will answer address queries for the ANAME owner with addresses found at the ANAME's target, and also with the ANAME itself. Recursive resolvers which understand ANAME can re-query for the ANAME target, just as if they had received a CNAME response. Recursive resolvers which do not understand ANAME will ignore the ANAME and consume the provided A/AAAA records directly. Similar authoritative functionality has been implemented and deployed by a number of DNS software vendors and service providers, using names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top level redirection. These approaches have all been standards-noncompliant in one way or another, and none have provided a mechanism for a recursive resolver to follow the redirection chain itself.

"Address type" refers to a DNS RR type that encodes a network address. Currently the set of address types consists of A and AAAA. (This is not an exclusive list; in the event that any new address types are standardized in the future, they will be included.) "Address query" refers to a DNS query for any address type. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document defines the "ANAME" DNS resource record type, with RR TYPE value [TBD]. The ANAME presentation format is identical to that of CNAME :

owner ttl class ANAME target The wire format is also identical to CNAME, except that name compression is not permitted in ANAME RDATA, per . Only one ANAME <target> can be defined per <owner>. An ANAME RRset MUST NOT contain more than one resource record.

When an ANAME record is present at a DNS node and a query is received by an authoritative server for type A or AAAA, the authoritative server returns the ANAME RR in the answer section. Because not all querying resolvers understand ANAME, the authoritative server MUST also return address records, as described below. This is conceptually similar to the synthesized CNAME record included with DNAME responses . Authoritative servers implementing ANAME MUST be equipped to resolve the ANAME <target> on the querying resolver's behalf, either by sending queries to an external recursive resolver or by implementing recursive resolution logic internally, so that address records can be expanded when the ANAME <target> is in a separate zone from <owner>. If a query for the ANAME <target> returns a chaining response (i.e., CNAME, DNAME, or another ANAME), then the authoritative server (or the resolver tasked with resolving the ANAME <target> on its behalf) MUST attempt to follow the chain until it is able to resolve a final address response, or until resolution fails. Intermediate ANAMEs, CNAMEs, and DNAMEs MUST be omitted from the response.

If the original query is for type A, and an RRset of type A exists at the final ANAME <target>, then that A RRset (with <owner> changed to match that of the ANAME RR), MUST be appended to the answer section after the ANAME RRset. If an AAAA RRset is also known to exist at the ANAME <target>, then the AAAA RRset MAY be appended to the additional section (again, with <owner> changed to match that of the ANAME RR). Similarly, if the original query was for type AAAA, and an AAAA RRset exists at the final ANAME <target>, then it is appended to the answer section (with <owner> changed), and if an A RRset also exists at the final ANAME <target> then it MAY be appended to the additional section. If the original query is for type ANAME, A and AAAA records MAY be returned in the additional section. If the original query is for type ANY and access to ANY query processing is not restricted, then the answer section MUST contain both the ANAME and the A and AAAA RRsets, if present and successfully resolved at the ANAME <target>. How and when an authoritative server resolves the A and AAAA responses from the ANAME <target> (when it is not itself authoritative for <target>) is unspecified. If the authoritative server is capable of performing recursive resolution, then it MAY resolve the query itself, or it MAY send address queries to an external resolver. It MAY send address queries to the ANAME <target> when loading the zone and cache the responses locally, or it MAY delay resolution of the address records until a query is received for the ANAME <owner>. In either case, for performance reasons, it is RECOMMENDED that address records be cached locally by the authoritative server. Address records cached locally MUST have a limited TTL. The initial TTL for locally-cached address records MUST be set to the minimum of the ANAME TTL and the TTLs of the intermediate and address records retrieved during ANAME <> resolution. The TTL of the cached address records MUST count down, just as it would in a conventional resolver cache. Address records with expired TTLs MUST NOT be used to answer address queries until refreshed by sending a new query to the ANAME <target>. If configured to do so, then the authoritative server MAY, when sending queries to the ANAME <target>, include an EDNS CLIENT-SUBNET (ECS) option , either forwarding an ECS option that was sent to it by the querying resolver, or generating a new ECS option from the querying resolver's address. If a response from the ANAME <target> includes an ECS option with a SCOPE PREFIX-LENGTH greater than zero, the response SHOULD be cached in such a way that it would subsequently only be used in response to queries from the same client subnet. If resolution of the ANAME <target> yields no address records due to NODATA or NXDOMAIN, then the authoritative server MUST return only the ANAME record. If the query was for a specific address type, then the response MUST also include the SOA as in a normal NODATA response, along with NSEC or NSEC3 if applicable. If resolution of the ANAME <target> yields no address records due to some other failure, and the query was for a specific address type, the response MUST include the ANAME record and set the RCODE to SERVFAIL.

If the zone is configured with an A or AAAA RRset at the same DNS node as ANAME, then the ANAME is considered to have already been expanded. If during query processing any address records are found at the same node as an ANAME RR, then the ANAME RR MUST NOT be further expanded by the authoritative server. ANAME MUST NOT coexist with CNAME or any other RR type that restricts the types with which it can itself coexist. Like other types, ANAME MUST NOT exist below a DNAME, but it can coexist at the same node; in fact, the two can be used cooperatively to redirect both the owner name (via ANAME) and everything under it (via DNAME). ANAME can freely coexist at the same owner name with any other RR type.

If the zone in which the ANAME resides is DNSSEC-signed, and if the server has access to its private zone-signing key, then the A and AAAA RRsets MUST be signed, either in advance when populating the A/AAAA answers for the ANAME records, or "on the fly" when responding to a query. If the server does not have access to the private zone-signing key then it MAY return unsigned address records, but this is NOT RECOMMENDED unless every resolver with access to the zone is known to support ANAME (as might be the case in a split-horizon deployment where ANAME records are only served to an internal network with its own resolvers). Validating resolvers which do not yet implement ANAME will not be able to validate the A and AAAA responses included with an ANAME response unless those responses are validly signed by a DNSKEY at the apex of the zone in which the ANAME resides. Passing along the RRSIGs associated with the original A and AAAA RRsets from the ANAME <target> will not be sufficient for DNSSEC validation. Implementers MAY allow address records associated with the ANAME to be populated and signed by the primary server, then sent along with their RRSIGs to secondaries via zone transfer. In this case, the master server MUST respect the TTLs of the address records, MUST refresh the address records by re-resolving the ANAME <target> when their TTLs expire, SHOULD respond to address queries with TTLs that count down as they would when answering from a normal DNS cache, and MUST inform secondary servers via DNS NOTIFY they need to refresh the zone when address records have been updated. A secondary server SHOULD store address records and associated RRSIGs supplied via zone transfer in such a way that their TTLs will count down, as they would in a normal DNS cache, and ultimately trigger a zone refresh query upon reaching zero. When a secondary server is responding to an address query, it SHOULD answer with the reduced TTL, but when responding to a zone transfer request, it MUST answer with the original TTL received from the primary. If this address record expansion and signing during zone transfer is not supported, then every authoritative server providing ANAME responses in a signed zone SHOULD have access to the private zone-signing key for that zone. Deployment of ANAME in signed zones where address records cannot be signed due to lack of access to the private zone-signing key is NOT RECOMMENDED. When ANAME is present in a signed DNS node and address records exist at the ANAME <target>, the type bit map in the NSEC or NSEC3 record for that node MUST include bits for A and/or AAAA as well as ANAME. This is for the benefit of validating resolvers not implementing ANAME which may use a signed proof of nonexistence for type A and AAAA to prevent address queries from being resolved. The type bit map SHOULD only include address types which are known to exist at the <target>.

When a recursive resolver sends a query of type A or AAAA and receives a response with an ANAME RRset in the answer section, it MUST re-query for the ANAME <target>. This is necessary because, in some cases, the address received will be dependent on network topology and other considerations, and the resolver may find a different answer than the authoritative server did. (This requirement MAY be relaxed if both the ANAME <owner> and <target> are validly signed and provably in the same zone.) If resolution fails -- for example, due to the local resolver being nonfunctional or the ANAME <target> zone being unreachable -- then the resolver MAY use the address records that were included in the authoritative response as a fallback. Otherwise, these records MUST NOT be cached or returned. If configured to do so, the resolver MAY include an EDNS CLIENT-SUBNET option both when sending the initial query to the ANAME <owner> and when re-querying for the ANAME <target>. If the response includes a SCOPE PREFIX-LENGTH greater than zero, the response SHOULD be cached in such a way that it would subsequently only be used in response to queries from the same client subnet.

Given the following zone:

$ORIGIN example.com. @ IN SOA example.com hostmaster.example.com 1 7200 600 1209600 60 @ IN NS ns1 @ IN ANAME example.com.my-cdn.example.net. www IN CNAME example.com.my-cdn.example.net. A query for example.com/A would return the following:

;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 5 IN ANAME example.com.my-cdn.example.net. example.com. 5 IN A 192.0.2.1 ;; ADDITIONAL SECTION: example.com. 5 IN AAAA 2001:db8::1 Similarly, for example.com/AAAA:

;; QUESTION SECTION: ;example.com. IN AAAA ;; ANSWER SECTION: example.com. 5 IN ANAME example.com.my-cdn.example.net. example.com. 5 IN AAAA 2001:db8::1 ;; ADDITIONAL SECTION: example.com. 5 IN A 192.0.2.1 A query for example.com/AANME would receive only the ANAME in the answer section, with the addresses for example.com.my-cdn.example.net expanded in the additional section:

;; QUESTION SECTION: ;example.com. IN ANAME ;; ANSWER SECTION: example.com. 5 IN ANAME example.com.my-cdn.example.net. ;; ADDITIONAL SECTION: example.com.my-cdn.example.net. 5 IN A 192.0.2.1 example.com.my-cdn.example.net. 5 IN AAAA 2001:db8::1 Meanwhile, a query for a non-address type would be returned normally:

;; QUESTION SECTION: ;example.com. IN NS ;; ANSWER SECTION: example.com. 5 IN NS ns1.example.com.

When a zone containing ANAME records is transferred to a secondary server, the ANAME records are transferred, but the A or AAAA records retrieved from the ANAME <target> may not be. If the primary server implements ANAME but the secondary server does not, then the two will return different answers for address queries. It is therefore RECOMMENDED that ANAME not be deployed in a zone unless all of the authoritative servers for that zone implement ANAME, or the primary is able to expand the ANAME with the related address RRsets during the zone transfer.

PowerDNS currently implements a similar authoritative-only feature using "ALIAS" records, which are expanded by the primary server and transfered as address records to secondaries. [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, Cloudflare, Amazon, and Akamai.]

An authoritative server which implements ANAME resolves address queries on behalf of its clients, either internally or by querying an external resolver. This resolution must be allowed to take place regardless of whether the client would ordinarily have been permitted by local policy to send recursive queries. When a resolver that does not understand ANAME receives a response containing A or AAAA records with <owner> rewritten to match that of the ANAME RR, this may bypass security mechanisms based on local policy limiting access to the original ANAME <target>. One possible mitigation for this is to make sure the resolver being used during ANAME resolution lives outside of such critical network sections. If ANAME is used in a signed zone, validating resolvers that do not understand ANAME will not be able to valudate the A and AAAA records included in the response, unless the responding server has added signatures for those records. Merely passing along signatures from the <target> is not sufficient. An authoritative server hosting a secure domain that includes ANAME SHOULD therefore have access to the private zone-signing key for that domain; otherwise, the operator must accept that validation failures will be common until ANAME is widly deployed. Both authoritative servers and resolvers that implement ANAME SHOULD carefully check for loops and treat them as an error condition. One possible approach is to implement a hop counter and stop resolution when a maximum hop count is reached. An authoritative resolver returning address records which were obtained by resolving the ANAME <target> is supplying its own best information to clients as to the correct answer. The response may be signed by the authoritative server, but that is not a guarantee of the actual correctness of the answer. This can have the effect of promoting an insecure response from the ANAME <target> to a signed response from the <owner>, which may then appear to clients to be more trustworthy than it should. To mitigate harm from this, DNSSEC validation SHOULD be used when resolving the ANAME <target>. Authoritative servers MAY refuse to expand ANAME records unless the <target> node is both signed and validated.

IANA is requested to assign a DNS RR data type value for the ANAME RR type under the "Resource Record (RR) TYPEs" subregistry under the "Domain Name System (DNS) Parameters" registry. IANA may wish to consider the creation of a registry of address types; addition of new types to such a registry would then implicitly update this specification.

Thanks to Mukund Sivaraman, Stephen Morris, Ray Bellis, Mark Andrews, Richard Salts, Job Snijders, Richard Gibson, Hakan Lindqvist, Jan Vcelak, Tatuya JINMEI, and Tony Finch for discussion and feedback.