Address-specific DNS Aliases (ANAME) and Zone Transfer

Introduction A CNAME record redirects all queries at its owner name and, with limited DNSSEC exceptions, cannot coexist with other data. A zone apex necessarily has SOA and NS records, so a CNAME cannot provide portable apex indirection. Static A and AAAA records do not solve the operational problem when a hosting or content-delivery provider controls a dynamic set of addresses. DNS hosting systems have independently deployed solutions called ALIAS, ANAME, apex alias, Route 53 alias, and CNAME flattening. Their common behavior is to resolve a configured target and answer the owner's A and AAAA queries using the target's addresses. Their control data, transfer behavior, failure behavior, and TTL policies differ. Cloudflare describes CNAME flattening as following a CNAME chain and returning the final addresses rather than the CNAME . DNSimple describes its ALIAS as a dynamic A/AAAA lookup performed by its authoritative service . Amazon Route 53 alias records can be placed at an apex but are restricted to selected AWS resources and records . IBM NS1 documents an authoritative ALIAS pseudo-record that is not included in outgoing zone transfers . PowerDNS can either transfer its private ALIAS representation or expand it to addresses, with explicit warnings about refresh and serial-number behavior . This specification replaces those non-portable control-plane differences with one RR type and defines its zone-transfer behavior. It builds on the expired DNSOP ANAME proposal . The principal change is that the ANAME RR itself is the portable zone data: it is carried by AXFR and IXFR, and every capable authoritative server resolves it. Synthesized address RRsets are derived state, not a substitute for transferring the ANAME.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses DNS terminology from .

Address RRset:: An RRset of type A or AAAA.
ANAME owner:: The owner name of an ANAME RR.
ANAME target:: The domain name carried in ANAME RDATA.
Sibling address RRset:: An A or AAAA RRset at the ANAME owner.
Target address RRset:: The terminal A or AAAA RRset obtained after resolving the ANAME target and following permitted CNAME or ANAME links.
Flattening:: Producing an address RRset at the ANAME owner from a target address RRset.
Native secondary:: An authoritative secondary that understands ANAME, receives it in zone transfer, and performs flattening independently.
Materializing secondary:: An ANAME-oblivious secondary that serves address RRsets generated by the primary. This is a transition arrangement and has additional consistency requirements.

The ANAME Resource Record ANAME has RR TYPE value TBD1. Its mnemonic is ANAME.

Presentation and Wire Format The presentation format is: The RDATA consists of exactly one domain name, the ANAME target. Its wire encoding is the DNS name wire format from . Name compression MUST NOT be used within ANAME RDATA, consistent with . Relative names in a master file are resolved by the master-file parser in the same manner as CNAME targets.

Cardinality and Coexistence An ANAME RRset MUST contain exactly one record. An ANAME MUST NOT coexist at the same owner with CNAME or another RR type whose own rules prohibit coexistence. ANAME MAY coexist with SOA, NS, MX, TXT, CAA, and other ordinary types. Authoritative zone configuration MUST NOT contain administrator-managed sibling A or AAAA RRsets at an ANAME owner. Address RRsets generated by the procedures in this document are derived state and are not independent zone content. Wildcard ANAME records are permitted only if an implementation applies the wildcard rules of before flattening. Implementations that cannot preserve those rules MUST reject wildcard ANAME configuration.

Target Resolution and Address Synthesis An ANAME-capable authoritative server performs the following procedure independently for A and AAAA:

Resolve the ANAME target using a recursive resolver that is not dependent on the authoritative server for the ANAME owner. The implementation MUST prevent recursion back into the same unresolved ANAME dependency.
Follow CNAME and ANAME links to a terminal address RRset. The implementation MUST detect loops and MUST impose configurable bounds on chain depth, response size, and resolution time.
Validate the response according to local DNSSEC policy. The security status of the target is discussed in .
Replace the terminal RRset's owner with the ANAME owner and remove signatures belonging to the target zone.
Set each synthesized TTL to no more than the minimum of the ANAME TTL, every followed alias TTL, and the remaining terminal address TTL.

The resulting owner and RDATA form the synthesized address RRset. An implementation MUST NOT combine addresses obtained from different generations of a target RRset.

Resolution Timing and Caching A server MAY flatten when a query arrives, refresh in advance, or use a shared cache. It SHOULD refresh before the cached target expires and SHOULD coalesce concurrent lookups for the same target and address type. A server MUST NOT serve a synthesized positive TTL greater than the remaining lifetime of the data from which it was derived. This prevents TTL extension at the authoritative boundary. A configured ANAME TTL acts as an upper bound, not permission to extend the target TTL.

Negative Answers and Failure Authenticated NXDOMAIN or NODATA for the target produces NODATA for the corresponding address type at the ANAME owner. A timeout, SERVFAIL, validation failure, or malformed target response is a resolution failure, not NODATA. On resolution failure, a server SHOULD return SERVFAIL unless it has previously validated target data eligible for bounded stale serving under . Stale use MUST be bounded by local policy and MUST NOT change the target's DNSSEC security status. A server MUST NOT convert a transient failure into an indefinite empty answer.

Query Processing

A and AAAA Queries For an A or AAAA query at an ANAME owner, an authoritative server MUST answer from the synthesized address RRset produced by . The response is authoritative for the ANAME owner. It MUST NOT contain a CNAME synthesized from the ANAME. An ANAME-capable authoritative server SHOULD also place the ANAME RRset in the Answer section. ANAME-oblivious resolvers ignore the unknown RR type while using the A or AAAA RRset as usual. An implementation MAY omit ANAME from an address response when response-size or compatibility policy requires it; this does not alter the address answer.

ANAME Queries A query for type ANAME is processed as an ordinary authoritative query. If the ANAME exists, the Answer section MUST contain it. The server SHOULD add currently available synthesized A and AAAA RRsets to the Additional section. Their absence does not mean the target lacks addresses.

Other Query Types and Delegations ANAME has no effect on query types other than A, AAAA, ANAME, and ANY. It does not redirect MX, TXT, HTTPS, SVCB, CAA, or any other data. It MUST NOT override a zone cut. The authoritative server applies normal delegation and wildcard processing before applying ANAME synthesis.

Zone Transfer The lack of common transfer semantics is a material interoperability problem in deployed flattening systems. Omitting proprietary control data prevents a secondary from reproducing behavior. Expanding only to A and AAAA records captures a transient observation and does not cause a transfer when the external target changes.

Native AXFR In an AXFR response conforming to , the primary MUST include each ANAME RR in zone scope exactly as it includes any other authoritative RR. The primary MUST NOT suppress ANAME merely because the requester did not advertise support for it. Unknown-RR handling in permits transfer and storage by software that does not yet understand its semantics. A native secondary MUST store the received ANAME RR and perform using its own resolver and cache. It MUST NOT assume that an address RRset materialized at the primary remains current. Consequently, changes to external target addresses do not require the zone serial to change and do not require another transfer when all authoritative servers are native. A primary SHOULD NOT include derived sibling A or AAAA RRsets in native AXFR. If it does include them for transition, a native secondary MUST treat them as replaceable cache seeds, bounded by their TTL, rather than administrator-managed zone data.

Native IXFR IXFR adds, deletes, or replaces the ANAME RR like any other RR. An ANAME target change is a zone-content change and MUST be accompanied by an SOA serial change. Refresh of addresses beneath an unchanged external target is derived state and MUST NOT by itself require an IXFR delta.

Capability Signaling Operators need to know whether every authoritative server will synthesize addresses. This document defines the ANAME-CAPABLE EDNS option, using the option format defined by , with code TBD2 for AXFR and IXFR requests. The option is encoded as follows: OPTION-CODE is the two-octet network-order value TBD2 and OPTION-LENGTH is the two-octet value zero. The option contains no OPTION-DATA in this version. A receiver MUST ignore an ANAME-CAPABLE option whose length is not zero. A native secondary SHOULD include ANAME-CAPABLE in its transfer request. A primary that recognizes it SHOULD include the same empty option in the first transfer response. The option is an assertion of processing capability, not authorization, and does not alter which authoritative RRs are transferred. Absence of ANAME-CAPABLE does not permit omission of ANAME from a standards-conforming transfer. It tells the operator that the secondary might only store the unknown RR and might not answer address queries correctly. A primary SHOULD expose this condition through logging or management telemetry.

Transition with ANAME-oblivious Secondaries A zone using ANAME SHOULD NOT be delegated to an authoritative server that cannot synthesize it. During transition, an operator may configure the primary to materialize A and AAAA RRsets for such a secondary. This is an operational compatibility mode, not native ANAME transfer. In compatibility mode, the primary MUST refresh the target, commit changed sibling addresses as zone changes, increment the SOA serial, and use DNS NOTIFY or an equivalently prompt transfer mechanism. Merely expanding addresses during occasional AXFR while leaving the serial unchanged is NOT RECOMMENDED, because the secondary has no signal that the external target changed. DNSSEC signing of materialized data occurs after flattening and before transfer. The operator is responsible for ensuring that all authoritative servers present a coherent signed zone.

Transfer Authentication ANAME does not change AXFR authorization requirements. Zone transfers commonly disclose the complete namespace and SHOULD be restricted and authenticated using TSIG , SIG(0), mutually authenticated transport, or an equivalent mechanism. ANAME-CAPABLE is not an authentication mechanism.

Examples

Native Primary and Secondary The operator configures the following authoritative data: The AXFR contains the SOA bookends, NS, MX, and ANAME records. It does not need to contain synthesized A or AAAA records. The native secondary advertises ANAME-CAPABLE and stores the ANAME. Each authoritative server independently resolves service.example.net.. If the target's A RRset has TTL 120 and contains 192.0.2.10, an A query can receive: The synthesized A TTL is 120, the smaller of the remaining target TTL and the configured ANAME ceiling. The ANAME retains its own TTL. The MX record and all other owner data remain unaffected. If the target later changes to 192.0.2.20 without any change to the example. zone, both native servers refresh independently. The SOA serial need not change and no transfer is required.

Changing the Target If the administrator changes the target itself to new-service.example.net., the ANAME is authoritative zone content. The primary increments the SOA serial and transfers this deletion and addition through IXFR, or sends the complete new ANAME through AXFR. This differs from an address change beneath an unchanged target.

Legacy Materialization Suppose ns2.example. does not synthesize ANAME. If the operator temporarily uses compatibility mode, the primary commits the current 192.0.2.10 A record as derived zone data for that transfer. When the target changes to 192.0.2.20, the primary must refresh, replace the committed A RRset, increment the serial, notify the secondary, and transfer the change. Expanding only when an unrelated AXFR happens can leave ns2.example. stale indefinitely.

DNSSEC This section uses the DNSSEC protocol and terminology defined by , , and . The ANAME RRset is authoritative zone data and MUST be signed when the zone is signed. Synthesized address RRsets are authoritative statements by the ANAME owner's zone; signatures from the target zone cannot be copied because the owner name differs. A server using online synthesis needs online signing if it returns signed synthesized address RRsets. A server using offline signing MUST materialize, sign, and publish address changes before their previous signatures or operational validity expire. A signed ANAME with no validly signed synthesized address response can cause validating clients to treat an answer as bogus. Signing synthesized addresses asserts that the ANAME owner's authority chose those addresses; it does not preserve the target zone's chain of trust. Implementations SHOULD validate the target before synthesizing signed data and MUST provide a policy for insecure, bogus, and indeterminate targets.

Operational Considerations

Multi-provider Consistency Native authoritative servers resolve from different network locations and caches. A target using geographic, latency, load, or EDNS Client Subnet policy can therefore yield different, individually valid address RRsets. Exact address equality among authorities is not required. Operators SHOULD test that every result is valid for clients and that TTL and failure policies are compatible. Authoritative flatteners SHOULD NOT forward a client's EDNS Client Subnet value by default. If they do, they MUST follow and account for the resulting cache variance and privacy exposure.

Monitoring Implementations SHOULD expose target resolution latency, cache age, refresh failure, DNSSEC status, stale-answer use, chain depth, synthesized TTL, and transfer capability. Operators SHOULD query A and AAAA independently at every authoritative server.

Security Considerations ANAME makes authoritative serving depend on recursive resolution. Implementations MUST isolate that resolver from authoritative query processing sufficiently to prevent deadlock and unbounded resource consumption. They MUST bound target chain length, response size, address count, lookup concurrency, retry rate, and total lookup time. A target controlled by another party can redirect an ANAME owner to arbitrary addresses. This is the intended delegation of address control, but it has security consequences similar to granting that party permission to edit A and AAAA records. Zone administrators SHOULD verify target ownership and lifecycle, and remove ANAME records before relinquishing a target name. Resolvers used for flattening MUST defend against cache poisoning and bailiwick violations. DNSSEC validation SHOULD be enabled. An implementation MUST NOT silently promote a bogus target into signed synthesized data. Self-reference and multi-name loops can cross zone boundaries. Implementations MUST detect loops within one resolution operation. They SHOULD coalesce concurrent lookups for the same target and retain short-lived failure state to suppress repeated cyclic work. On loop detection they MUST terminate the active chain and return SERVFAIL; they MUST NOT start a fresh recursive lookup that discards the known chain context. These requirements limit geometric query amplification when a loop crosses multiple authoritative providers. ANAME targets may resolve to private, loopback, link-local, or other special-use addresses. DNS itself permits such answers, so filtering is a deployment policy. Implementations SHOULD offer policy controls and clear diagnostics, especially where resolver traffic crosses trust boundaries. The transfer capability option is unauthenticated and can be removed or forged by an on-path attacker. It MUST NOT be used to authorize transfer or as the sole basis for a security decision. Authenticated transfer protects both the ANAME target and other zone contents.

IANA Considerations IANA is requested to assign a value from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry as follows:

Type	Value	Meaning	Reference
ANAME	TBD1	Address-specific DNS alias	This document

IANA is requested to assign a value from the "DNS EDNS0 Option Codes (OPT)" registry as follows:

Name	Value	Status	Reference
ANAME-CAPABLE	TBD2	Standard	This document

Implementation and Deployment Experience This section is to be removed before publication as an RFC. rgbdns 0.2.3 implements on-demand authoritative flattening, bounded caching, concurrent-miss coalescing, short-lived failure suppression, TTL capping, CNAME-chain and loop handling, per-zone native transfer, and independent target resolution by its secondary. Before IANA assignment, it uses an explicitly negotiated experimental protocol: EDNS option 65001 containing the four octets RGA1, and private-use TYPE65401 whose RDATA is RGA1 followed by the uncompressed target DNS name. The private RR TTL carries the configured ANAME TTL ceiling. A standard AXFR client does not receive rgbdns's experimental record. This behavior prevents private metadata from being mistaken for an assigned RR, but it is not the final behavior specified in . An implementation of this document will use TBD1 directly and transfer it to all AXFR clients. During migration, rgbdns can accept both its versioned private encoding and the assigned ANAME RR, but MUST NOT emit TYPE65401 as if it were the assigned standard. PowerDNS also uses private-use TYPE65401 for ALIAS, but its RDATA is an unprefixed DNS name . The two encodings are not interoperable despite sharing a private-use value. This collision demonstrates why a private-use RR value cannot establish a cross-vendor standard and why receivers must not infer semantics from TYPE65401 without out-of-band agreement.

Changes from draft-ietf-dnsop-aname-04

Makes the ANAME RR, rather than synthesized sibling addresses, the portable source data for native AXFR and IXFR.
Requires each native authoritative server to resolve the target, eliminating transfer-driven refresh for external address changes.
Adds ANAME-CAPABLE signaling for operational detection without making transfer contents depend on negotiation.
Separates native transfer from a serial-changing materialization mode for legacy secondaries.
Specifies failure, stale-answer, bounds, monitoring, multi-provider, and migration behavior informed by deployed services.
Adds end-to-end examples distinguishing a changed ANAME target from changed addresses beneath an unchanged target.
Documents the rgbdns implementation and the TYPE65401 collision with PowerDNS.

Acknowledgments This document builds on draft-ietf-dnsop-aname by Tony Finch, Evan Hunt, Peter van Dijk, Anthony Eden, and Willem Mekking. Their work and the DNSOP discussions established the ANAME model, terminology, and much of the analysis of TTLs, DNSSEC, and alias chains. Deployment documentation from Cloudflare, DNSimple, Amazon Web Services, IBM NS1, and PowerDNS supplied concrete evidence about flattening behavior and zone-transfer interoperability.