回答:
/ 22の委任は簡単で、4/24の委任です。/ 14は4/16の委任などです。
RFC2317は、/ 24より長いネットマスクを持つ特殊なケースをカバーしています。基本的に、オクテット境界以外でin-addr.arpaゾーンの委任を行うための非常にクリーンな方法はありませんが、これを回避できます。IPアドレス172.16.23.16-> 172.16.23.23である172.16.23.16/29を委任したいとしましょう。
23.16.172.in-addr.arpaゾーンの所有者として、この範囲を23.16.172.revゾーンファイルに入れて、この範囲を顧客に委任できます。
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
したがって、新しいゾーン(16-29.23.16.172.in-addr.arpa。)を定義し、それを顧客のネームサーバーに委任していることがわかります。次に、IPからCNAMEを作成し、新しく委任されたゾーンの下の対応する番号に委任します。
これらが委任された顧客として、named.confで次のようなことを行います。
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
そして、.revファイルで、通常のin-addr.arpaゾーンのようなPTRを作成します。
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
それは一種のクリーンな方法であり、PTRを配置するin-addr.arpaゾーンなどがあるため、精通した顧客を満足させます。逆DNSを制御したいが、そうしない顧客のためのより短い方法ゾーン全体を設定する場合、個々のレコードをメインゾーンの同様の名前にCNAMEするだけです。
この場合、委任者としての23.16.172.revファイルには次のようなものがあります。
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
そのため、概念は他のアイデアと似ていますが、新しいゾーンを作成して顧客に委任する代わりに、顧客の既存のメインゾーンの名前にレコードをCNAMEします。
顧客は、customer.comゾーンファイルに次のようなものを持っています。
office IN A 172.16.23.17
17 IN PTR office.customer.com.
www IN A 172.16.23.18
18 IN PTR www.customer.com.
(etc)
それはただ顧客のタイプに依存します。私が言ったように、それは単に顧客のタイプに依存します。精通した顧客は、独自のin-addr.arpaゾーンを設定することを好み、ドメイン名ゾーンにPTRを置くことは非常に奇妙だと思うでしょう。知識のないお客様は、大量の追加設定を行うことなく、「正常に動作する」ことを望みます。
他の方法もありそうで、私がよく知っている2つの方法を詳しく説明しています。
私は/ 22と/ 14がいかに簡単であるかについての私の声明について考えていました。そしてそれが本当である理由を考えていましたが、25から32の間は難しいです。私はこれをテストしていませんが、次のように/ 32全体を顧客に委任できるかどうか迷います。
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
次に、顧客側で/ 32全体をキャッチします。
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
そして、個々のファイルには次のようなものがあります。
@ IN PTR office.customer.com.
明らかな欠点は、/ 32ごとに1つのファイルがかなり粗悪なことです。しかし、私はそれがうまくいくに違いない。
私が言及したものはすべて純粋なDNSです。DNSサーバーがそれを許可しなかった場合、それはDNSの全機能を制限しているためです。私の例は明らかにBINDを使用していますが、Windows DNSとBINDを使用してこの点の顧客側を行いました。どのサーバーでも動作しない理由はわかりません。
BINDには、PTRレコードのシーケンスを作成するための独自の$ GENERATEマクロがありますが、クラスフルな世界を想定しているため、あまり役に立ちません。CIDRリバースゾーンを特別にサポートしている他のサーバーは知りませんが、CIDRの需要があると思われます。
PowerDNSには、問題が労力に見合うだけの大きさである場合に独自のコードを作成できる、優れたバックエンドインターフェイスがあります。「PipeBackend」を使用してプロトタイプを作成することもできます。特にPostgresには「cidr」データ型があるため、MySQL / PostgreSQLインターフェースを介して魔法のSQLを実行することもできます。
http://aa.net.uk/kb-domains-reversedns.html(約半分)で、ISPがリバースDNSを実行する方法を説明しています。私はあなたがそれをするどんな方法も地獄のようにいものになるだろうと思う。