Non-Terminal DNS Name Redirection
RFC 2672

Document Type RFC - Proposed Standard (August 1999; No errata)
Obsoleted by RFC 6672
Updated by RFC 4592, RFC 6604
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2672 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        M. Crawford
Request for Comments: 2672                                      Fermilab
Category: Standards Track                                    August 1999

                   Non-Terminal DNS Name Redirection

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  Introduction

   This document defines a new DNS Resource Record called "DNAME", which
   provides the capability to map an entire subtree of the DNS name
   space to another domain.  It differs from the CNAME record which maps
   a single node of the name space.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [KWORD].

2.  Motivation

   This Resource Record and its processing rules were conceived as a
   solution to the problem of maintaining address-to-name mappings in a
   context of network renumbering.  Without the DNAME mechanism, an
   authoritative DNS server for the address-to-name mappings of some
   network must be reconfigured when that network is renumbered.  With
   DNAME, the zone can be constructed so that it needs no modification
   when renumbered.  DNAME can also be useful in other situations, such
   as when an organizational unit is renamed.

3. The DNAME Resource Record

   The DNAME RR has mnemonic DNAME and type code 39 (decimal).

Crawford                    Standards Track                     [Page 1]
RFC 2672           Non-Terminal DNS Name Redirection         August 1999

   DNAME has the following format:

      <owner> <ttl> <class> DNAME <target>

   The format is not class-sensitive.  All fields are required.  The
   RDATA field <target> is a <domain-name> [DNSIS].

   The DNAME RR causes type NS additional section processing.

   The effect of the DNAME record is the substitution of the record's
   <target> for its <owner> as a suffix of a domain name.  A "no-
   descendants" limitation governs the use of DNAMEs in a zone file:

      If a DNAME RR is present at a node N, there may be other data at N
      (except a CNAME or another DNAME), but there MUST be no data at
      any descendant of N.  This restriction applies only to records of
      the same class as the DNAME record.

   This rule assures predictable results when a DNAME record is cached
   by a server which is not authoritative for the record's zone.  It
   MUST be enforced when authoritative zone data is loaded.  Together
   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
   and NS records can only coexist at the top of a zone which has only
   one node.

   The compression scheme of [DNSIS] 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.
   Signalling such understanding is expected to be the subject of future
   DNS Extensions.

   Naming loops can be created with DNAME records or a combination of
   DNAME and CNAME records, just as they can with CNAME records alone.
   Resolvers, including resolvers embedded in DNS servers, MUST limit
   the resources they devote to any query.  Implementors should note,
   however, that fairly lengthy chains of DNAME records may be valid.

4.  Query Processing

   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
   must be modified slightly for both servers and resolvers.

   Both modified algorithms incorporate the operation of making a
   substitution on a name (either QNAME or SNAME) under control of a
   DNAME record.  This operation will be referred to as "the DNAME

Crawford                    Standards Track                     [Page 2]
RFC 2672           Non-Terminal DNS Name Redirection         August 1999

4.1.  Processing by Servers

   For a server performing non-recursive service steps 3.c and 4 of
   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
   checking for a wildcard ("*") label, and to return certain DNAME
   records from zone data and the cache.

   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
   non-extended queries are presumed not to understand the semantics of
   the DNAME record, so a server which implements this specification,
   when answering a non-extended query, SHOULD synthesize a CNAME record
   for each DNAME record encountered during query processing to help the
   client reach the correct DNS data.  The behavior of clients and
Show full document text