| Internet-Draft | ANAME and Zone Transfer | July 2026 |
| Khrabrov | Expires 31 January 2027 | [Page] |
This document defines the ANAME DNS resource record. ANAME provides name-to-name indirection for address queries while allowing other resource record types to exist at the same owner name. It is therefore usable at a zone apex.¶
This document also defines authoritative processing, TTL and failure behavior, DNSSEC considerations, and interoperable transport of ANAME records in full and incremental zone transfers. In particular, each ANAME-capable authoritative server resolves the transferred target independently. This avoids treating transient, synthesized address records as the portable source of zone data.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker are available at https://github.com/querygraph/rgbdns/tree/master/ietf.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [CLOUDFLARE-FLATTENING]. DNSimple describes its ALIAS as a dynamic A/AAAA lookup performed by its authoritative service [DNSIMPLE-ALIAS]. Amazon Route 53 alias records can be placed at an apex but are restricted to selected AWS resources and records [ROUTE53-ALIAS]. IBM NS1 documents an authoritative ALIAS pseudo-record that is not included in outgoing zone transfers [NS1-ALIAS]. PowerDNS can either transfer its private ALIAS representation or expand it to addresses, with explicit warnings about refresh and serial-number behavior [POWERDNS-ALIAS].¶
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 [I-D.ietf-dnsop-aname]. 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses DNS terminology from [RFC9499].¶
ANAME has RR TYPE value TBD1. Its mnemonic is
ANAME.¶
The presentation format is:¶
owner.example. 300 IN ANAME target.example.net.¶
The RDATA consists of exactly one domain name, the ANAME target. Its wire encoding is the DNS name wire format from [RFC1035]. Name compression MUST NOT be used within ANAME RDATA, consistent with [RFC3597]. Relative names in a master file are resolved by the master-file parser in the same manner as CNAME targets.¶
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 [RFC4592] before flattening. Implementations that cannot preserve those rules MUST reject wildcard ANAME configuration.¶
An ANAME-capable authoritative server performs the following procedure independently for A and AAAA:¶
The resulting owner and RDATA form the synthesized address RRset. An implementation MUST NOT combine addresses obtained from different generations of a target RRset.¶
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.¶
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 [RFC8767]. 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.¶
For an A or AAAA query at an ANAME owner, an authoritative server MUST answer from the synthesized address RRset produced by Section 5. 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.¶
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.¶
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.¶
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.¶
In an AXFR response conforming to [RFC5936], 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 [RFC3597] permits transfer and storage by software that does not yet understand its semantics.¶
A native secondary MUST store the received ANAME RR and perform Section 5 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.¶
IXFR [RFC1995] 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.¶
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 [RFC6891],
with code TBD2 for AXFR and IXFR requests.¶
The option is encoded as follows:¶
+----------------------+----------------------+
| OPTION-CODE = TBD2 | OPTION-LENGTH = 0 |
+----------------------+----------------------+
16 bits 16 bits
¶
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.¶
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 [RFC1996] 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.¶
ANAME does not change AXFR authorization requirements. Zone transfers commonly disclose the complete namespace and SHOULD be restricted and authenticated using TSIG [RFC8945], SIG(0), mutually authenticated transport, or an equivalent mechanism. ANAME-CAPABLE is not an authentication mechanism.¶
The operator configures the following authoritative data:¶
example. 3600 IN SOA ns1.example. hostmaster.example. (
2026073001 3600 900 1209600 300 )
example. 3600 IN NS ns1.example.
example. 3600 IN NS ns2.example.
example. 300 IN ANAME service.example.net.
example. 3600 IN MX 10 mail.example.
¶
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.¶
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.¶
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.¶
This section uses the DNSSEC protocol and terminology defined by [RFC4033], [RFC4034], and [RFC4035].¶
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.¶
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 [RFC7871] and account for the resulting cache variance and privacy exposure.¶
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.¶
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 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 |
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 Section 7.1. 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 [POWERDNS-ALIAS]. 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.¶
This section is to be removed before publishing as an RFC.¶
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.¶