注意。 これは、私の必要から訳したもので品質、正確さについては保証しません takawata@shidahra1.planet.kobe-u.ac.jp 原文は例えばftp://ftp.media.kyoto-u.ac.jp/pub/rfc/rfc2317.txt 等で手に入ります。コメントは大歓迎です。 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 クラス無しの場合のIN-ADDR.ARPAの権限委譲。 この文書の位置付け このドキュメントは現在のところの最良の解決をインターネットコミュニティーに 提供し、改良のための議論と示唆を求めるものである。この文書の配布は無制限 である。 著作権 Copyright (C) The Internet Society (1998). All Rights Reserved. 2.導入。 この文書は、カバーするアドレス空間が256アドレスよりも小さい、 オクテット境界にないアドレスのIN-ADDR.ARPAドメインの権限の委譲の 仕方を記述したものである。この提案された方法は、オクテット境界に ないアドレスを作る事への異義の一つを取り除くだけでなく、もっと 重要な事は、24ビットプレフィクスよりも小さいIPアドレスの塊の 宣言を、対応するIN-ADDR.ARPA引きの権限の委譲が可能なように 保ったままできるようにするものである。提案された方法は、参考文献[1]に 規定された元々のDNSの検索メカニズムと完全互換である。つまり現在使われている 検索アルゴリズムを変更する必要はなく、DNS検索を行うソフトウエアに変更を 加える必要はない筈である。 この文書では、また、いくつかの運用上の考察を、この方法を実装する上 での方針を提供するために議論している。 3.動機 クラスレスなルーティング技術が増えて来るにつれ、オクテット境界にない アドレスを宣言する事があり得るようになって来た。とても2,3のホストしか ない小さい組織の場合、完全な24ビットプレフィクス(伝統的にclass C ネットワーク番号として呼ばれたもの)を宣言するのはアドレス空間を 非効率に利用する事になってしまう。 アドレスプレフィクスを長くする(アドレス空間を小さくする)時遭遇する問題の 一つは自分自身の逆引きゾーン("IN-ADDR.ARPA")を自律的に管理する事が 不可能に見える事である。以下に示す逆引き権限委譲の方法を使えば、 関係のない組織に長いアドレスプレフィクスを宣言する事に対してのもっとも 重要な反対意見は取り除く事ができるだろう。 以下のように3つの違った団体にアドレス空間を振り分けているとする。 192.0.2.0/25 を 組織 A 192.0.2.128/26 を 組織 B 192.0.2.192/26 を 組織 C 古典的なアプローチでは、以下のように書かざるを得なかった筈である $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. このゾーンを管理するのは問題が多い。このゾーンの権限はひとまとめで 委譲しなければならず、これは大抵「このゾーンは一つの組織のみで 管理されなければならない」と言う言葉に言い替えられる。このゾーンに 対応するホストを持っているその他の組織は、したがって別の組織に 逆引きを頼らなければならない。これから提案する方法によれば この潜在的な問題を回避する事ができる。 4.クラスレスな、IN-ADDR.ARPAの委譲 一つのゾーンがただ一回だけ委譲されねばならないことから、上で述べた 問題を解決するには、もっと多くの(委譲の)ポイントが必要になる。これらの 委譲のポイントは例えば、始点のアドレスまたは始点のアドレスと ネットワークマスク長(以下に示すように)を対応するアドレス空間で、最初の ゾーン名を形作るのに使う事でIN-ADDR.ARPAの木構造を延ばす事によって 導入する事ができる。以下の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. $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. $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. $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. この方法を使って分割された、全ての256アドレスの塊についてびっしりと 256個のCNAMEレコードを親ゾーンにインストールしなければならない。 これをみっともないと言う人も居るかも知れないが、その点については 議論しない事にする。しかしながら、もし、どのようにアドレスが分割 されているか分かっていれば自動的にCNAME資源レコードを親ゾーンで一気に 全部に対して生成するのはたやすい事である。 他のこの逆引き問題の解決方に対してのこのアプローチの利点は既存のソフトウエア に何ら変更を加える必要がないことである。特にDNSを引くメカニズムはこの "点で区切られてない"境界のあるIPv4アドレスと名前の変換の権限が分かれている 状況を調停するために変更される必要がない。更にこの方法が何年かして、 多くのところで行われても、明らかに変な現象が起こったりする事はない。 普通は以下のような資源レコードは $ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 便宜のためこの様に省略され得る。 $ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26 いくつかのDNSの実装は以上の例での「/」のようなドメイン名の特殊な文字に 寛容でない。見苦しいと言う人がいるかも知れないが、参考文献[3]において 明確にこれらは正しいと言っている。ホスト名ではないので、参考文献[2]にある 制限は適用されない。最近のクライアントとサーバは寛容で正しい方法で振舞う オプションを持っている。 ここでの例で"/"を使ったのは、分かりやすくするためと衒学的な査読者が、 「これはホスト名ではない」という議論を繰り返す必要が無いようにするためで ある。あなたはこんな風に衒学的にならず、まったくこのまんまの例をコピー しないように、たとえば、"/"をハイフン等の保守的な文字に置き換えるように するなどをお勧めする。 5.運用上の考慮すべき点。 このテクニックは、256アドレス以下をカバーするアドレス空間を委譲する 時に使われる事を意図したものである。もっと大きなアドレス空間の場合は 今まで通りの方法(多重委譲)が使える。 5.1 セカンダリネームサーバに求められる事。 /*XXX*/ いくつかの旧いバージョンのネームサーバは、もし、指されていた名前が 既に権限のあるデータとしてキャッシュされていたら、探そうとせずに、 CNAMEレコードの指された名前を返してしまう。これは、CNAMEデータ のみを返されてしまうためレゾルバにいくらかの混乱を引き起こす。この問題を 解決するためには委譲したゾーンを持っている(全てのCNAMEレコードを持っている) ネームサーバは、委譲された"子"ゾーンのスレーブ(セカンダリ)ネームサーバ としても動いて、それをCNAMEレコードで指している必要がある。 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. 5.2 代替名付けの慣例。 この方法の結果、本当のPTRレコードを持っている場所はもはや先に決められた ものではない。このことは柔軟性を与える。いくつかの例をここで示そう。 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. 最初のアドレスを使うかわりに、また最初のアドレスと、ネットワークマスク 長を使う代わりに、新しいゾーン名をつける時に別の(数字でない)名前を つける。すると、DNSツリーの別の部分を指す事ができる(つまりIN-ADDR.ARPAツリー の外)。これは、２つの違った組織が同じ物理サブネット(とIPアドレス空間) を共有している場合、きっちりアドレスが(ビット)境界で 分かれてるわけではないが、自分自身のIN-ADDR.ARPAマッピングを管理したい という場合のの一つの解決として必要であろう。 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. 以下の短い例はどのようにして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. ; $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 ; etc. この方法を使えば、名前からアドレスとアドレスから名前の写像データを 同じゾーンファイルに書くことができる。このことを、逆引きゾーンへの セカンダリを別々に与えなくとも良いので変な風に見える。しかし IN-ADDR.ARPAツリーを通してたどり着くことはやはり行われる事に 注意すると、うまく動くためにはここで挿入されるCNAMEレコードは正しい場所を 指している必要がある。 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. 下に書いたのは同じ解法を用いた別の方法である。 $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. $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 host2 A 192.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 その他の運用上の問題。 CNAME参照は同じ名前空間に対して2つは宣言できない事に注意せよ。つまり、 つまり、/25プレフィクスを一つの所に宣言して、この方法でIN-ADDR.ARPAドメインを 運用して、そのあと/25のネットを更に長いプレフィクスのサブネットを切って、 更に同じ方法でそれぞれのサブネットに自分の名前空間を管理させようとするのは 不可能である。そういう事をすればCNAMEレコードがCNAMEレコードを指す事になり、 堅牢さが無くなるであろう。 不幸な事に、いくつか良く使われるDNSネームサーバの実装であるBIND4.9.3の 旧いβ版では、CNAMEレコードが逆引きに現れた時にバグがある。そのバグの あるバージョンのβ版はすたれていて、リリースコードでは直っている。 いくつかのソフトウエア会社はそのバグ入りβ版のコードを製品に入れている。 知っている限りの数少ないそういう場合は、そのバグを抱えた廃れたβ版 コードを入れ換えるため、製造元からのパッチが入手可能であるか、または そうなるように計画中である。 6. セキュリティー上の考察。 この案では、リーフサイトは/24のアドレスをとれた場合に比べて、正しく 設定されているサーバが一つ多くある事に頼っている。信頼性の高い 名前解決のためには更に付け加える要素があるかも知れない。 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. 他に、このメカニズムを導入した事に対するセキュリティ上の問題は私達には 見当たらない。 7. 結論 ここで示唆した計画は、IN-ADDR.ARPAドメインの権限をを委譲する上でさらなる 柔軟性を提供し、したがって、対応する逆引きDNS権限委譲の能力を損なう事無しに、 アドレス空間をもっと効率的に割り振る事ができる。 8. 謝辞 Glen A. Herrmannsfeldt はこのトリックを comp.protocols.tcp-ip.domains で少し前発表し、 Alan Barrettと Sam Wilsonは有益なコメントをそのニュース グループで与えた。 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,そしてPeter Koch には、 査読と建設的なコメントを頂いた事に感謝する。 9. 参考文献。 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host Table Specification", RFC 952, October 1985. [3] Elz, R., and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. 10. 作者の連絡先 Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway Phone: +47 73 59 44 68 Fax: +47 73 59 17 00 EMail: Havard.Eidnes@runit.sintef.no Geert Jan de Groot Berkeley Software Design, Inc. (BSDI) Hendrik Staetslaan 69 5622 HM Eindhoven The Netherlands Phone: +31 40 2960509 Fax: +31 40 2960309 EMail: GeertJan.deGroot@bsdi.com Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 USA Phone: +1 415 747 0204 EMail: paul@vix.com 11. 完全な著作権宣言 Copyright (C) The Internet Society (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. 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]