CIDRの世界で逆引きDNS


24

リバースDNSはクラスの境界に強く結びついているようですが、CIDRがサブネットの権限を委任するための標準となっている現在、どのような方法が存在しますか?複数の方法が存在する場合、どれが最適ですか?DNSサーバー(バインド、djbdns、Microsoft DNS、その他)に応じて、委任を異なる方法で処理する必要がありますか?クラスB 168.192.in-addr.arpaであるネットワークの制御権があるとしましょう:

  • / 22の権限を委任する方法は?
  • / 25の権限を委任する方法は?

回答:


31

/ 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を使用してこの点の顧客側を行いました。どのサーバーでも動作しない理由はわかりません。


1
おそらく、RFC2317(考えているtools.ietf.org/html/rfc2317
Zoredache


0

BINDには、PTRレコードのシーケンスを作成するための独自の$ GENERATEマクロがありますが、クラスフルな世界を想定しているため、あまり役に立ちません。CIDRリバースゾーンを特別にサポートしている他のサーバーは知りませんが、CIDRの需要があると思われます。

PowerDNSには、問題が労力に見合うだけの大きさである場合に独自のコードを作成できる、優れたバックエンドインターフェイスがあります。「PipeBackend」を使用してプロトタイプを作成することもできます。特にPostgresには「cidr」データ型があるため、MySQL / PostgreSQLインターフェースを介して魔法のSQLを実行することもできます。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.