Lonely Hackers Club (LHC) B. Plankton
Request for Comments: ???? LHC DNS Division
Category: Standards Track vn
Obsoletes: Common Sense LHC DNS Division
Updates: RFC 1035 (emotionally) February 26, 2026
The IPv6-Specific Canonical Name Record (CNAAAAME)
Abstract
This document defines a new DNS resource record (RR) type, the CNAAAAME record (type code 42069), which provides a canonical name alias specifically for IPv6 address (AAAA) lookups. While the existing CNAME record type has historically supported both IPv4 and IPv6, the lack of protocol-specific naming conventions in the canonical space has led to “address family ambiguity” that can only be resolved by adding more letters to the record name.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Lonely Hackers Club (LHC). It represents the consensus of the LHC community. It has received public review and has been approved for publication by the LHC Engineering Steering Group (LHCSG).
Documents approved for publication by the LHCSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.cnaaaame.com.
Copyright Notice
Copyright (c) 2026 Lonely Hackers Club and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the LHC’s Legal Provisions Relating to LHC Documents in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions regarding this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . 2
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The CNAAAAME Resource Record . . . . . . . . . . . . . . . 3
3.1. CNAAAAME RDATA Wire Format . . . . . . . . . . . . . 4
3.2. TYPE Value . . . . . . . . . . . . . . . . . . . . . 4
3.3. Comparison with CNAME . . . . . . . . . . . . . . . 4
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . 5
4.1. Resolver Behavior . . . . . . . . . . . . . . . . . 5
4.2. Authoritative Server Behavior . . . . . . . . . . . 5
4.3. Coexistence with CNAME . . . . . . . . . . . . . . . 5
5. Master File Format . . . . . . . . . . . . . . . . . . . . 6
6. Backward Compatibility . . . . . . . . . . . . . . . . . . 6
7. Operational Considerations . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . 7
10. Future Work . . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The Domain Name System (DNS) [RFC1035] has long relied on the CNAME record to map one domain name to another. However, the CNAME record is entirely agnostic to the underlying address family. As the industry moves toward an IPv6-only future, maintaining a single record type that simultaneously points to both A and AAAA records is increasingly viewed as “insufficiently specific.”
To ensure that IPv6 packets feel “at home” throughout the entire resolution process, this memo proposes the CNAAAAME record. The extra “AAAA” in the middle of the name ensures that resolvers, administrators, and the packets themselves are aware that an IPv6-first mentality has been applied to the aliasing logic.
The name “CNAAAAME” is derived from the concatenation of “CN” + “AAAA” + “ME”, reflecting the deep union of the CNAME concept with the AAAA address family. Administrators who pronounce it aloud during configuration are advised to do so with appropriate gravitas.
1.1. Terminology
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.
The key phrase “SHOULD FEEL BAD ABOUT” is not defined in BCP 14 but is used in this document to indicate a moral, rather than technical, obligation upon the implementor.
2. Motivation
During a review of the DNS type ecosystem, the authors observed the following asymmetry:
Record Letters in Name Address Family Specificity
------ ---------------- ---------------------------
A 1 IPv4 only
AAAA 4 IPv6 only
CNAME 5 Address-family agnostic
CNAAAAME 8 IPv6 only (proposed)
The CNAME record, with five letters, carries no indication of its address family affiliation. This is a crisis of identity that has persisted for a while. In an era where even HTTP headers convey preferred color schemes, the DNS remains woefully behind in expressing protocol-level feelings.
The authors further note that the ratio of ‘A’ characters in “AAAA” to the ‘A’ characters in “CNAME” is 4:0 (undefined, as division by zero is involved for the CNAME numerator when considering only consecutive ‘A’ characters). This mathematical impossibility alone justifies the creation of a new record type.
3. The CNAAAAME Resource Record
The CNAAAAME (Canonical AAAA Name) RR specifies that a domain name is an alias for another domain name, but only when the querier is specifically interested in IPv6.
The CNAAAAME RR has the mnemonic “CNAAAAME” and type code 42069.
3.1. CNAAAAME RDATA Wire Format
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAAAAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAAAAME A <domain-name> which specifies the canonical or
primary name for the owner. The name is an alias.
The owner is also emotionally committed to IPv6.
The RDATA for a CNAAAAME record is identical in wire format to that of a standard CNAME record [RFC1035]. The only difference is the spiritual weight of the extra four characters in the RR type name. Implementations MUST NOT attempt to compress this spiritual weight.
3.2. TYPE Value
CNAAAAME uses the DNS RR type code 42069. This value was selected because:
(a) it was available in the “Unassigned” range, and
(b) the authors are a little immature.
3.3. Comparison with CNAME
For clarity, the distinction between CNAME and CNAAAAME is presented below:
Property CNAME CNAAAAME
-------- ----- --------
Wire format <domain-name> <domain-name>
Semantics Alias Alias (but IPv6)
Letters 5 8
'A' characters 1 4 (consecutive)
Emotional resonance Neutral IPv6-positive
Suitability for Yes In a perfect world
production use
4. Protocol Operation
4.1. Resolver Behavior
When a resolver receives a query for an AAAA record and finds a CNAAAAME record instead, it MUST follow the alias to the canonical name, in exactly the same manner as for a CNAME.
If a resolver receives a query for an A record and encounters a CNAAAAME record, it SHOULD ignore the CNAAAAME record entirely. The resolver SHOULD FEEL BAD ABOUT the fact that IPv4 is still in use, but MUST NOT drop the query. The domain owner clearly did not intend for IPv4 users to follow this specific canonical path, and the resolver should respect this boundary.
If a resolver receives a query for any other record type and encounters a CNAAAAME record, the resolver MAY follow it, but only after confirming that doing so does not undermine the IPv6-specific nature of the alias. The exact mechanism for this confirmation is left to the implementor.
4.2. Authoritative Server Behavior
An authoritative name server which hosts a zone containing a CNAAAAME record MUST serve it in response to queries with QTYPE=CNAAAAME or QTYPE=* (ANY).
The server SHOULD NOT serve the CNAAAAME record in response to QTYPE=CNAME queries. Serving a CNAAAAME when a CNAME was requested would be semantically misleading, as the querier has not demonstrated sufficient commitment to IPv6.
4.3. Coexistence with CNAME
A domain name MAY have both a CNAME and a CNAAAAME record. In such cases, the resolver MUST enter a state of deep existential contemplation before selecting the appropriate record. The CNAAAAME record takes precedence for AAAA queries, thereby honoring the administrator’s explicit intention to differentiate canonical aliasing by address family.
If a domain name has a CNAAAAME record but no corresponding CNAME record, the administrator is making a clear political statement about the future of networking. Resolvers MUST respect this position regardless of their own views on the matter.
Note that [RFC1034], Section 3.6.2 states that a CNAME RR should be the “only” RR at a node. This document updates that guidance to note that CNAAAAME records are exempt from this rule, on the grounds that they are spiritually distinct.
5. Master File Format
In master files [RFC1035], the CNAAAAME record follows the same syntax as CNAME:
; Zone file for example.com
$ORIGIN example.com.
$TTL 86400
@ IN SOA ns1 hostmaster (
2026022601 ; Serial
7200 ; Refresh
3600 ; Retry
1209600 ; Expire
86400 ) ; Minimum TTL
@ IN NS ns1
@ IN NS ns2
ns1 IN A 192.0.2.1
ns1 IN AAAA 2001:db8::1
ns2 IN A 192.0.2.2
ns2 IN AAAA 2001:db8::2
; Standard alias - address-family agnostic, morally ambiguous
www IN CNAME webserver.example.com.
; IPv6-aware alias - righteous and forward-looking
www IN CNAAAAME webserver.example.com.
; The above combination ensures that IPv6 users feel seen.
Zone file parsers that do not recognize the CNAAAAME type SHOULD emit a warning message that is both technically accurate and mildly condescending, such as “Unknown type CNAAAAME at line 19; consider upgrading your software to a version that respects IPv6.”
6. Backward Compatibility
Legacy resolvers that do not implement CNAAAAME will treat the record as an unknown RR type, per [RFC3597]. This is acceptable behavior, though such resolvers SHOULD FEEL BAD ABOUT their lack of IPv6 solidarity.
Resolvers compliant with this specification MUST NOT publicly mock legacy resolvers. Private disappointment is acceptable.
DNS monitoring tools, log parsers, and zone validators that encounter the CNAAAAME type for the first time may assume it is a typographical error. Authors of such tools are encouraged to add special-case handling that detects CNAAAAME and responds with a reassuring message, e.g., “This is not a typo. See RFC ????.”
7. Operational Considerations
Operators deploying CNAAAAME records should be aware of the following:
(a) CNAAAAME records will increase the average character count of zone files. Capacity planning for disk and memory usage should account for an additional three bytes per record compared to CNAME.
(b) The CNAAAAME record is RECOMMENDED for use in zones where the administrator has strong opinions about IPv6. It is NOT RECOMMENDED for zones managed by administrators who are ambivalent about address families.
(c) Misconfiguration of CNAAAAME records may result in situations where IPv6 queries follow a different alias chain than IPv4 queries for the same domain name. While this is technically a feature of the proposal, it may cause confusion among operators who expect DNS to behave consistently regardless of query type. Such operators are encouraged to reflect on whether consistency is truly a virtue or merely a crutch.
(d) CNAAAAME chains (a CNAAAAME pointing to a name that itself has a CNAAAAME) MUST be followed iteratively, up to the limit specified in [RFC1035] for CNAME chains. Each hop in the chain is an opportunity for the resolver to reaffirm its commitment to IPv6.
8. Security Considerations
The introduction of CNAAAAME increases the DNS amplification attack surface by exactly three bytes per record type name in the wire format. Security practitioners are advised to update their regex filters accordingly. The regular expression C(N(A{0,4}))+ME may prove useful, though matching it correctly is left as an exercise for the reader.
As with CNAME, CNAAAAME records may be used in alias chains that redirect queries to unexpected destinations. However, because the CNAAAAME record is IPv6-specific, such attacks will only succeed against parties who have adopted IPv6 — a demographic that, the authors note, has already demonstrated a willingness to endure suffering.
Furthermore, there is a risk that legacy systems will perceive the “AAAA” within “CNAAAAME” as a typographical error. This is a feature, not a bug, as it encourages the immediate retirement of non-compliant hardware. Administrators MAY include a TXT record alongside each CNAAAAME record reading “This is intentional. Please update your parser.” to mitigate helpdesk ticket volume.
DNSSEC [RFC4033] validation of CNAAAAME records follows the same procedures as for CNAME records. The RRSIG for a CNAAAAME RRset provides cryptographic assurance not only that the record has not been tampered with, but also that the zone administrator’s preference for IPv6 is authentic and has not been forged by a man-in-the-middle with inferior address-family loyalties.
9. IANA Considerations
IANA is requested to assign the following entry in the “Resource Record (RR) TYPEs” registry:
Type Value Meaning Reference
------ ------ -------- ---------
CNAAAAME 42069 IPv6-Specific Canonical Name RFC ????
If the value 42069 is unavailable, the authors request the next available value in the “Highly Specific and Somewhat Redundant” sub-registry, which IANA is also requested to create.
The “Highly Specific and Somewhat Redundant” sub-registry SHALL use the “Specification Required” registration policy as defined in [RFC8126]. The designated expert is expected to verify that any proposed record type is at least as unnecessary as CNAAAAME before approving registration.
10. Future Work
The CNAAAAME record is a vital first step toward a future where every component of the DNS type system is annotated with its preferred address family. Subsequent documents in this series are anticipated to define:
Type Meaning
---- -------
SOAAAA Start of authority for IPv6-forward zones
CAAAAA Constraining acceptable CAs for a host/domain
The authors note that the logical end state of this work is a DNS in which every record type exists in both an A-variant and an AAAA-variant, effectively doubling the size of the type registry. This is considered a benefit, as it will provide employment for DNS implementors for decades to come.
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., “Domain names - concepts and facilities”, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.
[RFC1035] Mockapetris, P., “Domain names - implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, “DNS Extensions to Support IP Version 6”, STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
11.2. Informative References
[RFC3597] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types”, RFC 3597, DOI 10.17487/RFC3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, DOI 10.17487/RFC4033, March 2005.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.
Acknowledgments
The authors wish to thank the following individuals for their contributions, real or imagined:
- The inventor of the AAAA record, whose four-letter masterpiece inspired this work.
- The letter ‘A’, without which none of this would have been possible.
Authors' Addresses
B. Plankton LHC DNS Division Localhost, ::1/128 vn LHC DNS Division Multicast, ff00::