RFC2317 日本語訳

Network Working Group                                         H. Eidnes
Request for Comments: 2317                                 SINTEF RUNIT
BCP: 20                                                     G. de Groot
Category: Best Current Practice          Berkeley Software Design, Inc.
                                                               P. Vixie
                                           Internet Software Consortium
                                                             March 1998

Eidnesがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2317SINTEF RUNIT BCP: 20 G.deグルートCategory: 1998年の最も良い現在の練習のP.Vixieインターネットソフトウェア共同体バークレイ・ソフトウェア・デザインのInc.行進

                   Classless IN-ADDR.ARPA delegation

階級のないIN-ADDR.ARPA代表団

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(1998)。 All rights reserved。

2. Introduction

2. 序論

   This document describes a way to do IN-ADDR.ARPA delegation on non-
   octet boundaries for address spaces covering fewer than 256
   addresses.  The proposed method should thus remove one of the
   objections to subnet on non-octet boundaries but perhaps more
   significantly, make it possible to assign IP address space in smaller
   chunks than 24-bit prefixes, without losing the ability to delegate
   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
   method is fully compatible with the original DNS lookup mechanisms
   specified in [1], i.e. there is no need to modify the lookup
   algorithm used, and there should be no need to modify any software
   which does DNS lookups.

このドキュメントはアドレス空間のために256未満のアドレスをカバーしながら非八重奏の境界でIN-ADDR.ARPA代表団をする方法を述べます。 その結果、提案された方法は非八重奏境界で反論の1つをサブネットに移すべきですが、24ビットの接頭語より小さい塊におけるIPアドレス空間を割り当てるのを可能に恐らくさらにかなり、してください、対応するIN-ADDR.ARPAマッピングのために権限を委ねる能力を失わないで。 提案された方法は[1]で指定されるオリジナルのDNSルックアップメカニズムと完全に互換性があります、そして、すなわち、使用されるルックアップアルゴリズムを変更する必要は全くありません、そして、DNSにルックアップをするどんなソフトウェアも変更する必要は全くあるべきではありません。

   The document also discusses some operational considerations to
   provide some guidance in implementing this method.

また、ドキュメントは、この方法を実行するのに何らかの指導を提供するためにいくつかの操作上の問題について議論します。

3. Motivation

3. 動機

   With the proliferation of classless routing technology, it has become
   feasible to assign address space on non-octet boundaries.  In case of
   a very small organization with only a few hosts, assigning a full
   24-bit prefix (what was traditionally referred to as a "class C
   network number") often leads to inefficient address space
   utilization.

階級のないルーティング技術の増殖によると、非八重奏境界のアドレス空間を割り当てるのは可能になりました。 ほんの数人のホストとの非常に小さい組織の場合には、完全な24ビットの接頭語(「クラスCネットワーク・ナンバー」と伝統的に呼ばれたこと)を割り当てるのはしばしば効率の悪いアドレス空間利用に通じます。

Eidnes, et. al.          Best Current Practice                  [Page 1]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[1ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   One of the problems encountered when assigning a longer prefix (less
   address space) is that it seems impossible for such an organization
   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
   use of the reverse delegation method described below, the most
   important objection to assignment of longer prefixes to unrelated
   organizations can be removed.

より長い接頭語(より少ないアドレス空間)を割り当てるとき行きあたられる問題の1つはそのような組織が自主的にそれ自身の逆(「ADDR.ARPA」の)のゾーンを維持するように不可能に思えるということです。 以下で説明された逆の代表団方法の使用で、関係ない組織への、より長い接頭語の課題への最も重要な異論を取り除くことができます。

   Let us assume we have assigned the address spaces to three different
   parties as follows:

私たちが以下の3回の異なったパーティーにアドレス空間を配属したと仮定しましょう:

           192.0.2.0/25   to organization A
           192.0.2.128/26 to organization B
           192.0.2.192/26 to organization C

組織Cへの組織A192.0.2組織B192.0.2 26対.192/26への.128/192.0.2.0/25

   In the classical approach, this would lead to a single zone like
   this:

古典派的接近法では、これはこのようなただ一つのゾーンに通じるでしょう:

   $ORIGIN 2.0.192.in-addr.arpa.
   ;
   1               PTR     host1.A.domain.
   2               PTR     host2.A.domain.
   3               PTR     host3.A.domain.
   ;
   129             PTR     host1.B.domain.
   130             PTR     host2.B.domain.
   131             PTR     host3.B.domain.
   ;
   193             PTR     host1.C.domain.
   194             PTR     host2.C.domain.
   195             PTR     host3.C.domain.

$起源2.0.192.in-addr.arpa。 ; 1つのPTR host1.A.ドメイン。 2PTR host2.A.ドメイン。 3PTR host3.A.ドメイン。 ; 129PTR host1.B.ドメイン。 130PTR host2.B.ドメイン。 131PTR host3.B.ドメイン。 ; 193PTR host1.C.ドメイン。 194PTR host2.C.ドメイン。 195PTR host3.C.ドメイン。

   The administration of this zone is problematic.  Authority for this
   zone can only be delegated once, and this usually translates into
   "this zone can only be administered by one organization."  The other
   organizations with address space that corresponds to entries in this
   zone would thus have to depend on another organization for their
   address to name translation.  With the proposed method, this
   potential problem can be avoided.

このゾーンの管理は問題が多いです。 一度このゾーンへの権威を代表として派遣することができるだけです、そして、通常、これは「1つの組織がこのゾーンを管理できるだけであること」に翻訳されます。 その結果、それらのアドレスが翻訳を命名するように、このゾーンでのエントリーに対応するアドレス空間がある他の組織は別の組織に頼らなければならないでしょう。 提案された方法で、この潜在的な問題を避けることができます。

4. Classless IN-ADDR.ARPA delegation

4. 階級のないIN-ADDR.ARPA代表団

   Since a single zone can only be delegated once, we need more points
   to do delegation on to solve the problem above.  These extra points
   of delegation can be introduced by extending the IN-ADDR.ARPA tree
   downwards, e.g. by using the first address or the first address and
   the network mask length (as shown below) in the corresponding address

一度ただ一つのゾーンを代表として派遣することができるだけであるので、私たちは上の問題を解決するためにオンな代表団をするために、より多くのポイントを必要とします。 下向きにIN-ADDR.ARPA木を広げることによって、代表団のこれらのエキストラポイントを導入できます、例えば、対応するアドレスで最初のアドレスか最初のアドレスとネットワークマスクの長さ(以下に示すように)を使用することによって

Eidnes, et. al.          Best Current Practice                  [Page 2]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[2ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   space to form the the first component in the name for the zones.  The
   following four zone files show how the problem in the motivation
   section could be solved using this method.

名前における最初のコンポーネントをゾーンに形成するスペース。 以下の4個のゾーンファイルがこの方法を使用することでどう動機部の問題を解決できるだろうかを示しています。

   $ORIGIN 2.0.192.in-addr.arpa.
   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
   ;...
   ;  <<0-127>> /25
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.
   ;
   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
   ;
   ;  <<128-191>> /26
   128/26          NS      ns.B.domain.
   128/26          NS      some.other.name.server.too.
   ;
   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
   ;
   ;  <<192-255>> /26
   192/26          NS      ns.C.domain.
   192/26          NS      some.other.third.name.server.
   ;
   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
   195             CNAME   195.192/26.2.0.192.in-addr.arpa.

$起源2.0.192.in-addr.arpa。 @IN SOA、私、-、ns.my.domain. hostmaster.my.domain。 (...) ;... ; 0/25ナノ秒の<<0-127>>/25ns.A.ドメイン。 0/25NS some.other.name.server。 1 CNAME 1.0/25.2.0.192.in-addr.arpa。 2 CNAME 2.0/25.2.0.192.in-addr.arpa。 3 CNAME 3.0/25.2.0.192.in-addr.arpa。 ; ; 128/26ナノ秒の<<128-191>>/26ns.B.ドメイン。 128/26NS some.other.name.server.too。 ; 129 CNAME 129.128/26.2.0.192.in-addr.arpa。 130 CNAME 130.128/26.2.0.192.in-addr.arpa。 131 CNAME 131.128/26.2.0.192.in-addr.arpa。 ; ; 192/26ナノ秒の<<192-255>>/26ns.C.ドメイン。 192/26NS some.other3番目の.name.server。 193 CNAME 193.192/26.2.0.192.in-addr.arpa。 194 CNAME 194.192/26.2.0.192.in-addr.arpa。 195 CNAME 195.192/26.2.0.192.in-addr.arpa。

   $ORIGIN 0/25.2.0.192.in-addr.arpa.
   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
   @               NS      ns.A.domain.
   @               NS      some.other.name.server.
   ;
   1               PTR     host1.A.domain.
   2               PTR     host2.A.domain.
   3               PTR     host3.A.domain.

$起源0/25.2.0.192.in-addr.arpa。 @SOA ns.A.ドメインhostmaster.A.ドメインで。 (...) @ナノ秒、ns.A.ドメイン。 @NS some.other.name.server。 1つのPTR host1.A.ドメイン。 2PTR host2.A.ドメイン。 3PTR host3.A.ドメイン。

Eidnes, et. al.          Best Current Practice                  [Page 3]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[3ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   $ORIGIN 128/26.2.0.192.in-addr.arpa.
   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
   @               NS      ns.B.domain.
   @               NS      some.other.name.server.too.
   ;
   129             PTR     host1.B.domain.
   130             PTR     host2.B.domain.
   131             PTR     host3.B.domain.

$起源128/26.2.0.192.in-addr.arpa。 @SOA ns.B.ドメインhostmaster.B.ドメインで。 (...) @ナノ秒、ns.B.ドメイン。 @NS some.other.name.server.too。 ; 129PTR host1.B.ドメイン。 130PTR host2.B.ドメイン。 131PTR host3.B.ドメイン。

   $ORIGIN 192/26.2.0.192.in-addr.arpa.
   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
   @               NS      ns.C.domain.
   @               NS      some.other.third.name.server.
   ;
   193             PTR     host1.C.domain.
   194             PTR     host2.C.domain.
   195             PTR     host3.C.domain.

$起源192/26.2.0.192.in-addr.arpa。 @SOA ns.C.ドメインhostmaster.C.ドメインで。 (...) @ナノ秒、ns.C.ドメイン。 @NS some.other3番目の.name.server。 193PTR host1.C.ドメイン。 194PTR host2.C.ドメイン。 195PTR host3.C.ドメイン。

   For each size-256 chunk split up using this method, there is a need
   to install close to 256 CNAME records in the parent zone.  Some
   people might view this as ugly; we will not argue that particular
   point.  It is however quite easy to automatically generate the CNAME
   resource records in the parent zone once and for all, if the way the
   address space is partitioned is known.

この方法を使用する分けられたそれぞれのサイズ-256塊のために、およそ256のCNAME記録を親ゾーンにインストールする必要があります。 何人かの人々が、これが醜いとみなすかもしれません。 私たちはその特定のポイントについて論争するつもりではありません。 たやすく、CNAMEリソースを自動的に発生させるのは親ゾーンにきっぱり記録します、アドレス空間が仕切られる方法が知られているならどんなにかなりそれがそうであるか。

   The advantage of this approach over the other proposed approaches for
   dealing with this problem is that there should be no need to modify
   any already-deployed software.  In particular, the lookup mechanism
   in the DNS does not have to be modified to accommodate this splitting
   of the responsibility for the IPv4 address to name translation on
   "non-dot" boundaries.  Furthermore, this technique has been in use
   for several years in many installations, apparently with no ill
   effects.

この問題に対処するための他の提案されたアプローチの上のこのアプローチの利点はどんな既に配備されたソフトウェアも変更する必要は全くあるべきでないということです。 特に、DNSのルックアップメカニズムは、IPv4アドレスが「非ドット」境界に関する翻訳を命名する責任のこの分かれることを収容するように変更される必要はありません。 その上、このテクニックは数年間多くのインストールと、明らかな害なしで使用中です。

   As usual, a resource record like

通常通りであって、aリソース記録同様です。

   $ORIGIN 2.0.192.in-addr.arpa.
   129             CNAME   129.128/26.2.0.192.in-addr.arpa.

$起源2.0.192.in-addr.arpa。 129 CNAME 129.128/26.2.0.192.in-addr.arpa。

   can be convienently abbreviated to

convienentlyに、簡略化できます。

   $ORIGIN 2.0.192.in-addr.arpa.
   129             CNAME   129.128/26

$起源2.0.192.in-addr.arpa。 129 CNAME129.128/26

Eidnes, et. al.          Best Current Practice                  [Page 4]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[4ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   Some DNS implementations are not kind to special characters in domain
   names, e.g. the "/" used in the above examples.  As [3] makes clear,
   these are legal, though some might feel unsightly.  Because these are
   not host names the restriction of [2] does not apply.  Modern clients
   and servers have an option to act in the liberal and correct fashion.

「いくつかのDNS実現が例えばドメイン名における特殊文字に親切でない、」 /、」 上記の例では、使用されています。 [3]が明らかにするように、或るものは見苦しく感じられるかもしれませんが、これらは法的です。 これらがホスト名でないので、[2]の制限は適用されません。 現代のクライアントとサーバには、寛容で正しいファッションで行動するオプションがあります。

   The examples here use "/" because it was felt to be more visible and
   pedantic reviewers felt that the 'these are not hostnames' argument
   needed to be repeated.  We advise you not to be so pedantic, and to
   not precisely copy the above examples, e.g.  substitute a more
   conservative character, such as hyphen, for "/".

それが、より目に見えて衒学的な評論家であると感じられたので、「ここの例は」 /を使用すること」が、'これらはホスト名ではありません'という議論が、繰り返される必要だったと感じました。 「私たちは、あなたがそれほど訳知り顔でなく、また正確に上記の例をコピーしないようにアドバイスして、例えば、代用品は、より保守的な性格です、ハイフンなどのように、」 /のために。」

5. Operational considerations

5. 操作上の問題

   This technique is intended to be used for delegating address spaces
   covering fewer than 256 addresses.  For delegations covering larger
   blocks of addresses the traditional methods (multiple delegations)
   can be used instead.

256未満のアドレスをカバーするアドレス空間を代表として派遣するのにこのテクニックが使用されることを意図します。 より大きいブロックのアドレスをカバーする代表団のために、代わりに、伝統的方法(複数の代表団)を使用できます。

5.1 Recommended secondary name service

5.1 お勧めの二次名前サービス

   Some older versions of name server software will make no effort to
   find and return the pointed-to name in CNAME records if the pointed-
   to name is not already known locally as cached or as authoritative
   data.  This can cause some confusion in resolvers, as only the CNAME
   record will be returned in the response.  To avoid this problem it is
   recommended that the authoritative name servers for the delegating
   zone (the zone containing all the CNAME records) all run as slave
   (secondary) name servers for the "child" zones delegated and pointed
   into via the CNAME records.

ネームサーバソフトウェアのいくつかの旧式のバージョンは先鋭な名前が既に局所的に知られていないならキャッシュにされるとして、または、信頼すべきデータとしてCNAMEの示している名前を見つけて、返すための努力を全く記録にしないでしょう。 応答でCNAME記録だけを返すとき、これはレゾルバでの何らかの混乱を引き起こす場合があります。 この問題を避けるために、代表として派遣するゾーン(すべてのCNAME記録を含むゾーン)への正式のネームサーバがゾーンがCNAME記録で代表として派遣して、指した「子供」のための奴隷(二次)ネームサーバとしてすべて走るのは、お勧めです。

5.2 Alternative naming conventions

5.2 代替の命名規則

   As a result of this method, the location of the zone containing the
   actual PTR records is no longer predefined.  This gives flexibility
   and some examples will be presented here.

この方法の結果、実際のPTR記録を含むゾーンの位置はもう事前に定義されません。 これは柔軟性を与えます、そして、いくつかの例がここに提示されるでしょう。

   An alternative to using the first address, or the first address and
   the network mask length in the corresponding address space, to name
   the new zones is to use some other (non-numeric) name.  Thus it is
   also possible to point to an entirely different part of the DNS tree
   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
   use one of these alternate methods if two organizations somehow
   shared the same physical subnet (and corresponding IP address space)
   with no "neat" alignment of the addresses, but still wanted to
   administrate their own IN-ADDR.ARPA mappings.

対応するアドレス空間に最初のアドレスか、最初のアドレスとネットワークマスクの長さを使用することへの代替手段、新しいゾーンを命名するのは、ある他の(非数値)の名前を使用することです。 したがって、また、DNS木の完全に異なった部分を示すのも(すなわち、IN-ADDR.ARPA木の外)可能です。 2つの組織が「きちんとした」整列なしで同じ物理的なサブネット(そして、対応するIPアドレス空間)をどうにか、共有したならアドレスについてこれらの代替方法の1つを使用しますが、それら自身のIN-ADDR.ARPAマッピングを管理して欲しくて、まだ使用しているのが必要でしょう。

Eidnes, et. al.          Best Current Practice                  [Page 5]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[5ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   The following short example shows how you can point out of the IN-
   ADDR.ARPA tree:

以下の短い例はあなたがIN ADDR.ARPA木からどう指すことができるかを示しています:

   $ORIGIN 2.0.192.in-addr.arpa.
   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
   ; ...
   1               CNAME   1.A.domain.
   2               CNAME   2.A.domain.
   ; ...
   129             CNAME   129.B.domain.
   130             CNAME   130.B.domain.
   ;

$起源2.0.192.in-addr.arpa。 @IN SOA、私、-、ns.my.domain. hostmaster.my.domain。 (...) ; ... 1つのCNAME 1.A.ドメイン。 2CNAME 2.A.ドメイン。 ; ... 129CNAME 129.B.ドメイン。 130CNAME 130.B.ドメイン。 ;

   $ORIGIN A.domain.
   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
   ; ...
   ;
   host1           A       192.0.2.1
   1               PTR     host1
   ;
   host2           A       192.0.2.2
   2               PTR     host2
   ;

$起源A.ドメイン。 SOAの@、私、-、ns.A.ドメイン. hostmaster.A.ドメイン。 (...) ; ... ; host1A192.0.2.1 1PTR host1。 host2A192.0.2.2 2PTR host2。

   etc.

など

   This way you can actually end up with the name->address and the
   (pointed-to) address->name mapping data in the same zone file - some
   may view this as an added bonus as no separate set of secondaries for
   the reverse zone is required.  Do however note that the traversal via
   the IN-ADDR.ARPA tree will still be done, so the CNAME records
   inserted there need to point in the right direction for this to work.

あなたが実際に同じゾーンファイルのデータを写像する>を命名しているアドレスと(示します)の>を記述している名前で終わることができるこの方法--逆のゾーンへの代理人のどんな別々のセットも必要でないように或るものが加えられたボーナスであるとこれをみなすかもしれません。 してください、そして、そこに挿入されたCNAME記録が、働くのに正しい方向にこれのために指す必要があるように、しかしながら、それでも、IN-ADDR.ARPA木を通して縦断することに注意してください。

   Sketched below is an alternative approach using the same solution:

以下にスケッチされているのは、同じ解決策を使用する代替的アプローチです:

   $ORIGIN 2.0.192.in-addr.arpa.
   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
   ; ...
   1                  CNAME   1.2.0.192.in-addr.A.domain.
   2                  CNAME   2.2.0.192.in-addr.A.domain.

$起源2.0.192.in-addr.arpa。 @SOA、私、-、ns.my.domain. hostmaster.my.domain。 (...) ; ... 1つのCNAME 1.2.0.192.in-addr.A.ドメイン。 2CNAME 2.2.0.192.in-addr.A.ドメイン。

   $ORIGIN A.domain.
   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
   ; ...
   ;
   host1              A       192.0.2.1
   1.2.0.192.in-addr  PTR     host1

$起源A.ドメイン。 @SOA、私、-、ns.A.ドメイン. hostmaster.A.ドメイン。 (...) ; ... ; host1A192.0.2.1 1.2.0.192.in-addr PTR host1

Eidnes, et. al.          Best Current Practice                  [Page 6]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[6ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   host2              A       192.0.2.2
   2.2.0.192.in-addr  PTR     host2

host2A192.0.2.2 2.2.0.192.in-addr PTR host2

   It is clear that many possibilities exist which can be adapted to the
   specific requirements of the situation at hand.

手元の状況に関する決められた一定の要求にどれを適合させることができるかは多くの可能性が存在するのが明確です。

5.3 Other operational issues

5.3 他の操作上の問題

   Note that one cannot provide CNAME referrals twice for the same
   address space, i.e. you cannot allocate a /25 prefix to one
   organisation, and run IN-ADDR.ARPA this way, and then have the
   organisation subnet the /25 into longer prefixes, and attempt to
   employ the same technique to give each subnet control of its own
   number space. This would result in a CNAME record pointing to a CNAME
   record, which may be less robust overall.

1つが同じアドレス空間のために二度紹介をCNAMEに供給できないで、この方向に1つの機構への25接頭語を/に割り当てて、IN-ADDR.ARPAを動かして、次に、より長いことへの/25が前に置く機構サブネットを持つことができないことに注意してください、そして、それ自身の数のスペースのそれぞれのサブネット支配力を与えるのに同じテクニックを使うのを試みてください。 これは全体的に見てそれほど強健でないかもしれないCNAME記録を示すCNAME記録をもたらすでしょう。

   Unfortunately, some old beta releases of the popular DNS name server
   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
   record was encountered when a reverse lookup was made.  The beta
   releases involved have since been obsoleted, and this issue is
   resolved in the released code.  Some software manufacturers have
   included the defective beta code in their product. In the few cases
   we know of, patches from the manufacturers are available or planned
   to replace the obsolete beta code involved.

残念ながらポピュラーなDNSネームサーバ実現BINDのいくつかの古いベータリリース、4.9、.3、逆のルックアップが作られたとき、CNAME記録が遭遇したなら問題を起こしたバグを持っていました。 かかわったベータリリースは以来時代遅れにされています、そして、この問題はリリースされたコードで解決されています。 彼らの製品で欠陥があるベータコードを入れたソフトウェア製造業者もありました。 私たちが知っているわずかな場合では、メーカーからのパッチは、利用可能であり、コードがかかわった時代遅れのベータを置き換えるために計画されています。

6. Security Considerations

6. セキュリティ問題

   With this scheme, the "leaf sites" will need to rely on one more site
   running their DNS name service correctly than they would be if they
   had a /24 allocation of their own, and this may add an extra
   component which will need to work for reliable name resolution.

この計画で、彼らにそれら自身の/24配分があったなら、「葉のサイト」は、彼らであるだろうより彼らのDNS名前サービスを正しく走らせるもうひとつのサイトを当てにする必要があって、これは信頼できる名前解決のために働く必要がある余分なコンポーネントを言い足すかもしれません。

   Other than that, the authors are not aware of any additional security
   issues introduced by this mechanism.

それ以外に、作者はこのメカニズムによって紹介されたどんな追加担保問題も意識していません。

7. Conclusion

7. 結論

   The suggested scheme gives more flexibility in delegating authority
   in the IN-ADDR.ARPA domain, thus making it possible to assign address
   space more efficiently without losing the ability to delegate the DNS
   authority over the corresponding address to name mappings.

提案された計画はIN-ADDR.ARPAドメインで権限を委ねる際に、より多くの柔軟性を与えます、その結果、より効率的にマッピングを命名する対応するアドレスの上のDNS権威を代表として派遣する能力を失わないでアドレス空間を割り当てるのを可能にします。

8. Acknowledgments

8. 承認

   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
   valuable comments on the newsgroup.

谷間A.Herrmannsfeldtは先頃comp.protocols.tcp ip.domainsでこのトリックを説明しました。 アラン・バーレットとサム・ウィルソンはニュースグループの貴重なコメントを提供しました。

Eidnes, et. al.          Best Current Practice                  [Page 7]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[7ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
   and Peter Koch for their review and constructive comments.

彼らのレビューと建設的なコメントについてロブAustein、ランディ・ブッシュ、マット・クロフォード、ロバートElz、Glen A.Herrmannsfeldt、ダニエルKarrenberg、デヴィッドKessens、トニー・李、ポールMockapetris、エリックWassenaar、マイケル・パットン、ハンス・モウラー、およびピーター・コッホに感謝申し上げます。

9. References

9. 参照

   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
        STD 13, RFC 1034, November 1987.

[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
        Table Specification", RFC 952, October 1985.

[2]HarrenstienとK.とスタール、M.とE.Feinler、「DoDインターネットホストテーブル仕様」、RFC952、1985年10月。

   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
        Specification", RFC 2181, July 1997.

1997年7月の[3] Elz、R.とR.ブッシュ、「DNS仕様への明確化」RFC2181。

Eidnes, et. al.          Best Current Practice                  [Page 8]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[8ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

10. Authors' Addresses

10. 作者のアドレス

   Havard Eidnes
   SINTEF RUNIT
   N-7034 Trondheim
   Norway

Havard Eidnes SINTEF RUNIT N-7034トロンヘイムノルウェー

   Phone: +47 73 59 44 68
   Fax: +47 73 59 17 00
   EMail: Havard.Eidnes@runit.sintef.no

以下に電話をしてください。 +47 73 59 44 68、Fax: +47 73 59 17 00はメールされます: Havard.Eidnes@runit.sintef.no

   Geert Jan de Groot
   Berkeley Software Design, Inc. (BSDI)
   Hendrik Staetslaan 69
   5622 HM Eindhoven
   The Netherlands

ヘールト1月のdeグルートバークレイ・ソフトウェア・デザインInc.(BSDI)Hendrik Staetslaan69 5622HMアイントホーフェンオランダ

   Phone: +31 40 2960509
   Fax:   +31 40 2960309
   EMail: GeertJan.deGroot@bsdi.com

以下に電話をしてください。 +31 40 2960509、Fax: +31 40 2960309はメールされます: GeertJan.deGroot@bsdi.com

   Paul Vixie
   Internet Software Consortium
   Star Route Box 159A
   Woodside, CA 94062
   USA

カリフォルニア94062米国のポールVixieインターネットソフトウェア共同体星のルート箱の159Aウッドサイド

   Phone: +1 415 747 0204
   EMail: paul@vix.com

以下に電話をしてください。 +1 0204年の415 747メール: paul@vix.com

Eidnes, et. al.          Best Current Practice                  [Page 9]

RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998

et Eidnes、アル。 最も良いCurrent Practice[9ページ]RFC2317Classless IN-ADDR.ARPA代表団行進1998

11.  Full Copyright Statement

11. 完全な著作権宣言文

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

Copyright(C)インターネット協会(1998)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Eidnes, et. al.          Best Current Practice                 [Page 10]

et Eidnes、アル。 最も良い現在の習慣[10ページ]