RFC2672 日本語訳

Network Working Group                                        M. Crawford
Request for Comments: 2672                                      Fermilab
Category: Standards Track                                    August 1999

Network Working Group M. Crawford Request for Comments: 2672 Fermilab Category: Standards Track August 1999

                   Non-Terminal DNS Name Redirection

Non-Terminal DNS Name Redirection

Status of this Memo

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.

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 Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright (C) The Internet Society (1999). All Rights Reserved.

1.  Introduction

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.

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].

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

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.

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

3. The DNAME Resource Record

   The DNAME RR has mnemonic DNAME and type code 39 (decimal).

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

Crawford Standards Track [Page 1]  RFC 2672 Non-Terminal DNS Name Redirection August 1999

   DNAME has the following format:

DNAME has the following format:

      <owner> <ttl> <class> DNAME <target>

<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 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 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:

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.

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.

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.

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.

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

4. Query Processing

   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
   must be modified slightly for both servers and resolvers.

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".

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

Crawford Standards Track [Page 2]  RFC 2672 Non-Terminal DNS Name Redirection August 1999

4.1.  Processing by Servers

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.

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.

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 synthesized CNAME RR, if provided, MUST have

      The same CLASS as the QCLASS of the query,

The same CLASS as the QCLASS of the query,

      TTL equal to zero,

TTL equal to zero,

      An <owner> equal to the QNAME in effect at the moment the DNAME RR
      was encountered, and

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.

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.

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:

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.

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.

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:

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

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.

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.

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.

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.

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.

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.

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 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 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 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.

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

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.

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.

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.

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.

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

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:

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.

1. See if the answer is in local information, and if so return it to the client.

   2. Find the best servers to ask.

2. Find the best servers to ask.

   3. Send them queries until one returns a response.

3. Send them queries until one returns a response.

   4. Analyze the response, either:

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.

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.

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.

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

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.

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.

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.

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. Examples of Use

5.1.  Organizational Renaming

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.

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.

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.

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

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.

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

$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

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

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.

$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].

The same advisory remarks concerning the choice of the "/" character apply here as in [INADDR].

5.3.  Network Renumbering Support

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.

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 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.example.net. 188 DNAME in-addr.customer.example.

      $ORIGIN in-addr.customer.example.
      1                 PTR      www.customer.example.
      2                 PTR      mailhub.customer.example.
      ; etc ...

$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.

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.

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

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.

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

Crawford Standards Track [Page 7]  RFC 2672 Non-Terminal DNS Name Redirection August 1999

7.  Security Considerations

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.

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

8. References

   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.

9.  Author's Address

9. Author's Address

   Matt Crawford
   Fermilab MS 368
   PO Box 500
   Batavia, IL 60510
   USA

Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA

   Phone: +1 630 840-3461
   EMail: crawdad@fnal.gov

Phone: +1 630 840-3461 EMail: crawdad@fnal.gov

Crawford                    Standards Track                     [Page 8]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999

Crawford Standards Track [Page 8]  RFC 2672 Non-Terminal DNS Name Redirection August 1999

10.  Full Copyright Statement

10. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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.

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.

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.

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

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Funding for the RFC Editor function is currently provided by the Internet Society.

Crawford                    Standards Track                     [Page 9]

Crawford Standards Track [Page 9]