Browse Prior Art Database

Non-Terminal DNS Name Redirection (RFC2672)

IP.com Disclosure Number: IPCOM000003263D
Original Publication Date: 1999-Aug-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Crawford: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 16% of the total text.

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",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

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).

DNAME has the following format:

DNAME

The format is not class-sensitive. All fields are required. The

RDATA field is a [DNSIS].

The DNAME RR causes type NS additional section processing.

The effect of the DNAME record is the substitution of the record's

for its 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...