## page was renamed from DNS/実装/djbdns/dot-arpa ## page was renamed from DNS/djbdns/dot-arpa DNS/djbdns/dot-arpaについて、ここに記述してください。 http://cr.yp.to/djbdns/dot-arpa.html の日本語訳（更新中）　-- ToshinoriMaeno <> D. J. Bernstein [Translated into Japanese by MAENO Toshinori] Internet publication [[djbdns]] == .in-addr.arpaからの委譲を受ける == 一群の IP アドレスを管理していて、それら IP アドレスの 逆引きを設定するのなら、 in-addr.arpa ドメイン内に対応する名前を作ることになります。 例えば、 1.8.7.0 から 1.8.7.255 までの IP アドレスを管理しているとしたら、 7.8.1.in-addr.arpa ドメインがあなたに委譲されているはずです。 例として、ここでの説明では 7.8.1.in-addr.arpa ドメインを使います。 DNS を動かしている二台のコンピュータがあって、 一台の IP アドレスは 1.8.7.200、もう一台は 1.8.7.201 であるとします。 通常二つの手順を踏みます。 最初は DNS サーバに 7.8.1.in-addr.arpa に対する問合せに 答えるように設定することと 7.8.1.in-addr.arpa の DNS サーバのアドレスが 1.8.7.200 と 1.8.7.201 とであることを公表するように設定することです: {{{ cd /service/tinydns/root ./add-ns 7.8.1.in-addr.arpa 1.8.7.200 ./add-ns 7.8.1.in-addr.arpa 1.8.7.201 make }}} 第二は親サーバの管理者に 7.8.1.in-addr.arpa を a.ns.7.8.1.in-addr.arpa (IP アドレス は 1.8.7.200) と b.ns.7.8.1.in-addr.arpa (IP アドレス は 1.8.7.201) の 二台のサーバに委譲してもらうするように言うことです。 委譲のための費用は通常は 最初に IP アドレスを分けてもらったときの 費用に含まれているでしょう。 不幸なことは上の通常手続きがうまく行かないような 余計な制約を付ける親管理者がいることです。 特に ARIN (IP addresses in America) と RIPE (IP addresses in Europe) の両者は 委譲が グルーなし(glueless) であることを要求します。 これは DNS サーバが in-addr.arpa 外の名前を必要することを意味します。 「グルーなし」は悪い実践です。 なぜなら、DNS 検索を遅れさせ、ときには検索できなくさせますから。 しかし、 ARIN と RIPE は気にしていません。 (Reported May 2001.) ARIN と RIPE については /service/tinydns/root/data を編集して、 あなたの管理下の別ドメインのサーバ名を指定します。 それをx.orgとすると: {{{ .7.8.1.in-addr.arpa:1.8.7.200:a.reversens.x.org .7.8.1.in-addr.arpa:1.8.7.201:b.reversens.x.org }}} 7.8.1.in-addr.arpa を a.reversens.x.org (IP アドレス 1.8.7.200) と b.reversens.x.org (IP address 1.8.7.201) に委譲するように親サーバ管理者に依頼します。 APNIC (Asia と Australia の IP アドレス管理組織) は グルーなし委譲には拘りませんが、 TCP サービス を設定することを要求します。 (Reported June 2001.) == 個々の IP アドレスの逆引きの委譲 == 256 こ未満の IP アドレス群を貰っているときには 親サーバは各アドレスを別々に委譲しているはずです。 例えば、 DNS サーバ (1.8.7.200 と 1.8.7.201)に IP アドレスが 1.2.3.144 と 1.2.3.145 であるコンピュータの名前を 公表させたいとしたら、 3.2.1.in-addr.arpa ドメインの管理者は以下のようにします。 {{{ cd /service/tinydns/root ./add-childns 144.3.2.1.in-addr.arpa 1.8.7.200 ./add-childns 144.3.2.1.in-addr.arpa 1.8.7.201 ./add-childns 145.3.2.1.in-addr.arpa 1.8.7.200 ./add-childns 145.3.2.1.in-addr.arpa 1.8.7.201 make }}} そして、あなたは以下のようにします。 {{{ cd /service/tinydns/root ./add-ns 144.3.2.1.in-addr.arpa 1.8.7.200 ./add-ns 144.3.2.1.in-addr.arpa 1.8.7.201 ./add-ns 145.3.2.1.in-addr.arpa 1.8.7.200 ./add-ns 145.3.2.1.in-addr.arpa 1.8.7.201 make }}} /service/tinydns/root/data に 以下の行が作られます。 {{{ .144.3.2.1.in-addr.arpa:1.8.7.200:a .144.3.2.1.in-addr.arpa:1.8.7.201:b .145.3.2.1.in-addr.arpa:1.8.7.200:a .145.3.2.1.in-addr.arpa:1.8.7.201:b }}} そして、以下の行が {{{ =phoenix.elysium.heaven.af.mil:1.2.3.144 }}} phoenix.elysium.heaven.af.mil は IP アドレス 1.2.3.144 であり、 1.2.3.144 に対する名前は phoenix.elysium.heaven.af.mil あると宣言します。 == RFC 2317 流儀 == in-addr.arpa 管理者の中には 逆引きドメインをひとつの委譲だけですませるために 「RFC 2317 クラスレス逆引きの委譲 」に拘る人もいることに注意してください: {{{ C144.3.2.1.in-addr.arpa:144.144-145.3.2.1.in-addr.arpa C145.3.2.1.in-addr.arpa:145.144-145.3.2.1.in-addr.arpa &144-145.3.2.1.in-addr.arpa:1.8.7.200:a &144-145.3.2.1.in-addr.arpa:1.8.7.201:b # or, in BIND master zone-file format: # 144.3.2.1.in-addr.arpa. CNAME 144.144-145.3.2.1.in-addr.arpa. # 145.3.2.1.in-addr.arpa. CNAME 145.144-145.3.2.1.in-addr.arpa. # 144-145.3.2.1.in-addr.arpa. NS a.ns.144-145.3.2.1.in-addr.arpa. # 144-145.3.2.1.in-addr.arpa. NS b.ns.144-145.3.2.1.in-addr.arpa. # a.ns.144-145.3.2.1.in-addr.arpa. A 1.8.7.200 # b.ns.144-145.3.2.1.in-addr.arpa. A 1.8.7.201 }}} その場合にはdata ファイルは以下の行のようになります。 {{{ .144-145.3.2.1.in-addr.arpa:1.8.7.200:a .144-145.3.2.1.in-addr.arpa:1.8.7.201:b =phoenix.elysium.heaven.af.mil:1.2.3.144 ^144.144-145.3.2.1.in-addr.arpa:phoenix.elysium.heaven.af.mil =bogey.elysium.heaven.af.mil:1.2.3.145 ^145.144-145.3.2.1.in-addr.arpa:bogey.elysium.heaven.af.mil }}} 親管理者が決めた名前と同じ144-145.3.2.1.in-addr.arpaを使います。 普通なら = 行によって自動生成されるので、 ^行は使わないのですが、 クラスレスの逆引き委譲にはこの機能は使えません。 Why would anyone want to use classless reverse delegation? Answer: If you were running BIND, you'd find it only a little bit painful to receive a classless reverse delegation (setting up one zone file), while you'd find it much more painful to receive separate reverse delegations (setting up many zone files).