メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

このドキュメントは有効期限を過ぎており無効です。 現在有効なドキュメントについては、以下をご参照ください。
http://www.nic.ad.jp/ja/doc/validity.html

○本文書は、新IPレジストリシステム運用開始にともない施行いたします。
-------------------------------------------------------------------------
|  JPNIC公開文書著作権表示 (Copyright notice of JPNIC open documents)     |
|                                                                        |
|  この文書はJPNIC公開文書であり、著作権は社団法人日本ネットワーク           |
|  インフォメーションセンター(JPNIC)が保持しています。JPNIC公開文            |
|  書は誰でも送付手数料のみの負担でJPNICから入手できます。また、こ           |
|  の著作権表示を入れるかぎり、誰でも自由に転載・複製・再配布を行っ           |
|  て構いません。                                                         |
|  〒101-0047 東京都 千代田区 内神田2-3-4 国際興業神田ビル6F             |
|        社団法人日本ネットワークインフォメーションセンター                  |
-------------------------------------------------------------------------

      /24より小さい割り当てに対する、ネームサーバーの逆引きの設定方法


             社団法人日本ネットワークインフォメーションセンター
                    最終更新 2002年  3月 7日


*本文書について*

  この文書は技術参考資料です。

  本文書はBIND Version8.2.5以上を対象に/24より小さいIPアドレス割り当て
  に対する、ネームサーバーの逆引きの設定方法について解説したものです。

  なお、Bindについては以下のホームページに詳しい情報が掲載されています。

    http://www.isc.org/products/BIND/


*目次*

  1. はじめに
  2. ネームサーバーの設定方法
    2.1. 概要
    2.2. ISP側の設定
    2.3. エンドユーザー側の設定
    2.4. 実際の動作
  3. 注意点
    3.1. 設定が有効になるタイミング
    3.3. 逆引きを柔軟に設定できないネームサーバ
  4. 終わりに


1. はじめに

        現在のIPアドレスの割り当ては、従来のIPアドレスのクラスに依存し
        ない割り当てが行われています。

        このうち24ビットプリフィクス(従来ClassCと呼んでいた)より小さい
        単位で割り当てが行われた場合の、クラスレスなネームサーバーの逆
        引き設定の方法について説明します。

        この設定方法は、ネームサーバーの設定方法だけで対処するため、従
        来のDNSクライアントの変更を必要としません。


2. ネームサーバーの設定方法

  2.1. 概要

        従来の方法では、逆引きの設定にオクテットバウンダリに依存した方
        法が使われていました。しかしこのままですと、24ビットプリフィク
        スより小さい割り当ての場合の設定が行えません。

        そこで、ネームサーバーの逆引き設定の部分にCNAMEを利用した方法
        を使います。

        たとえば example.co.jp に次の割り当てがあったとします。これは
        27ビットプリフィクス(ClassCの1/8)の割り当てということですが、
        192.168.23.0/24の残りの部分は、example.co.jpが接続しているISP
        の、他の接続組織が利用することになります。

        example.co.jp   192.168.23.32/27

        ISP側のネームサーバーで23.168.192.in-addr.arpaを管理し、ユーザー
        側のネームサーバーで32/27.23.168.192.in-addr.arpaを管理する方法
        をとります。


  2.2. ISP側の設定

        ISP側の設定では、named.confを次のように記述します。

------------------------------------------------------------------------
zone "23.168.192.IN-ADDR.ARPA" {
    type master;
    file "suba.rev";
};

zone "32/27.23.168.192.IN-ADDR.ARPA" {
    type slave;
    file "bak/example.rev";
    masters {
        192.168.23.34;
    };
};
------------------------------------------------------------------------

        ISP側のsuba.revは、次に示すような CNAMEの羅列を用意します。

------------------------------------------------------------------------
$ORIGIN                         23.168.192.in-addr.arpa
@       IN SOA          ns.example.ad.jp. hostmaster.......
32/27   IN NS           gw.example.co.jp.
33      IN CNAME        33.32/27.23.168.192.in-addr.arpa.
34      IN CNAME        34.32/27.23.168.192.in-addr.arpa.
35      IN CNAME        35.32/27.23.168.192.in-addr.arpa.
 <中略>
61      IN CNAME        61.32/27.23.168.192.in-addr.arpa.
62      IN CNAME        62.32/27.23.168.192.in-addr.arpa.
------------------------------------------------------------------------

        この例では、192.168.23.32/27のサブネットに対して、
        192.168.23.32と、192.168.23.63を意図的に登録していません。これ
        は、このサブネット空間において、ネットワークアドレスおよびブロー
        ドキャストアドレスという特別な意味を持つアドレスであるためです。

  2.3. エンドユーザー側の設定

        エンドユーザー側(example.co.jp)では次のように設定します。

        ここで、example.co.jpのNSが

------------------------------------------------------------------------
gw.example.co.jp        192.168.23.35
------------------------------------------------------------------------

        であった場合、この設定を受けて、/27の割り当てのあった
        example.co.jpでは以下のような設定を用意します。

        named.confでは次のように記述します。

------------------------------------------------------------------------
zone "32/27.23.168.192.IN-ADDR.ARPA" {
    type master;
    file "example.rev";
};
------------------------------------------------------------------------

        また、example.revでは次のようにします。

------------------------------------------------------------------------
$ORIGIN                 32/27.23.168.192.IN-ADDR.ARPA.
@       IN SOA  gw.example.co.jp. hostmaster.example.co.jp
        IN NS   gw.example.co.jp.
33      IN PTR  rt.example.co.jp.
34      IN PTR  www.example.co.jp.
35      IN PTR  gw.example.co.jp.
------------------------------------------------------------------------


  2.4. 実際の動作

        以上の設定により、たとえば192.168.23.34のIPアドレスからホスト
        名を検索する場合、

        34.23.168.192.in-addr.arpa.
          ->
            ISPのサーバーの CNAMEから 34.32/27.23.168.192.in-addr.arpa.
              ->
                ユーザー側のサーバーより www.example.co.jp.

        となります。


3. 注意点

        本方式を利用した場合での注意点を以下に示します。

  3.1. 設定が有効になるタイミング

        通常の設定では、ユーザー側の設定が終われば問題なく逆引きを行う
        ことができます。しかしこの方法を利用する場合は、ISP側とユーザー
        側の両方の設定が終わらないと、逆引きを行うことができません。


  3.3. 逆引きを柔軟に設定できないネームサーバ

        GUIを利用して項目を設定するために、GUIの制限によりオクテットバ
        ウンダリに依存し、逆引きにCNAMEを利用した設定を行うことができ
        ないものがあります。この場合はそのDNSの利用をあきらめるしかあ
        りません。

  3.4. 文書内の設定例における注意点

        本文書で掲載している各設定において、以下のような記述がいくつか
        出てきます。

        32/27.23.168.192.IN-ADDR.ARPA.

        従来JPNICではこのような記述方法はRFC2317[1]に従い、推奨として
        公開してきました。しかし、この記載中にある'/'(スラッシュ)は、
        本来ドメインネーム・ホストネームとして利用するべきでないと定義
        されており[2]、この規則を厳密にチェックするDNSシステムでは、使
        用できない文字として扱われる場合があります。このような場合、
        '/'を'-' (ハイフン)と置き換えることで問題なく動作します。

4. 終わりに

        本設定はあくまでも設定例の一例ですので、ユーザー側とISP側の方
        法により、他の方法を利用していただいてもかまいません。たとえば
        32/27.23.168.192.in-addr.arpa以外に、

------------------------------------------------------------------------
A01.23.168.192.in-addr.arpa
32.23.168.192.in-addr.arpa
------------------------------------------------------------------------

        などを利用した方法も実際に利用されています。

        JPNICでは実際にどのような方法を採用するかについては、ISPとそのユー
        ザーに任せています。

       また、本文書では、設定例として'.jp'であるようなものだけを示しま
       したが、本文書に示した設定例はBindを利用した場合の一般的な設定
       例であり、'.  jp'に特化したものではなく、'.com'などのgTLDなどで
       も利用可能です。


*参考文献*

[1] RFC2317 : Classless IN-ADDR.ARPA delegation, H. Eidnes, G. de Groot, P. Vixie, March 1998
[2] RFC1034 : DOMAIN NAMES - CONCEPTS AND FACILITIES, P. Mockapetris, November 1987


以上
            

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.