Network Working Group
Request for Comments: 2317
BCP: 20
Category: Best Current Practice
H. Eidnes (SINTEF RUNIT)
G. de Groot (Berkeley Software Design, Inc.)
P. Vixie (Internet Software Consortium)
平田 泰行 (Asuka.Net) 訳
1998年3月
これは、 RFC 2317, "Classless IN-ADDR.ARPA delegation" を独自に翻訳した物です。 この翻訳を利用する際は、 翻訳者の理解不足による誤訳の可能性が十分にあることを念頭に入れて下さい。 (誤訳を発見された場合、翻訳者まで連絡を頂ければ幸いです。)
この翻訳は "現状有姿 (AS IS)" で提供され、 明示的であるか黙示的であるかを問わずいかなる保証も行われないものとします。
この文書はインターネットコミュニティ の Internet Best Current Practices を規定するものである。 改良のための議論と提案を求める。 この文書の配布に制限はない。 (この日本語訳に関しても同様の扱いとする。)
Copyright © The Internet Society (1998). All rights reserved.
この文書では256個未満のアドレスを使用しているような アドレス空間がオクテットで区切られない場合における IN-ADDR.ARPA の権限委譲方法について解説する。 このようにして提案された方法によって非オクテット区切りを持つサブネットに 対する反対はなくなるだろう。 また、IN-ADDR.ARPA マッピングに適合する権限委譲機能を失うこと無く、 より著しく24ビットのプレフィクスの空間よりも狭いIPアドレス空間 を割り当てることが可能になるだろう。 提案された方法は、[1] で規定される元来の DNS 参照機構と完全に互換性がある。 すなわち、使用されるアルゴリズムを変更する必要性、 DNS を参照するソフトウェアを変更する必要性は全く無い。
この文書では、 この方法を実装するにあたってのガイドラインを提供するために 操作上の注意点についても論じている。
クラスレス・ルーティング技術の発展により、 非オクテット区切りのアドレス空間を割り当てることが可能になった。 小数のホストしか持たないような非常に小規模な組織の場合、 24ビット・プレフィクス (慣習的に "クラスCネットワーク番号" として参照された) の割り当ては、多くの場合アドレス空間の非効率な利用につながる。
より長いプレフィクス (より少ないアドレス空間) を割り当てたときに生じる問題として、 そのような割当を受けた組織が自分でそれ自身の逆引き ("IN-ADDR.ARPA") ゾーンを管理することが不可能であることがあげられる。 以下で解説する逆引きの権限委譲方法によって、 それぞれに無関係な組織に対して長いプレフィクスを持つアドレス空間を 割り当てる際のもっとも重大な欠点を取り除くことが可能である。
以下の通り、3つの異なった組織にアドレス空間を割り当てることを考える:
古来の方法では、以下のように単一ゾーンを使用することになる:
$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.
このゾーンの管理には問題が多い。 このゾーンに対する権限は1回委譲されているのみであるため、 これは "このゾーンは単一の組織によって管理される" と解釈される。 このゾーンにあるエントリに一致するアドレス空間を持つ他の組織は、 そのアドレスの名前を変更するために他の組織に依存せざるを得ない。 提案される方法を使用することによって、 この潜在的な問題を避けることが可能になる。
単一のゾーンはただ1度のみ権限が委譲される。 このため、上記の問題を解決するためには更に追加して権限委譲を行う必要がある。 追加して権限委譲をする点は、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
資源レコードを自動的に生成するのは非常に簡単なことである。
この問題の対処方法について提案された別の方法に対するこの方法は優位性に、 既に開発されたソフトウェアの修正が全く不要であるという点が挙げられる。 特に、"非ドット" 境界の IPv4 アドレスから名前への変換に対する権限分割を 処理するために、DNS における検索機構を変更する必要は無い。 さらに、この技法は多くの場所で何年も使用され続けており、 明白な問題を引き起こしていない。
当然、資源レコード
$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] の制限は適用されない。
近代的なクライアントとサーバは偏見にとらわれす、
正当な流儀に従う選択を行うだろう。
この例では "/" を使用している。
なぜならば、より目立つように思え、
そして学者ぶった評論家は「これらはホスト名ではない」
という議論が繰り返される必要があると感じるからである。
私達はあなたがそれほどまでに学者ぶらないよう、
そして几帳面に上記の例をそのまま写さないように助言する。
たとえば、"/"
の代わりにハイフンなどの控え目な文字を代用すると良いだろう。
この技法は256個以下のアドレス空間の権限委譲に使用することを想定している。 より大きなアドレスブロックの権限委譲については、 代わりに伝統的な方法 (複数の権限委譲) が使用できる。
古い版のネームサーバソフトウェアは
既にローカルまたは権限のあるデータとして持っていない場合、
CNAME レコードで指し示されている名前を検索して返すことをしない。
CNAME レコードのみがレスポンスとして帰されるため、
リゾルバ (resolver) に対していくつかの混乱を引き起こす可能性がある。
この問題を避けるため、
ゾーンの権限を委譲する側 (全ての CNAME レコードを含む)
のサーバは全て権限委譲を受け、
権限委譲を受けて CNAME レコードで指し示される
"子" ゾーンに対するスレーブ (セカンダリ)
サーバとして動作させることを推奨する。
この方法を使用する場合、 実際の PTR レコードを含むゾーンの位置はもはやあらかじめ定義されない。 これによって柔軟性が与えられる。 ここにいくつかの例を示す。
最初のアドレスまたは、 最初のアドレス及び一致するアドレス空間にあるネットワークマスク長を 使用する方法に対する代替手段として、 新たなゾーンの名前を決定する場合に (数字ではない) 名前を使用する方法がある。 このように、それは DNS ツリーの完全に異なった場所 (すなわち、IN-ADDR.ARPA ツリーの外部) を指し示すことが可能である。 2つの組織が何らかの理由で "明確な" アドレスの区切りが無い同一の物理サブネット (と一致するIPアドレス空間) を共有し、 それでも自身の IN-ADDR.ARPA マップを管理したい場合、 この代替手法を使用する必要がある。
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 ;
この方法で、
正引き (名前→アドレス) と逆引き (アドレス→名前)
の割り当てデータを実際に同一のゾーンファイルで設定することができる
― 逆引きゾーンに対するセカンダリが必要無いとして、
これを追加の利点と見なす人もいるだろう。
しかしながら、IN-ADDR.ARPA 木を経由するアクセスは行われることを
十分に認識するべきである。
したがって、動作させるにはそこに挿入された CNAME レコードは
それに対する正しい方向を指し示す必要がある。
同様の解決方法を使用した代替手法の概略を以下に示す:
$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
近いうちに、 この状況の特定の必要条件に適合する可能性が高いことは明白である。
同一のアドレス空間に対する2回以上の CNAME
参照を提供することはできないことに注意しなければならない。
すなわち、ある組織に対して /25 プレフィクスを割り当てて
この方法で IN-ADDR.ARPA を運用し、
同様の手法を使用してサブネットごとにそれ自身の数字空間の管理を与えた場合、
CNAME レコードが CNAME レコードを指し示すことになり、
これは結果として堅牢さの低下に繋がるだろう。
不幸にも、良く知られた DNS ネームサーバ実装である
BIND 4.9.3 の古いベータ版は逆引き検索が行われた際、CNAME
レコードが見付かった場合に問題を起こすことが知られている。
このようなベータ版は既に廃れたものとなっており、
リリースコードではこの問題は解決している。
製品に欠陥のあるベータコードを含んでいる
ソフトウェア製造元も存在する。
我々の知るいくつかの場合、
そのような廃れたベータコードを置き換えるような
パッチが製造元から入手可能または予定がある。
この方法を使用する場合、 "リーフサイト" (訳註: http://leaf.aquaplus.co.jp/ のことではなく、末端サイトの意味。:-p) は それ自身の /24 プレフィクスのアドレス空間を持つ場合に比べて 追加して1つのサイトを DNS ネームサービスの正しく運用に関して 信頼する必要がある。 そして、信頼性のある名前解決に際して、 動作しなければならない余分な構成要素を追加する。
それ以外に関して、 著者らはこの仕組みによって起こり得るセキュリティ上の問題を認識していない。
提案された方法は、IN-ADDR.ARPA ドメインの権限委譲における柔軟性を提供する。 これによって、アドレスから名前へのマッピングに一致するような DNS の権限委譲機能を失うことなく、 アドレス空間をより効率的に割り当てることが可能になる。
Glen A. Herrmannsfeldt には、少し前にこの技法を news: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 に感謝します。
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.