diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2672.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2672.txt | 507 |
1 files changed, 0 insertions, 507 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2672.txt b/contrib/bind9/doc/rfc/rfc2672.txt deleted file mode 100644 index 11030168dcd0..000000000000 --- a/contrib/bind9/doc/rfc/rfc2672.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -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] - |