As per Relevance of the word standards, we have this rfc below:
Network Working Group M.
Request for Comments: 2672
Category: Standards Track August 1999
Non-Terminal DNS Name
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
This document defines a new DNS Resource Record called "DNAME",
provides the capability to map an entire subtree of the DNS
space to another domain. It differs from the CNAME record which
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
document are to be interpreted as described in [KWORD].
2.
This Resource Record and its processing rules were conceived as
solution to the problem of maintaining address-to-name mappings in
context of network renumbering. Without the DNAME mechanism,
authoritative DNS server for the address-to-name mappings of
network must be reconfigured when that network is renumbered.
DNAME, the zone can be constructed so that it needs no
when renumbered. DNAME can also be useful in other situations,
as when an organizational unit is renamed
3. The DNAME Resource
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
DNAME
The format is not class-sensitive. All fields are required.
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'
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
(except a CNAME or another DNAME), but there MUST be no data
any descendant of N. This restriction applies only to records
the same class as the DNAME record
This rule assures predictable results when a DNAME record is
by a server which is not authoritative for the record's zone.
MUST be enforced when authoritative zone data is loaded.
with the rules for DNS zone authority [DNSCLR] it implies that
and NS records can only coexist at the top of a zone which has
one node
The compression scheme of [DNSIS] MUST NOT be applied to the
portion of a DNAME record unless the sending server has some way
knowing that the receiver understands the DNAME record format
Signalling such understanding is expected to be the subject of
DNS Extensions
Naming loops can be created with DNAME records or a combination
DNAME and CNAME records, just as they can with CNAME records alone
Resolvers, including resolvers embedded in DNS servers, MUST
the resources they devote to any query. Implementors should note
however, that fairly lengthy chains of DNAME records may be valid
4. Query
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
substitution on a name (either QNAME or SNAME) under control of
DNAME record. This operation will be referred to as "the
substitution".
Crawford Standards Track [Page 2]
RFC 2672 Non-Terminal DNS Name Redirection August 1999
4.1. Processing by
For a server performing non-recursive service steps 3.c and 4
section 4.3.2 [DNSCF] are changed to check for a DNAME record
checking for a wildcard ("*") label, and to return certain
records from zone data and the cache
DNS clients sending Extended DNS [EDNS0] queries with Version 0
non-extended queries are presumed not to understand the semantics
the DNAME record, so a server which implements this specification
when answering a non-extended query, SHOULD synthesize a CNAME
for each DNAME record encountered during query processing to help
client reach the correct DNS data. The behavior of clients
servers under Extended DNS versions greater than 0 will be
when those versions are defined
The synthesized CNAME RR, if provided, MUST
The same CLASS as the QCLASS of the query
TTL equal to zero
An equal to the QNAME in effect at the moment the DNAME
was encountered,
An RDATA field containing the new QNAME formed by the action
the DNAME substitution
If the server has the appropriate key on-line [DNSSEC, SECDYN],
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
depending on whether the name server is willing to
recursive service. If recursive service is available
requested via the RD bit in the query, go to step 5,
step 2.
2. Search the available zones for the zone which is the
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
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
CNAME, copy the CNAME RR into the answer section of
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
section and go to step 6.
b. If a match would take us out of the authoritative data, we
a referral. This happens when we encounter a node with NS
marking cuts along the bottom of a zone
Copy the NS RRs for the subzone into the authority section
the reply. Put whatever addresses are available into
additional section, using glue RRs if the addresses are
available from authoritative data or the cache. Go to step 4.
c. If at some label, a match is impossible (i.e.,
corresponding label does not exist), look to see whether
last label matched has a DNAME record
If a DNAME record exists at that point, copy that record
the answer section. If substitution of its for
in QNAME would overflow the legal size for a
name>, set RCODE to YXDOMAIN [DNSUPD] and exit;
perform the substitution and continue. If the query was
extended [EDNS0] with a Version indicating understanding of
DNAME record, the server SHOULD synthesize a CNAME record
described above and include it in the answer section. Go
to step 1.
If there was no DNAME record, look to see if the "*"
exists
If the "*" label does not exist, check whether the name we
looking for is the original QNAME in the query or a name
have followed due to a CNAME. If the name is original, set
authoritative name error in the response and exit.
just exit
If the "*" label does exist, match RRs at that node
QTYPE. If any match, copy them into the answer section,
set the owner of the RR to be QNAME, and not the node with
"*" 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
section. If QNAME is not found in the cache but a DNAME record
present at an ancestor of QNAME, copy that DNAME record into
answer section. If there was no delegation from
data, look for the best one from the cache, and put it in
authority section. Go to step 6.
5. Use the local resolver or a copy of its algorithm (see
section of this memo) to answer the query. Store the results
including any intermediate CNAMEs and DNAMEs, in the
section of the response
6. Using local data only, attempt to add other RRs which may
useful to the additional section of the query. Exit
Note that there will be at most one ancestor with a DNAME
described in step 4 unless some zone's data is in violation of
no-descendants limitation in section 3. An implementation might
advantage of this limitation by stopping the search of step 3c
step 4 when a DNAME record is encountered
4.2. Processing by
A resolver or a server providing recursive service must be
to treat a DNAME as somewhat analogous to a CNAME. The
algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.
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
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
itself, cache the CNAME, change the SNAME to the canonical
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
itself, cache the DNAME. If substitution of the DNAME'
for its in the SNAME would overflow the
size for a , return an implementation-
error to the application; otherwise perform the
and go to step 1.
e. if the response shows a server failure or other
contents, delete the server from the SLIST and go back to
3.
A resolver or recursive server which understands DNAME records
sends non-extended queries MUST augment step 4.c by deleting from
reply any CNAME records which have an which is a subdomain
the of any DNAME record in the response
5. Examples of
5.1. Organizational
If an organization with domain name FROBOZZ.EXAMPLE became part of
organization with domain name ACME.EXAMPLE, it might ease
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.
would contain, in the answer section, the DNAME record shown
and the relevant RRs for www.frobozz-division.acme.example
5.2. Classless Delegation of Shorter
The classless scheme for in-addr.arpa delegation [INADDR] can
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
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
address 192.0.9.33 might
$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 "/"
apply here as in [INADDR].
5.3. Network Renumbering
If IPv4 network renumbering were common, maintenance of address
delegation could be simplified by using DNAME records instead of
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
"example.net" to be changed without the necessity of altering
zone files describing the use of that space by the ISP and
customers
Renumbering IPv4 networks is currently so arduous a task
updating the DNS is only a small part of the labor, so this
may have a low value. But it is hoped that in IPv6 the
task will be quite different and the DNAME mechanism may play
useful part
6. IANA
This document defines a new DNS Resource Record type with
mnemonic DNAME and type code 39 (decimal). The naming/
space is defined in [DNSIS]. This name and number have already
registered with the IANA
Crawford Standards Track [Page 7]
RFC 2672 Non-Terminal DNS Name Redirection August 1999
7. Security
The DNAME record is similar to the CNAME record with regard to
consequences of insertion of a spoofed record into a DNS server
resolver, differing in that the DNAME's effect covers a whole
of the name space. The facilities of [DNSSEC] are available
authenticate this record type
8.
[DNSCF] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[DNSCLR] Elz, R. and R. Bush, "Clarifications to the
Specification", RFC 2181, July 1997.
[DNSIS] Mockapetris, P., "Domain names - implementation
specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name
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,
1997.
[EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)",
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
Requirement Levels," BCP 14, RFC 2119, March 1997.
[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System
Update", RFC 2137, April 1997.
9. Author's
Matt
Fermilab MS 368
PO Box 500
Batavia, IL 60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.
Crawford Standards Track [Page 8]
RFC 2672 Non-Terminal DNS Name Redirection August 1999
10. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Crawford Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
