508 lines
18 KiB
Plaintext
508 lines
18 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
substitution".
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
servers under Extended DNS versions greater than 0 will be specified
|
||
when those versions are defined.
|
||
|
||
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
|
||
the DNAME substitution.
|
||
|
||
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:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 3]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
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.
|
||
|
||
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. If substitution of its <target> for its
|
||
<owner> in QNAME would overflow the legal size for a <domain-
|
||
name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
|
||
perform the substitution and continue. If the query was not
|
||
extended [EDNS0] with a Version indicating understanding of the
|
||
DNAME record, 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.
|
||
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 4]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
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. Use 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
|
||
described in step 4 unless some zone's data is in violation of the
|
||
no-descendants limitation in section 3. An implementation might take
|
||
advantage of this limitation by stopping the search of step 3c or
|
||
step 4 when a DNAME record is encountered.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 5]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
d. if the response shows a DNAME and that is not the answer
|
||
itself, cache the DNAME. If substitution of the DNAME's
|
||
<target> for its <owner> in the SNAME would overflow the legal
|
||
size for a <domain-name>, return an implementation-dependent
|
||
error to the application; otherwise perform the substitution
|
||
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.
|
||
|
||
5. Examples of Use
|
||
|
||
5.1. Organizational Renaming
|
||
|
||
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 10 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.
|
||
|
||
5.2. Classless Delegation of Shorter Prefixes
|
||
|
||
The classless scheme for in-addr.arpa delegation [INADDR] can be
|
||
extended to prefixes shorter than 24 bits by use of the DNAME record.
|
||
For example, the prefix 192.0.8.0/22 can be delegated by the
|
||
following records.
|
||
|
||
$ORIGIN 0.192.in-addr.arpa.
|
||
8/22 NS ns.slash-22-holder.example.
|
||
8 DNAME 8.8/22
|
||
9 DNAME 9.8/22
|
||
10 DNAME 10.8/22
|
||
11 DNAME 11.8/22
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 6]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
A typical entry in the resulting reverse zone for some host with
|
||
address 192.0.9.33 might be
|
||
|
||
$ORIGIN 8/22.0.192.in-addr.arpa.
|
||
33.9 PTR somehost.slash-22-holder.example.
|
||
|
||
The same advisory remarks concerning the choice of the "/" character
|
||
apply here as in [INADDR].
|
||
|
||
5.3. Network Renumbering Support
|
||
|
||
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.example.
|
||
|
||
$ORIGIN in-addr.customer.example.
|
||
1 PTR www.customer.example.
|
||
2 PTR mailhub.customer.example.
|
||
; etc ...
|
||
|
||
This would allow the address space 190.189.0.0/16 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.
|
||
|
||
Renumbering IPv4 networks is currently so arduous a task that
|
||
updating the DNS is only a small part of the labor, so this scheme
|
||
may have a low value. But it is hoped that in IPv6 the renumbering
|
||
task will be quite different and the DNAME mechanism may play a
|
||
useful part.
|
||
|
||
6. IANA Considerations
|
||
|
||
This document defines a new DNS Resource Record type with the
|
||
mnemonic DNAME and type code 39 (decimal). The naming/numbering
|
||
space is defined in [DNSIS]. This name and number have already been
|
||
registered with the IANA.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 7]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
7. Security Considerations
|
||
|
||
The DNAME record is similar to the CNAME record with regard to the
|
||
consequences of insertion of a spoofed record into a DNS server or
|
||
resolver, differing in that the DNAME's effect covers a whole subtree
|
||
of the name space. The facilities of [DNSSEC] are available to
|
||
authenticate this record type.
|
||
|
||
8. References
|
||
|
||
[DNSCF] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[DNSIS] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
|
||
Security Extensions", RFC 2065, January 1997.
|
||
|
||
[DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
|
||
"Dynamic Updates in the Domain Name System", RFC 2136, April
|
||
1997.
|
||
|
||
[EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
|
||
2671, August 1999.
|
||
|
||
[INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
|
||
ADDR.ARPA delegation", RFC 2317, March 1998.
|
||
|
||
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels," BCP 14, RFC 2119, March 1997.
|
||
|
||
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
|
||
Update", RFC 2137, April 1997.
|
||
|
||
9. Author's Address
|
||
|
||
Matt Crawford
|
||
Fermilab MS 368
|
||
PO Box 500
|
||
Batavia, IL 60510
|
||
USA
|
||
|
||
Phone: +1 630 840-3461
|
||
EMail: crawdad@fnal.gov
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 8]
|
||
|
||
RFC 2672 Non-Terminal DNS Name Redirection August 1999
|
||
|
||
|
||
10. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crawford Standards Track [Page 9]
|
||
|