DNS/djbdns/dot-arpaについて、ここに記述してください。

http://cr.yp.to/djbdns/dot-arpa.html の日本語訳（更新中）　-- ToshinoriMaeno 2013-12-28 02:37:52

D. J. Bernstein [Translated into Japanese by MAENO Toshinori] Internet publication djbdns

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

2. 個々の 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 あると宣言します。

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