DNSIND Working Group Matt Crawford
Internet Draft Fermilab
July 24, 1998
Non-Terminal DNS Name Redirection
<draft-ietf-dnsind-dname-01.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), ftp.ietf.org (US East
Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Distribution of this memo is unlimited.
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
Expires January 29, 1999 Crawford [Page 1]
Internet Draft Non-Terminal Nicknames July 24, 1998
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 TBA (decimal).
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. Two limiting
rules govern the use of DNAMEs.
Rule One
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.
Rule Two
When resolving a query, it is valid to encounter more than one
DNAME record along the way ONLY IF every DNAME record encountered
has fewer labels in its <target> than in its <owner>. (Note that
in the bit-string label [BITLBL], each bit is a separate label.)
If a single DNAME is encountered this document places no new
restriction on the number of labels in its <target>.
Rule One 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. This rule,
together with the rules for DNS zone authority [DNSCLR] imply that
DNAME and NS records can only coexist at the top of a zone which has
only one node.
Rule Two prevents DNAME loops. It MUST be enforced by servers
during recursive query processing and by resolvers.
Expires January 29, 1999 Crawford [Page 2]
Internet Draft Non-Terminal Nicknames July 24, 1998
4. Query Processing
To exploit the DNAME mechanism the name resolution algorithms
[DNSCF] must be modified slightly for both servers and resolvers.
In both cases a conceptual per-query variable DFLAG is introduced to
enforce Rule Two. Implementations MAY use other means to enforce
the rule. DFLAG's value is
0 when processing of a query begins and whenever no DNAME has been
encountered;
1 when one or more DNAME records have been encountered, and each
had fewer labels in its <target> than in its <owner>;
2 when a DNAME record has been encountered which had at least as
many labels in its <target> as in its <owner>.
Both modified algorithms incorporate the operation of making a
substitution on a name (either QNAME or SNAME) under control of a
DNAME record. For conciseness, this operation is elaborated here
and will be referred to as "Procedure S".
S1. If DFLAG = 2, Rule Two is violated. Go to step S4.
S2. If DFLAG = 1 and the DNAME record's <target> does not have fewer
labels than its <owner>, Rule Two is violated. Go to step S4.
S3. If substituting the DNAME's <target> for its <owner> in the name
being operated on would overflow the legal size for a <domain-
name>, go to step S4. Otherwise make the substitution.
If the <target> has fewer labels than the <owner>, set DFLAG to
1, otherwise set DFLAG to 2. Return.
S4. In a resolver, return an implementation-dependent error to the
application. In a server, copy the DNAME record to the answer
section, set RCODE to YXDOMAIN [DNSUPD], and exit.
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 the cache.
DNS clients sending Extended DNS [EDNS] queries with Version 0 or
greater are presumed to understand the semantics of the DNAME
Expires January 29, 1999 Crawford [Page 3]
Internet Draft Non-Terminal Nicknames July 24, 1998
record. The sender of a non-extended query may not understand
DNAME, 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 synthesized CNAME RR, if
provided, MUST have
The same CLASS as the QCLASS of the query,
TTL equal to zero,
An <owner> equal to the QNAME in effect at the moment the DNAME
RR was encountered, and
An RDATA field containing the new QNAME formed by the action of
Procedure S.
If the server has the appropriate key on-line [DNSSEC, SECDYN], it
MAY generate and return a SIG RR for the synthesized CNAME RR.
The revised server algorithm is:
1. Set or clear the value of recursion available in the response
depending on whether the name server is willing to provide
recursive service. If recursive service is available and
requested via the RD bit in the query, go to step 5, otherwise
step 2.
2. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 3,
otherwise step 4.
3. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME
RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the answer
section and go to step 6.
b. If a match would take us out of the authoritative data, we
have a referral. This happens when we encounter a node with
NS RRs marking cuts along the bottom of a zone.
Expires January 29, 1999 Crawford [Page 4]
Internet Draft Non-Terminal Nicknames July 24, 1998
Copy the NS RRs for the subzone into the authority section
of the reply. Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data or the cache. Go to step
4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a DNAME record.
If a DNAME record exists at that point, copy that record
into the answer section, substitute its <target> for its
<owner> in QNAME according to Procedure S. If the query was
not extended [EDNS], the server SHOULD synthesize a CNAME
record as described above and include it in the answer
section. Go back to step 1.
If there was no DNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME. If the name is original,
set an authoritative name error in the response and exit.
Otherwise just exit.
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
set the owner of the RR to be QNAME, and not the node with
the "*" label. Go to step 6.
4. Start matching down in the cache. If QNAME is found in the
cache, copy all RRs attached to it that match QTYPE into the
answer section. If QNAME is not found in the cache but a DNAME
record is present at an ancestor of QNAME, copy that DNAME
record into the answer section. If there was no delegation from
authoritative data, look for the best one from the cache, and
put it in the authority section. Go to step 6.
5. Using the local resolver or a copy of its algorithm (see
resolver section of this memo) to answer the query. Store the
results, including any intermediate CNAMEs and DNAMEs, in the
answer section of the response.
6. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query. Exit.
Note that there will be at most one ancestor with a DNAME as
Expires January 29, 1999 Crawford [Page 5]
Internet Draft Non-Terminal Nicknames July 24, 1998
described in step 4 unless some zone's data is in violation of Rule
One.
4.2. Processing by Resolvers
A resolver or a server providing recursive service must be modified
to treat a DNAME as somewhat analogous to a CNAME. The resolver
algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
as 4.e and insert a new 4.d. The complete algorithm becomes:
1. See if the answer is in local information, and if so return it
to the client.
2. Find the best servers to ask.
3. Send them queries until one returns a response.
4. Analyze the response, either:
a. if the response answers the question or contains a name
error, cache the data as well as returning it back to the
client.
b. if the response contains a better delegation to other
servers, cache the delegation information, and go to step 2.
c. if the response shows a CNAME and that is not the answer
itself, cache the CNAME, change the SNAME to the canonical
name in the CNAME RR and go to step 1.
d. if the response shows a DNAME the DNAME, substitute the
DNAME's <target> for its <owner> in the SNAME according to
Procedure S and go to step 1.
e. if the response shows a server failure or other bizarre
contents, delete the server from the SLIST and go back to
step 3.
A resolver or recursive server which understands DNAME records but
sends non-extended queries MUST augment step 4.c by deleting from
the reply any CNAME records which have an <owner> which is a
subdomain of the <owner> of any DNAME record in the response.
Expires January 29, 1999 Crawford [Page 6]
Internet Draft Non-Terminal Nicknames July 24, 1998
5. Examples of Use
If an organization with domain name FROBOZZ.EXAMPLE became part of
an organization with domain name ACME.EXAMPLE, it might ease
transition by placing information such as this in its old zone.
frobozz.example. DNAME frobozz-division.acme.example.
MX mailhub.acme.example.
The response to an extended recursive query for www.frobozz.example
would contain, in the answer section, the DNAME record shown above
and the relevant RRs for www.frobozz-division.acme.example.
If IPv4 network renumbering were common, maintenance of address
space delegation could be simplified by using DNAME records instead
of NS records to delegate.
$ORIGIN new-style.in-addr.arpa.
189.190 DNAME in-addr.example.net.
$ORIGIN in-addr.example.net.
188 DNAME in-addr.customer.xy.
$ORIGIN in-addr.customer.xy.
1 PTR www.customer.xy.
2 PTR mailhub.customer.xy.
; etc ...
This would allow the address space assigned to the ISP "example.net"
to be changed without the necessity of altering the zone files
describing the use of that space by the ISP and its customers.
6. References
[BITLBL] M. Crawford, "Binary Labels in the Domain Name System",
currently draft-ietf-dnsind-binary-labels-02.txt.
[DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities",
RFC 1034.
[DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification",
RFC 2181.
[DNSIS] P.V. Mockapetris, "Domain names - implementation and
specification", RFC 1035.
[DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security
Expires January 29, 1999 Crawford [Page 7]
Internet Draft Non-Terminal Nicknames July 24, 1998
Extensions", RFC 2065.
[DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System", RFC 2136.
[EDNS] P. Vixie, "Extensions to DNS (EDNS)", Currently draft-
dnsind-edns-02.txt.
[KWORD] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[SECDYN]D. Eastlake, 3rd, "Secure Domain Name System Dynamic
Update", RFC 2137.
7. Author's Address
Matt Crawford
Fermilab MS 368
PO Box 500
Batavia, IL 60510
USA
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Expires January 29, 1999 Crawford [Page 8]
