Non-Terminal DNS Name Redirection
Extracted elements (19)
Classless delegation of prefixes shorter than 24 bits in in-addr.arpa (RFC 2317) can be extended using DNAME records, allowing a /22 prefix to be delegated with four DNAME entries mapping each /24 subdomain into the delegated zone.
DNAME was conceived as a solution to maintaining address-to-name mappings during network renumbering: without DNAME, an authoritative server for reverse mappings must be reconfigured on renumbering, but with DNAME the zone needs no modification.
The synthesized CNAME TTL is set to zero so it is not cached by non-DNAME-aware clients, preventing stale synthetic CNAMEs from persisting after the underlying DNAME changes.
DNAME and NS records can only coexist at the top of a zone that has only one node, as implied by the no-descendants rule combined with DNS zone authority rules from RFC 2181.
DNS clients sending EDNS0 queries with Version 0 or non-extended queries are presumed not to understand DNAME semantics; servers SHOULD synthesize CNAME records for such clients. Behavior under EDNS versions greater than 0 is deferred to future specification.
A resolver or recursive server that understands DNAME records but sends non-extended queries MUST augment resolver step 4.c by deleting from the reply any CNAME records whose owner is a subdomain of the owner of any DNAME record in the response.
A server answering a non-extended DNS query (EDNS0 Version 0 or no EDNS) SHOULD synthesize a CNAME record for each DNAME record encountered during query processing to help the client reach the correct DNS data.
If a DNAME RR is present at a node N, there MUST be no data at any descendant of N (of the same class). Other data may exist at N itself, except a CNAME or another DNAME.
If substitution of the DNAME's <target> for its <owner> in QNAME would overflow the legal size for a <domain-name>, the server MUST set RCODE to YXDOMAIN and exit.
Resolvers, including resolvers embedded in DNS servers, MUST limit the resources they devote to any query, to guard against naming loops created with DNAME or DNAME/CNAME combinations.
The DNS name compression scheme of RFC 1035 MUST NOT be applied to the RDATA portion of a DNAME record unless the sending server has some way of knowing that the receiver understands the DNAME record format.
The no-descendants restriction MUST be enforced when authoritative zone data is loaded, ensuring predictable results when a DNAME record is cached by a non-authoritative server.
The synthesized CNAME RR MUST have the same CLASS as QCLASS, TTL equal to zero, owner equal to the QNAME at the moment the DNAME was encountered, and RDATA containing the new QNAME formed by the DNAME substitution.
The DNAME RR has mnemonic DNAME and type code 39 (decimal). Its RDATA field contains a single <domain-name> (the target), is not class-sensitive, and all fields are required.
The DNAME substitution operation replaces the record's <owner> with its <target> as a suffix of a domain name (QNAME or SNAME), effectively redirecting an entire subtree of the DNS name space to another domain.
This document registers DNS Resource Record type DNAME with mnemonic DNAME and type code 39 (decimal) in the IANA DNS RR type registry defined by RFC 1035.
The DNAME record is similar to CNAME with regard to the consequences of inserting a spoofed record into a DNS server or resolver, but DNAME's effect covers an entire subtree of the name space rather than a single node. DNSSEC facilities are available to authenticate this record type.
The modified resolver algorithm inserts step 4.d: if the response shows a DNAME that is not the answer itself, cache the DNAME, perform the substitution of <target> for <owner> in SNAME (or return error on overflow), and go to step 1.
The revised server algorithm defines six steps: (1) check recursion availability; (2) find nearest ancestor zone; (3) match labels in zone data, handling CNAME, NS cuts, and DNAME substitution; (4) search cache for QNAME or ancestor DNAME; (5) use recursive resolution; (6) add additional section data.