DNAME Redirection in the DNS
obsoletes
- rfc-2672 — Non-Terminal DNS Name Redirection
updates
- rfc-3363 — Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
Extracted elements (26)
DNAME was originally conceived to solve the problem of maintaining address-to-name mappings during network renumbering. With careful setup, a renumbering event does not require changes to the authoritative server holding address-to-name mappings. A secondary use is aliasing entire name spaces, such as providing punycode alternates.
The DNAME owner name itself is not redirected — only subordinate names are. This differs from CNAME, which redirects the owner name itself. This allows a zone apex to have a DNAME while retaining its SOA and NS records, though it cannot be used to completely mirror a zone.
The EDNS version signaling for DNAME target name compression described in RFC 2672 was never actually specified and is explicitly removed in this revision. There is no EDNS version signaling for DNAME, and the target name MUST always be sent uncompressed.
Target names of MX, NS, PTR, and SRV records must be canonical hostnames — no CNAME or DNAME redirection may be present during address record lookup for these names. DNAME-redirected names cannot appear in MX, NS, SRV, or PTR RDATA.
This document updates RFC 3363 by dropping all constraints on having DNAME RRs in the IPv6 reverse tree. RFC 3363 had deprecated DNAME use in the reverse tree based on a faulty premise tied to A6 records; that deprecation is now reversed.
DNAME RRs MUST NOT appear at the same owner name as an NS RR unless the owner name is the zone apex. At a non-apex owner, an NS RR signifies a delegation point.
If a dynamic update attempts to add a DNAME where a CNAME already exists at that owner name, the server MUST ignore the DNAME. If a CNAME is added where a DNAME already exists, the CNAME MUST be ignored.
If a recursive caching name server encounters a DNSSEC-validated DNAME RR that contradicts cached information, it SHOULD cache the DNAME RR. If the DNAME RR cannot be DNSSEC-validated, the server SHOULD NOT cache the DNAME RR.
If the DNAME substitution would overflow the legal size for a domain name (255 octets), the server MUST set RCODE to YXDOMAIN and include the DNAME record and its signature in the answer.
Recursive caching name servers MUST perform CNAME synthesis on behalf of clients.
Resource records MUST NOT exist at any subdomain of the owner of a DNAME RR. A server MAY refuse to load a zone that has data at a subdomain of a DNAME RR owner.
Servers MUST be able to answer a query for a synthesized CNAME. Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a value equal to the TTL of the corresponding DNAME record.
The DNAME RDATA target name MUST NOT be sent out in compressed form and MUST be downcased for DNSSEC validation.
When a DNAME is employed as a substitution instruction, a CNAME RR with TTL equal to the corresponding DNAME RR MUST be synthesized and included in the answer section. The synthesized CNAME owner name is the QNAME of the query.
Wildcard DNAME records of the form '*.example.com DNAME example.net' SHOULD NOT be used because the interaction between wildcard expansion and DNAME redirection is non-deterministic, preventing DNSSEC validation.
DNAME is a singleton type: only one DNAME is allowed per owner name, and no CNAME RRs can exist at the same owner name. This ensures a single unambiguous redirection per domain name.
DNAME substitution replaces the suffix labels of the queried name matching the DNAME owner name with the DNAME target. Only whole labels are replaced. If substitution would produce a name exceeding 255 octets, the server returns RCODE YXDOMAIN.
In DNSSEC, a signed DNAME RR indicates non-terminal redirection. Any server-synthesized CNAME accompanying a DNAME will never itself be signed. A DNSSEC validator verifies the DNAME RR signature and confirms the CNAME was properly synthesized rather than requiring a separate CNAME signature.
In DNSSEC negative responses, the NSEC or NSEC3 type bitmap SHOULD be checked for the DNAME bit. If the DNAME bit is set and the query name is a subdomain of the closest encloser, DNAME substitution should have been performed; its absence indicates a bogus response.
The DNAME resource record has mnemonic DNAME and type code 39 (decimal). It is CLASS-insensitive. Its RDATA consists of a single field, <target>, which is a fully qualified domain name that provides subtree-level DNS redirection.
IANA updated the DNS Resource Record (RR) Types registry entry for type code 39 (decimal), previously registered by RFC 2672, to point to this document (RFC 6672).
DNAME redirects queries to potentially different security zones. The lowest security status of any link in a CNAME/DNAME chain determines the security status of the final result. Wildcarded DNAMEs create additional security issues because the synthesized CNAME has no signature and the server's intended result may differ from what the resolver computes.
DNSSEC validators MUST understand DNAME because an attacker can collate existing DNS records to forge a bogus NXDOMAIN response. Without understanding the DNAME bit in the NSEC type bitmap, a validator cannot distinguish a valid name error from a spoofed one.
The resolver algorithm: (1) check local information or cached DNAME for a synthesizable answer; (2) find best servers; (3) send queries; (4) analyze response — handle answers, delegations, CNAME chains, or DNAME substitutions; (5) handle errors by removing servers from SLIST.
The server algorithm defines a multi-step resolution process: (1) set recursion available, (2) search zones for nearest ancestor to QNAME, (3) match labels in zone triggering DNAME substitution and CNAME synthesis if a DNAME is encountered, (4) search cache including ancestor DNAME records, (5) use recursive resolution if requested, (6) add additional RRs.
The DNAME RDATA target field MUST be sent in uncompressed form and MUST be downcased for DNSSEC validation. The presentation format is: <owner> <ttl> <class> DNAME <target>.