503 lines
17 KiB
Plaintext
503 lines
17 KiB
Plaintext
|
||
DNSIND Working Group Matt Crawford
|
||
Internet Draft Fermilab
|
||
March 21, 1999
|
||
|
||
Non-Terminal DNS Name Redirection
|
||
<draft-ietf-dnsind-dname-03.txt>
|
||
|
||
|
||
|
||
Status of this Memo
|
||
|
||
This document is an Internet-Draft and is in full conformance with
|
||
all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents
|
||
at any time. It is inappropriate to use Internet- Drafts as
|
||
reference material or to cite them other than as "work in progress."
|
||
|
||
To view the list Internet-Draft Shadow Directories, see
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 1]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
3. The DNAME Resource Record
|
||
|
||
The DNAME RR has mnemonic DNAME and type code 39 (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. 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
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 2]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
substitution on a name (either QNAME or SNAME) under control of a
|
||
DNAME record. This operation will be referred to as "the DNAME
|
||
substitution".
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 3]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
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.
|
||
|
||
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
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 4]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
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. 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.
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 5]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
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 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 6]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
|
||
$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
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 7]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
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.
|
||
|
||
|
||
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] 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
|
||
Extensions", RFC 2065.
|
||
|
||
[DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
|
||
Updates in the Domain Name System", RFC 2136.
|
||
|
||
[EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently
|
||
draft-dnsind-edns0-01.txt.
|
||
|
||
[INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA
|
||
delegation", RFC 2317.
|
||
|
||
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels," RFC 2119.
|
||
|
||
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
|
||
Update", RFC 2137.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 8]
|
||
|
||
Internet Draft Non-Terminal Nicknames March 21, 1999
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Expires September 26, 1999 Crawford [Page 9]
|
||
|