☰

クラスレス逆マップ委任は「dig -x」では機能しません。何か影響がありますか?

tag-icon • tag-icon domain-name-system bind dns-zone
クラスレス逆マップ委任は「dig -x」では機能しません。何か影響がありますか?

ウェブザイトラックス、そこで私はクラスレス逆マップ委任dig -x <ip address>は、この委任方法 (CNAMES を使用) が使用されている場合、これは機能しないはずだと述べています。

例えば：

これは機能しないはずです: dig -x 192.168.23.66

そして、これは動作するはずです: dig 66.64/27.168.192.IN-ADDR.ARPA

そして、少し変更すると動作します (委任先のサーバーと、PTR レコードが必要なサーバーを指定します)。 dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA

チュートリアルで説明されているとおりに動作するようです:

同様の委任を設定しましたが、上記のように動作します。dig -x委任された範囲の IP アドレスを使用すると、委任元のネーム サーバーは、誰が権限を持っているかを伝えます。66.64/27.168.192.IN-ADDR.ARPA.クラスレス ネットワークが委任されたサーバーは、3 番目のコマンド ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA) でのみ機能します。

大丈夫で安全ですか？

dig -x (または nslookup) では動作しないので、動作しないものが他にもあるのではないかと思います。リゾルバはそのような IP アドレスを問題なく解決できますか? たとえば、この委任方法を使用すると、電子メール サーバーは問題なく逆引き参照を実行できますか? これを使用しない理由はありますか?

私の例（若干修正）：

dig @ns1.example.com -x 192.168.134.1

;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60  IN  CNAME   1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN   NS      ns2.example.com.


dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.

;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR     1st_super.example.com.

なぜうまくいかなかったのか

委任先のゾーンの名前が間違っており、2 番目のクエリで間違った名前を使用したため、回答が得られました (2 つの間違いは部分的に相殺されました)。

間違い（反転していない）:

0-127.192.168.134.in-addr.arpa.

になるはずだった：

0-127.134.168.192.in-addr.arpa.

このエラーを修正し、委任サーバーが委任されたゾーンのスレーブになると、dig -x <ipaddress>動作します。

答え1

要約

作成する場合RFC2317スタイルのクラスレス in-addr.arpa 委任では、IP アドレスの逆マッピングを使用してサブ委任の権威ネームサーバーに直接クエリを実行できないのは、まったく普通のことです。
本当に重要なのは、リゾルバ サーバーが逆の名前を検索できることです (たとえばdig -x 192.0.2.1 @8.8.8.8、環境やユースケースに関連する IP アドレスとリゾルバ サーバーの組み合わせなど)。

RFC2317の説明

RFC2317 が一種の回避策を提供している全体的な問題は、IPv4 アドレスから DNS の逆引き名への規則ベースのマッピング (例: 192.0.2.1-> 1.2.0.192.in-addr.arpa) がクラスレス委任よりも古いため、可能な委任ポイントが実質的に/0、/8、16、/24、に固定されている/32ことです。(委任できるのはラベルごとにのみで、マッピングは IPv4 アドレスの各オクテットを逆順にラベルにするように定義されています。)
実際に委任のようなものを可能にするには、マッピングを別の方法で定義し、よりきめの細かい命名スキームにマッピングする必要がありました/27。

RFC2317 は、基本的な状況を変えるものではなく、実際にプロトコルをまったく変更するものでは
ありません。クラスレス委任が不可能であるという制限を回避するために人間のオペレーターが使用できるスキームを提案するだけです。

そのスキームは次のように要約できます。

  1. 実際の逆ゾーン（命名規則に従って）の名前のセットに別名（レコードを追加）を定義しCNAME、これを新しい名前にマッピングします。新しい名前空間
    （新しい名前空間は実際にはどれでも名前ですが、RFC2317 では、説明的な名前を使用し、新しい名前空間を既存のゾーンの子として、その下のどこかに配置することを推奨していますin-addr.arpa。
  2. これに対応するゾーンを委任します新しい名前空間必要に応じて

その結果、検索を依頼されたリゾルバ サーバーは、1.2.0.192.in-addr.arpa単に通常どおり検索を実行し、実際に探していたCNAMEではなく、そのレコードに遭遇します。 次に、RFC2317 が存在することさえ知らなくても、単に を新しい名前空間にたどり、RFC2317 で提案されているとおりに設定されていれば、その新しい名前で使用できる が見つかります。PTR
CNAMEPTR

たとえば、次の内容を含む2.0.192.in-addr.arpa.ゾーンがあるとしますns1.other.example.。

1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.

実際の逆引き名 ( ) の検索プロセス1.2.0.192.in-addr.arpa.では となりCNAME、リゾルバは をCNAME通常どおり処理し、どこに導かれてもそれに従います。

この例では、 につながり1.0/27.2.0.192.in-addr.arpa.、ゾーンの への委任もあるため0/27.2.0.192.in-addr.arpa.、ns7.example.com.リゾルバは の検索プロセスを続行できます。新しい名前そしてすべてうまくいくでしょう。

一方、 にクエリを送信した場合、 は1.2.0.192.in-addr.arpa.それns7.example.com.について何も知りません。
ns7.example.com. ではないそのアドレスの逆引きゾーンがある場合、実際の逆引きゾーンがこれらのエイリアスによって参照する、緩く関連したゾーンのみがあります。

RFC2317 スタイルの委任が機能しているかどうかを確認するには、まず、実際のリゾルバが名前の検索に成功するかどうかを確認します。
ただし、詳細を掘り下げると、実際の逆ゾーンのネームサーバーが何で応答するか (CNAMEこの場合は ) を確認し、正規名 ( CNAME「ターゲット」) がどこに委任されているかを確認し、そのネームサーバーがレコードで指定された正規名に対して意図したとおりに応答するかどうかを確認しますCNAME。

関連情報