13-4. DNSの動作を調べる  

  (1) DNS キャッシュデ−タ   '96〜

   * キャッシュデ−タとは

    DNS のキャッシュデ−タというのは、コンピュ−タのメモリ内に蓄えたドメイン名の情報
    である。named を起動させると、初め制御ファイルの named.ca 記載のドメイン名情報を、
    メイン・メモリに記憶する。named.ca ファイルの記述を、 インタ−ネットのル−ト用キ
    ャッシュのを使うと、世界中どこへでもアクセスができるようになる。このファイルには 
    DNS 管理の大親分のIPアドレスが書いてあるからである。そして他のドメインのホスト
    にアクセスするたび、そのネ−ムサ−バやホストのIPアドレスがキャッシュデ−タに追
    加されて行くことになる。つまりコンピュ−タのメモリに記憶されていく。もちろんメモ
    リ中の記憶なので、コンピュ−タをシャットダウンしたらその記憶はまっさらになる。


   * キャッシュデ−タの例

    ロ−カルでのみ使う DNS の設定を例にする。 一応 SunOS 4.1.4-JLE の named デ−モン
    での結果である。以下の例では他の DNS を見に行くことはできず、 クロ−ズしているの
    で情報は増えることはない。

    /etc/named.boot
    -------------------------------------------------------------------
    |;domain         nix.co.jj      << これはキャッシュデ−タには関係ない。
    |
    |primary         nix.co.jj                  /etc/named.hosts
    |cache           .                          /etc/named.ca
    |primary         0.0.127.in-addr.arpa       /etc/named.local
    |;primary        201.9.192.in-addr.arpa     /etc/named.rev  << とりあえずなし。

    /etc/named.ca
    -------------------------------------------------------------------
    |.                 99999   IN  NS  hostA.nix.co.jj.
    |hostA.nix.co.jj.  99999   IN  A   192.9.201.1

    /etc/named.hosts
    -------------------------------------------------------------------
    |;name   ttl     class   type    reccod specific infomation
    |@               IN      SOA    hostA.nix.co.jj. katou.nix.co.jj. (
    |                               19970307 
    |                               3600 300 3600000 360000 )   
    |                IN      NS     hostA.nix.co.jj.
    |localhost.      IN      A      127.0.0.1
    |hostA           IN      A      192.9.201.1

    /etc/named.local
    -------------------------------------------------------------------
    |@               IN      SOA    hostA.nix.co.jj. katou.nix.co.jj. (
    |                               19970307 
    |                               3600 300 3600000 360000 )   
    |                IN      NS     hostA.nix.co.jj.
    |$ORIGIN 0.0.127.in-addr.arpa.
    |1               IN      PTR    localhost.


    # /usr/etc/in.named &
    # kill -INT in.named-pid        << これで named_dump.db ファイルができる。
                                       すでにある場合は、書き換えられる。
    # cat /var/tmp/named_dump.db
    ; Dumped at Thu Mar 27 10:41:59 1997
    ; --- Cache & Data ---
    $ORIGIN .
    .       286     IN      NS      hostA.nix.co.jj.
    localhost       IN      A       127.0.0.1
    $ORIGIN co.jj.
    nix      IN      SOA     hostA.nix.co.jj. katou.nix.co.jj. (
                    19970307 3600 300 3600000 360000 )
                    IN      NS      hostA.nix.co.jj.
    $ORIGIN nix.co.jj.
    hostA           IN      A       192.9.201.1
    $ORIGIN 0.127.in-addr.arpa.
    0               IN      SOA     hostA.nix.co.jj. katou.nix.co.jj. (
                    19970307 3600 300 3600000 360000 )
                    IN      NS      hostA.nix.co.jj.
    $ORIGIN 0.0.127.in-addr.arpa.
    1               IN      PTR     localhost.
    ; --- Hints ---                                 << ここから下が named.ca で読み
    $ORIGIN .                                          込んだル−トの情報。
    .       99957   IN      NS      hostA.nix.co.jj.
    $ORIGIN nix.co.jj.
    hostA   99957   IN      A       192.9.201.1  ; 26
             ↑
             |
    この値はどんどん減って行く。named デ−モンを起動して、# kill -INT やるまで33秒
    ( 99999-99957=33 )経ったということである。これ 0 になったらどうなるのかな。 最新
    の BIND では root.cache のデ−タは値が減らないようになっているらしい。named.caを
    インタ−ネット用のものにすれば、他サイトにアクセスする毎にキャッシュデ−タに結果
    が蓄えられていく。このように有効期間を伴ったデ−タが蓄えられる。これで、よそのデ
    −タなのか、自分とこのデ−タなのか区別できる。


   * named_dump.db から分かること

    このキャッシュデ−タのダンプ情報の意味するところは大きい。DNS の仕組み、それに制
    御ファイルの書き方を理解する上で重要である。 named.hosts だ named.rev だと記述し
    ても、つまるところこのようなメモリに蓄えられるデ−タが、DNS の情報として有効にな
    る。named.boot の primary も secondary も、 このようにメモリ展開されたら一緒であ
    り、デ−タとしては区別はない。 ともかくメモリ中の $ORIGIN nix.co.jj. に続く A レ
    コ−ドが、ホスト名に対応するIPアドレスであり、nix.co.jj ドメインのオ−ソライズ
    されたデ−タである。 逆引きデ−タについても $ORIGIN 1.168.192.in-addr.arpa. とあ
    れば、192.168.1.0 ネットワ−クのホストIPアドレスを管理してますということである。
    そして上位ドメイン、つまりインタ−ネット上では、nix.co.jj についてはここに聞いて
    くれ、192.168.1.0 についてはここに聞いてくれと、 JPNIC の DNS に書かれていればい
    いのである。これら nix.co.jj と 192.168.1.0 のペアのゾ−ン情報は、通常は同じ DNS
    で管理される。しかし DNS の仕組み的には、 どこが管理しているか分かってさえいれば、
    よそのサイトで 192.168.1.0 のゾ−ン情報が管理されても構わないということである。


   * Apollo の named で確認したこと  `23/11

    SOA レコ−ドの Minimum TTL について気付いたこと。 この値を60秒や10秒にしてテ
    ストをやっていたところ、 問い合わせをした named サ−バにキャッシュされる時間がそ
    うならない。どうも5分が最低で、それ以下の値だと5分にしてキャッシュするようであ
    る。下のようなミニ・インタ−ネットで確認してみた。DNS のクライアントのホストから
    例えば $ ping D1.ddd.jj とやれば、ホスト E0 の named サ−バに D1.ddd.jj のIPア
    ドレスを問い合わせる。E0 の named は知らないので、 ホスト D0 の named に問い合わ
    せ、回答をもらいクライアントに返答し、自分もその情報を蓄える。


            ddd.jj    D1.ddd.jj     eee.jj     D1.ddd.jj
           --------   問い合わせ   --------    問い合わせ  --------
           |ホスト| <------------  |ホスト|  <------------ |クライ| /etc/resolv.conf
           |  D0  |                |  E0  |                |アント| ----------------
           -------- named          -------- named          -------- |192.10.10.2
               | .1                    |.2                     |.3
        -------------------------------------------------------------- 192.10.10.0
                              D1.ddd.jj のキャッシュ時間は5分。
                              D2.ddd.jj のキャッシュ時間は10分。

    ホスト D0 の named.hosts
    ---------------------------------------------------------------
    |@  IN  SOA D0.aaa.jj. katou.D0.aaa.jj. ( 1 100 100 100 60 ) ; 
    |           |                                           ↑
    |D1     IN A 192.10.10.8  ←  D1.ddd.jj はキャッシュ時間をデ
    |D2 600 IN A 192.10.10.9      フォルトでこの値、60秒をとる。
         ↑
        D2.ddd.jj はキャッシュ時間を600秒と指定した。


  (2) nslookup コマンド

   * 詳細情報をみる     例:INDY でサブドメインの DNS 情報をみる。

    /etc/resolv.conf
    -----------------------
    |nameserver 192.9.200.6

    % nslookup
    Default Server:  hostC.sub.nix.co.jj
    Address:  192.9.200.6

    > set all                           << set all はオプションの状態を表示する。
    Default Server:  hostC.sub.nix.co.jj
    Address:  192.9.200.6

    Set options:
      nodebug         defname         search          recurse
      nod2            novc            noignoretc      port=53
      querytype=A     class=IN        timeout=5       retry=4
      root=ns.internic.net.
      domain=
      srchlist=
    
    > set type=any                      << set type=any とやってドメイン名を入れると、
    > sub.nix.co.jj                        そのドメインの SOA と NS レコ−ド情報が出
    Server:  hostC.sub.nix.co.jj           て来る。
    Address:  192.9.200.6
    
    sub.nix.co.jj
            origin = hostC.sub.nix.co.jj
            mail addr = katou.hostC.sub.nix.co.jj
            serial = 10001
            refresh = 3600 (1 hour)
            retry   = 300 (5 mins)
            expire  = 3600000 (41 days 16 hours)
            minimum ttl = 360000 (4 days 4 hours)
    sub.nix.co.jj        nameserver = hostC.sub.nix.co.jj
    sub.nix.co.jj        preference = 10, mail exchanger = hostC.sub.nix.co.jj
    hostC.sub.nix.co.jj internet address = 192.9.200.6

    > ls -d sub.nix.co.jj               << named.hosts の内容そのものが表示される。
    [hostC.sub.nix.co.jj]
     sub.nix.co.jj.     SOA   hostC.sub.nix.co.jj katou.hostC.sub.nix.co.jj. 
                                                  (10001 3600 300 3600000 360000)
     sub.nix.co.jj.     NS    hostC.sub.nix.co.jj       
     sub.nix.co.jj.     MX    10   hostC.sub.nix.co.jj
     hostC              A     192.9.200.6
     sub.nix.co.jj.     SOA   hostC.sub.nix.co.jj katou.hostC.sub.nix.co.jj. 
                                                  (10001 3600 300 3600000 360000)

    > ls -d 200.9.192.in-addr.arpa      << named.rev の内容そのものが表示される。

    > set type=a    << A レコ−ドをみる。FQDN を入れる。
    > set type=ptr  << 逆引きレコ−ドをみる。IPアドレスを入れる。
    > set type=ns   << ネ−ムサ−バをみる。
    > set type=soa  << SOA レコ−ドをみる。

    > ?         << ヘルプ。
    Commands:       (identifiers are shown in uppercase, [] means optional)
    NAME            - print info about the host/domain NAME using default server
    NAME1 NAME2     - as above, but use NAME2 as server
    help or ?       - print info on common commands; see nslookup(1) for details
    set OPTION      - set an option
        all         - print options, current server and host
        [no]debug   - print debugging information
        [no]d2      - print exhaustive debugging information
        [no]defname - append domain name to each query 
        [no]recurse - ask for recursive answer to query
        [no]vc      - always use a virtual circuit
        domain=NAME - set default domain name to NAME
        srchlist=N1[/N2/.../N6] - set domain to N1 and search list to N1,N2, etc.
        root=NAME   - set root server to NAME
        retry=X     - set number of retries to X
        timeout=X   - set initial time-out interval to X seconds
        querytype=X - set query type, e.g., A,ANY,CNAME,HINFO,MX,NS,PTR,SOA,WKS
        type=X      - synonym for querytype
        class=X     - set query class to one of IN (Internet), CHAOS, HESIOD or ANY
    server NAME     - set default server to NAME, using current default server
    lserver NAME    - set default server to NAME, using initial server
    finger [USER]   - finger the optional NAME at the current default host
    root            - set current default server to the root
    ls [opt] DOMAIN [> FILE] - list addresses in DOMAIN (optional: output to FILE)
        -a          -  list canonical names and aliases
        -h          -  list HINFO (CPU type and operating system)
        -s          -  list well-known services
        -d          -  list all records
        -t TYPE     -  list records of the given type (e.g., A,CNAME,MX, etc.)
    view FILE       - sort an 'ls' output file and view it with more
    exit            - exit the program, ^D also exits

    > exit      << 終わり。quit でも終われそうな気がするがダメ。


   * DNS のキャッシュ情報の確認

    > set type=a
    > hostB.nix.co.jj                   << 初めて hostB.nix.co.jj のIPアドレスを問
    Server:   hostC.sub.nix.co.jj          い合わせる。
    Address:  192.9.200.6

    Name:     hostB.nix.co.jj
    Address:  192.9.200.2

    > hostB.nix.co.jj                   << 2回目、問い合わせたところ。 このネ−ムサ
    Server:   hostC.sub.nix.co.jj          −バは hostB.nix.co.jj のIPアドレスを覚
    Address:  192.9.200.6                  えている。
    
    Non-authoritative answer:           << キャッシュされていることを示す。
    Name:     hostB.nix.co.jj  
    Address:  192.9.200.2


   * ネ−ムサ−バを見つける

    > set q=ns     
    > nix.co.jj
    Server:  hostC.sub.nix.co.jj
    Address:  192.9.200.6

    Non-authoritative answer:
    nix.co.jj       nameserver = hostA.nix.co.jj

    Authoritative answers can be found from:
    nix.co.jj       nameserver = hostA.nix.co.jj
    hostA.nix.co.jj internet address = 192.9.200.1


   * 他のネ−ムサ−バの情報をみる

    > server hostA.nix.co.jj            << IPアドレスを入れてもいい。
    Default Server:  hostA.nix.co.jj
    Address:  192.9.200.1

    > ls nix.co.jj
    [hostA.nix.co.jj]
     nix.co.jj.       server = hostA.nix.co.jj       
     hostA            192.9.200.1
     hostB            192.9.200.2
     localhost        127.0.0.1
     sub              server = hostC.sub.nix.co.jj       
     hostC.sub        192.9.200.6
     hostA            192.9.200.1


   * named のポ−ト番号を変更する

    named の TCP/UDP ポ−ト番号を変えてみる。何の役に立つか分からないが、 一応こんな
    こともできるよということで。named デ−モンのクライアントからのアクセス・ポ−ト番
    号のデフォルトは 53 番。named デ−モン同士も 53 番を使う。

    % named -p 55 &   

    /etc/services 
    ----------------------------------
    |   |
    |domain     55/tcp     nameserver   << 55 番に変えておく。元は 53 番。
    |domain     55/udp     nameserver
    |   |

    % nslookup      << 確認してみる
    > set port=55
    > sub.nix.co.jj
    Server:  hostC.sub.nix.co.jj
    Address:  192.9.200.6               << 見つからないと出ている。

    *** hostC.sub.nix.co.jj can't find sub.nix.co.jj: No response from server


    % named -help   << INDY に入っていた /usr/sbin/named のヘルプ。
    Usage: named [-d #] [-p port] [-L lamedel,rootns] [{-b} bootfile]


  (3) tcpdump で DNS の動作を見る

   * DNS のアクセス・ポ−トの確認

    nix.co.jj の1次ネ−ムサ−バ                  
    cad.nix.co.jj の2次ネ−ムサ−バ              1本のネットワ−ク・セグメントを2
        -------                                   つのドメインに分ける。上位、下位ド
        |hostA| named                             メインを設定した。DNS の論理階層構
        -------             □ hostB              造である。2本のネットワ−クの間に
       ec0 | 192.9.200.1    |192.9.200.2         ゲ−トウェイがないことに注意したい。
       ----*------------------------------
                  |
                  |       ------- cad.nix.co.jj の1次ネ−ムサ−バ   
                  |       |hostC| named
                  |       ------- 
                  |          | 192.9.200.3         
       ----------------------*-------------

    [ hostA ]

    /etc/named.boot                     注.named.rev など一部省略してある。
    --------------------------------------------------------------
    |cache      .              /etc/named.ca
    |primary    nix.co.jj      /etc/named.hosts
    |secondary  cad.nix.co.jj  192.9.200.3   /etc/named.hosts.sec

    /etc/named.hosts
    --------------------------------------------------------------
    |@          IN  SOA hostA.nix.co.jj. katou.hostA.nix.co.jj. (
    |                   1.1 ... )
    |           IN  NS  hostA.nix.co.jj.
    |
    |hostA      IN  A   192.9.200.1 
    |hostB      IN  A   192.9.200.2


    [ hostC ]

    /etc/named.boot
    --------------------------------------------
    |;cache     .              /etc/named.ca        << 分からない問い合わせをル−ト
    |primary    cad.nix.co.jj  /etc/named.hosts        でなく上位ドメインに送るため。

    /etc/named.hosts
    ----------------------------------------------------------------------
    |@          IN  SOA hostC.cad.nix.co.jj. tarou.hostC.cad.nix.co.jj. (
    |                   1.1 ... )
    |           IN  NS  hostC.cad.nix.co.jj.
    |hostC      IN  A   192.9.200.3
    |
    |nix.co.jj.         IN  NS  hostA.nix.co.jj.    << 上位ドメインの NS レコ−ド。
    |hostA.nix.co.jj.   IN  A   192.9.200.1


   * named-xfer 2次ネ−ムサ−バのゾ−ン転送

    上記の設定により hostA の named を再起動すると、 hostC の named.hosts ファイルを
    hostA に /etc/named.hosts.sec という名前でコピ−してくる。 この時 hostA の named
    デ−モンは named-xfer というプログラムを起動してコピ−する。hostA 側のポ−トは何
    番を使うのか実際調べて見た。調べるには先ず同じサブネット上にあるホストどれでもい
    いから tcpdump を起動しておき、次に hostA の named を再起動する。


                  hostA からのアクセスで任意のポ−トを使っている。
    % tcpdump tcp  ↓
    192.9.200.1.1040 > hostC.cad.nix.co.jj.domain: S 845747510:845747510(0) win 
                                                                     9116 
    hostC.cad.nix.co.jj.domain > 192.9.200.1.1040: S 1617600001:1617600001(0) ack 
                                                      845747511 win 61060 
    192.9.200.1.1040 > hostC.cad.nix.co.jj.domain: . ack 1 win 9116
    192.9.200.1.1040 > hostC.cad.nix.co.jj.domain: P 1:37(36) ack 1 win 9116
    hostC.cad.nix.co.jj.domain > 192.9.200.1.1040: P 1:84(83) ack 37 win 61060
    192.9.200.1.1040 > hostC.cad.nix.co.jj.domain: F 37:37(0) ack 84 win 9116
    hostC.cad.nix.co.jj.domain > 192.9.200.1.1040: . ack 38 win 61060
    hostC.cad.nix.co.jj.domain > 192.9.200.1.1040: F 84:84(0) ack 38 win 61060
    192.9.200.1.1040 > hostC.cad.nix.co.jj.domain: . ack 85 win 9116

    注.日付けの部分はとってある。


   * DNS によるIPアドレスの検索
    
    hostC % ping hostB.nix.co.jj

    hostC % tcpdump
    tcpdump: listening on ec0                                        [0]
    hostC.cad.nix.co.jj.domain > 192.9.200.1.domain: 1 (37)          [a]
    192.9.200.1.domain > hostC.cad.nix.co.jj.domain: 1* 1/0/0 (53)   [b]
    arp who-has 192.9.200.2 tell hostC.cad.nix.co.jj                 [c]
    arp reply 192.9.200.2 is-at 8:?:??:?:??:c1                       [d]
    hostC.cad.nix.co.jj > 192.9.200.2: icmp: echo request            [e]
    192.9.200.2 > hostC.cad.nix.co.jj: icmp: echo reply

                  
    [ 解説 ]

    ・[0] tcpdump に現われる前に、自分自身 hostC の named に hostB.nix.co.jj  を知ら
          ないか、レゾルバが問い合わせをしている。 これは hostC の中で処理されている
          ので、ec0 インタ−フェ−スには現われないのである。

    ・[a] では、hostC の named は知らないので、それを親ドメインの named に送っている。

    ・[b] では親の named から hostC の named に hostB のIPアドレスを答えている。

    ・[c] ではレゾルバが 192.9.200.2 に対してMACアドレスを教えろと要求している。

    ・[d] で 192.9.200.2 はMACアドレスを返答している。

    ・[e] でMACアドレスも分かったので、ping の ICMP パケットを hostB に送っている。
            

    [ 補足説明 ]

    上記の状態で、すぐもう一度同じことをやると [a]..[d] は出ずに、いきなり ICMP パケ
    ットを送る。これは hostC の named に hostB.nix.co.jj  のIPアドレスがキャッシュ
    されるためである。これは [a],[b] が出ないことでわかる。 キャッシュの状況を確認す
    るには、% kill -INT name-Process_ID とやると /var/tmp/named_dump.db ファイルにキ
    ャッシュ・デ−タが記述されるので、hostB のIPアドレスができていることがわかる。

    [c],[d] の部分は、この実験を同じサブネットにホストを配置しているため  ARP 要求を
    出しているのが見えるのである。普通のインタ−ネットの状況では出てこないはずである。


  (4) Cobalt Qube3 の DNS で遊ぶ

   * DNS サ−バで遊んでみる  

    Cobalt にユ−ザ katou で個人用WWWを先ず作っておく。そして Cobalt のネットワ−
    ク関係の設定を、以下のようにする。 内部ネットワ−クのコンピュ−タから、Cobalt の
    WWWサ−バにホスト名( FQDN )でアクセスできるようにする。そのために Cobalt でも
    DNS を稼働させ、Cobalt 自身のホスト名解決をできるようにする。 それに、これまで通
    り外部へのアクセスもホスト名でできるようにする。

        [システム ]->[TCP/IP] で "ホスト名" を "web"、
        "ドメインネ−ム" は "localdomain"。"DNS サ−バ(省略可)" は何も書かない。
        [ネットワ−クサ−ビス] で "DNS サ−ビスを有効にする" にチェック。
        [DNS]->[プライマリサ−ビスを設定] では "web.localdomain A 192.168.1.10"。


         □ hostA' 仮想IP  □ Router                    外向けDNS 202.241.128.3 
         |.3                |.1                         内向けDNS 192.168.1.10
    -----------*------------------------- 202.241.128.0   
             .2|       □ hostA, DNS                      Windows 98 の DNS 検索の設
            -------.2  |192.168.2.1                      定は、これら2つを指定する。
            |hostG|---------------         Windows 98     先に内向けDNSのIPアド
            -------    □ hostB    ■       □            レスを記述した方がいい。
             .2|       | .1       |.10    |.20         
    -----------*----------------------------------- 192.168.1.0
                   Mail-Server   Cobalt, DNS

    ここでは、内部ネットにある Windows 98 パソコンから、CobaltのWWWサ−バにアクセ
    してみる。http://web.localdomain/ が先ずできるか。http://web.localdomain/~katou/
    はどうかな。IPアドレスでもアクセスしてみよう。うまく行ったら Cobalt の DNSサ−
    バの制御ファイル /etc/named/db.localdomain を直接 vi でいじって、localdomain. の
    Aレコ−ドを追加してみる。これで http://localdomain/ だけで、 WWWサ−バにアク
    セスできるようになっているはずだ。


    % telnet 192.168.1.10               << どこか別のUNIXからアクセスしている。
    Cobalt Linux release 6.0 (Carmel)     
    Kernel 2.2.16C7 on an i586
    login: admin                        << login: admin で入って、su で root になる。
    
    /etc/named.conf
    --------------------------------------
    |// BIND8 configuration file        << 自動生成した制御ファイル。 ハンドでいじっ
    |options {                             ておかしくなっても知らないよと英語で、 注
    |  directory "/etc/named";             意書きがある。
    |  // no forwarders defined
    |  // no zone transfer access defined
    |};
    |
    |zone "." {
    |  type hint;
    |  file "db.cache";                 << 相対パスで /etc/named/db.cache ファイルに
    |};                                    なる。file "/db.cache";  としたら絶対パス
    |                                      でル−トからの /db.cache ファイルとなる。
    |zone "0.0.127.in-addr.arpa" { 
    |  type master; 
    |  file "pri.0.0.127.in-addr.arpa"; 
    |};
    |
    |zone "localdomain" {
    |  type master;
    |  file "db.localdomain"; 
    |};

    /etc/named/db.localdomain
    ---------------------------------------------------------------
    |$TTL 86400                         << BIND 8 では TTL 値はちゃんと記述すること。
    |localdomain. IN SOA web.localdomain. admin.web.localdomain. (
    |        994150802 ; serial number
    |        10800     ; refresh
    |        3600      ; retry
    |        604800    ; expire
    |        86400     ; ttl
    |        )
    |localdomain.  IN  NS web.localdomain.
    |localdomain.  IN  A  192.168.1.10  << viで編集して追加した。http://localdomain/
    |                                      だけでアクセスできるようにする。
    |web     in a 192.168.1.10
    |$INCLUDE db.localdomain.include    << 空のファイル。 Aレコ−ドなど追加したけれ
                                           ば、このファイルをいじるということ。

    /etc/named/pri.0.0.127.in-addr.arpa
    ------------------------------------------------------------
    |$TTL 86400
    |0.0.127.in-addr.arpa. IN SOA localhost. admin.localhost. (
    |        2000081417 10800 3600 604800 86400 )
    |0.0.127.in-addr.arpa.   IN      NS      localhost.
    |1       in      ptr     localhost.


    # /usr/sbin/named -v    << バ−ジョン表示。昔の named はこのオプションはなかった。
    named 8.2.2-P5 Wed Jun 14 17:32:48 PDT 2000
        root@zerg.cobalt.com:/home/redhat/BUILD/bind-8.2.2_P5/src/bin/named
    
    /etc/resolv.conf            
    -----------------------
    |#nameserver 127.0.0.1  << 管理画面の[システム]->[TCP/IP] で"DNS サ−バ(省略可)"
    |search localdomain        にIPアドレスを書き込むと、ここに記述される。 この例
    |domain localdomain        では 127.0.0.1 と書き込んでみた場合である。

    /etc/hosts
    ----------------------------------------------
    |127.0.0.1    localhost localhost.localdomain  
    |192.168.1.10 web.localdomain web           << # hostname で web.localdomain と
                                                   なっていることも確認しておこう。 

    /etc/nsswitch.conf         /etc/host.conf   << ファイル名は hosts.conf ではない。
    -----------------------    ------------------
    |passwd:     files         |order hosts,bind
    |   |                      |multi on
    |hosts:      files dns
    |   |


   * ラウンドロビンDNSは

    /etc/named/db.localdomain
    ---------------------------------------------------------------
    |$TTL 86400
    |localdomain. IN SOA web.localdomain. admin.web.localdomain. (
    |   |    )
    |localdomain.  IN  NS web.localdomain.
    |                                    
    |web     in a 192.168.1.10
    |web     in a 192.168.1.11          << 同じIPアドレスでAレコ−ドを追加する。
    |$INCLUDE db.localdomain.include       Cobalt の管理画面からそのまま追加できる。

    もう1つ Cobalt なりEWSを用意するなりして、とりあえず 192.168.1.11 でWWWサ
    −バを稼働させておく。そして内部ネットの Windows 98、同一のパソコンから DOS 窓で、 
    C:\WINDOWS>ping web.localdomain と繰り返し打ってみる。192.168.1.10を返す時もあれ
    ば 192.168.1.11 を返す時もある。交互にIPアドレスが出て来るのが、本当のような気
    がするのだが。一応ラウンドロビンDNSの機能は働いているようである。


  (5) DNS 挙動の微妙なところ  `24/04

   * この事例はいかに

    http://jprs.jp/tech/ にある「DNS再入門」"Internet Week 2002/DNS DAY"、P.13 自
    分のゾ−ン以外のNS指定設定例2(すべてのDNSサ−バが外部名)、 2002/12/19 森下
    泰宏氏作成。に記述されていることから。aaa.con ドメインのネ−ムサ−バはレジストリ
    に 192.168.1.1 で登録されている。ユ−ザがホスト www.aaa.con にアクセスしようとす
    ると、先ず 192.168.1.1 のネ−ムサ−バを見にいく。すると ns.bbb.con と ns.ccc.con 
    の2つのホストがあり、ラウンドロビンかランダムにホスト ns.bbb.con を見るようにと
    返事があった。多分ラウンドロビンで選ばれるのだろう。bbb.con ドメインのネ−ムサ−
    バは 192.168.2.1 でレジストリに登録されている。そこには確かに aaa.con ゾ−ンの情
    報があって、www.aaa.con は 192.168.1.2 であると返事が来た。という流れ。


    aaa の named.conf                      192.168.1.1  .2       192.168.2.1 
    ------------------------                    □      □ www       □
    |zone "aaa.con" {                           |      |           |
    |   type master;                        ----------------      ---------
    |   file "named.hosts";                   aaa.con              bbb.con
    |};                               

        aaa の named.hosts
        -------------------------------------------
        |$TTL 86400
        |@  IN SOA ns.aaa.con. admin.ns.aaa.con. (
        |      .. )
        |   IN NS  ns.bbb.con.      << aaa.conドメインのゾ−ン情報を管理するのはこの
        |   IN NS  ns.ccc.con.      << 2つ。aaa.con ではないことに注意したい。
        |ns IN A   192.168.1.1

        aaa.con ドメインのゾ−ン情報は、 ns.aaa.con 192.168.1.1 にオ−ソリティを上位
        ドメインの con によって与えられている。つまり管理の権限を委譲されている。 し
        かし実際は aaa.con のゾ−ン情報は、ns.bbb.con と ns.ccc.con が持っている。例
        えてみれば建設業者の丸投げみたいな話である。

    
    bbb の named.conf            bbb の named_a.hosts
    -------------------------    -------------------------------------------
    |zone "bbb.con" {            |$TTL 86400     
    |   type master;             |@   IN SOA ns.aaa.con. admin.ns.aaa.con. (
    |   file "named_b.hosts";    |       .. )   
    |};                          |    IN NS  ns.aaa.con.           
    |                            |ns  IN A   192.168.2.1
    |zone "aaa.con" {            |www IN A   192.168.1.2
    |   type master;
    |   file "named_a.hosts";       
    |};                               


   * 上の事例からのハテナ

    以下のような設定、よくある典型的なネ−ムサ−バの設定である。これで、このネ−ムサ
    −バを指定したクライアントは、 ネ−ムサ−バ ns.aaa.con と ns.provider.con どちら
    かで名前解決がされる。ということなのだろうか。/etc/resolv.conf で 192.168.1.1 を
    指定したにも関わらず、 このネ−ムサ−バは実際の名前解決を ns.provider.con に回す
    かも知れない。もしそうなら、ゾ−ン情報を変更したような場合、マスタ−の変更がスレ
    −ブに反映されるまでの間 ns.provider.con は、古いゾ−ン情報を出すことになる。 多
    分問い合わせ情報が、先ずそのネ−ムサ−バのキャッシュにあるか調べるのだろう。自分
    自身のドメインのゾ−ン情報はキャッシュに持っている。それですぐに問い合わせホスト
    のIPアドレスが返されるので、問題になるようなことはないのだろう。

    1) クライアントが www.iij.ad.jp にアクセスしたいと問い合わせた場合。

      ネ−ムサ−バ ns.aaa.con は、すぐル−トキャッシュから上位ネ−ムサ−バに問い合わ
      せ、検索にかかる。

    2) クライアントが www.aaa.con にアクセスしたいと問い合わせた場合。

      www.aaa.con は自ドメインのホストである。ネ−ムサ−バ ns.aaa.con は www.aaa.con 
      のIPアドレスをキャッシュしているので、すぐにそれを返答する。

    3) クライアントが ftp.aaa.con にアクセスしたいと問い合わせた場合。

      ftp.aaa.con は自ドメインのホストだが、ネ−ムサ−バ ns.aaa.con には ftp.aaa.con
      はない。ns.provider.con のネ−ムサ−バにも問い合わせに行くことになる?。


    aaa の named.conf                      192.168.1.1  .9
    ------------------------                    □      □ www
    |zone "aaa.con" {                           |      |
    |   type master;                        -------------------------------
    |   file "named.hosts";                   aaa.con             |
    |};                                                           □クライアント
                                           
        named.hosts                                          /etc/resolv.conf
        -------------------------------------------          -----------------------
        |$TTL 86400                                          |nameserver 192.168.1.1
        |@  IN SOA ns.aaa.con. admin.ns.aaa.con. (
        |      .. )
        |    IN NS  ns.aaa.con.         << 自分がゾ−ン情報もっている。
        |    IN NS  ns.provider.con.    << プロバイダにスレ−ブになってもらった。
        |ns  IN A   192.168.1.1
        |
        |www IN A   192.168.1.9


   * 複数ドメインを管理する DNS の図

    マシン<3> の DNS は自身のドメイン Y と、他ドメインX の情報も管理させるものとする。
    マシン<1> からホスト名 2.X にアクセスしたい。 マシン<1> は先ず <3> の DNS を見て
    2.X に対応するIPアドレスを検索する。もし<3> の DNS が止まっていたら <4> の DNS 
    を見る。この検索にあたっては 1.Y、1.Z ホストの resolv.conf はなくても関係ない。

             ドメインX          ドメインB       ドメインC
                              
             □     □           DNS □          DNS □        p  : primary
          1.X|  2.X|     |      1.Y|      |    1.Z|        s  : secondary
        -------------------|-----------------|--------------   :IPアドレス
            <1>    <2>     |       <3>       |      <4>

        <1>/etc/resolv.conf  <3>named.boot        <4>named.boot
        -------------------  -----------------    -----------------
        |nameserver <3>      |p Y named.hostsY    |p Z named.hostsZ
        |nameserver <4>      |p X named.hostsX    |s Y named.hostsY
                                                  |s X named.hostsX
                                                     
                             <3>named.hostsY      <4>named.hostsZ
                             -----------------    -----------------
                             |Y   SOA 1.Y         |Z   SOA 1.Z
                             |Y   NS  1.Y         |Z   NS  1.Z
                             |1.Y A   <3>         |1.Z A   <4>
                                                
                             <3>named.hostsX    
                             -----------------  
                             |X   SOA 1.Y   << ドメインX を管理しているのは、ホスト
                             |X   NS  1.Y   << 1.Y であり、大元のネ−ムサ−バである。
                             |;X  NS  1.Z   << もう1つのネ−ムサ−バはこれと、宣言
                             |1.X A   <1>      しているだけの意味しかない。記述しな
                             |2.X A   <2>      くても特に問題はないと思われる?。

   * IPアドレスの問い合わせの流れ

    ================================================================================
    1996年当時、DNSを勉強した時、DNSの動きを以下のように理解したのだったが、
    どうも違うみたいである。ネ−ムサ−バがリレ−して行って最終的に答えを返してくれる
    というモデルだと思ったのだが。確かに問い合わせをフォワ−ド、フォワ−ドしていけば
    そういうことになるのだが。フォワ−ドはロ−カルなネ−ムサ−バ間での話で、インタ−
    ネット全体の話ではない。インタ−ネットでのDNSの問い合わせの動きは、よく雑誌で
    図示されている。そちらを参考にして頂きたい。ともかくリレ−ではなく、下の絵ではホ
    ストCのネ−ムサ−バとそれゾレのネ−ムサ−バはピンポン見たいにやり取りして、最終
    的にホストXのネ−ムサ−バから Z.b のIPアドレスを引き出す。 ゾ−ン転送、と正引
    き逆引きの問い合わせについてのパケットの種類とポ−ト番号は合っていると思う。
    ================================================================================


Fig. d11

    ※ ゾ−ン転送の named-xfer はBからCへのアクセスである。Bは任意ポ−ト、C
       は TCP/53 を使う。転送するかどうかのチェックには、両者 UDP/53 を使う。

    ホストDが ホストZにアクセスする場合を考える。D.c.a % ping Z.b というアクセスで
    ある。このためには Z.b ドメイン名のIPアドレスを知らなければならない。 ホストD
    のレゾルバは、先ず自ドメインを管理しているホストCの named デ−モンに尋ねる。 こ
    の named は知らないため、 named が上位のドメインを管理しているホストBに問い合わ
    せて行く。named がリレ−して尋ねていってくれて、 最終的にホストXの named がホス
    トCの named に、ホストZのIPアドレスを答える。そしてホストCの named からホス
    トDのレゾルバに答えが返されることになる。

    ホストCの named に、ホストZのIPアドレスが他の named から応答されると、ホスト
    Cの named は同じ問い合わせを繰り返さないように、 ある時間その情報をキャッシュす
    る。ここでレゾルバというのが出てきたが、これは他のホストのIPアドレスを調べるた
    めのライブラリであり、EWSのカ−ネルに組み込まれている。 何げなく telnet hostX
    とか ping hostX とかやるが、ホスト名からIPアドレスを検索するために、内部ではレ
    ゾルバというのが働いているのである。

    使用するポ−トは、ホストDのレゾルバからホストCへの問い合わせの際は、UDP/任意ポ
    −トから UDP/53 ポ−トへのアクセスとなる。named 同士のやり取りは UDP/53 ポ−トを
    双方使う。このことはパケットフィルタリングする場合に必要な知識である。


        ホストD --->  ホストC ---> ホストB ---> ホストA ----> ホストX

       ( resolver )    ( named )     ( named )     ( named )      ( named )
      UDP/任意ポ−ト UDP/53  UDP/53                                UDP/53
            ↑          |  ↑                                        |
             ――――――    ―――――――――――――――――――――
                  IPアドレスを答える                                                        

    --------------------------------------------------------------------------------
    「ファイアウォ−ル構築」P.293〜を見ていたら UDP で問い合わせが失敗したら、今度は
    TCP でやると書いてあった。named の関係でクライアント側は、任意ポ−ト TCP/1024 以
    上の番号で、サ−バ側は TCP/53 を使うとしている。それにマシンへの実装によって、ど
    うも少し変えている場合もあるみたいだ。サ−バ側ポ−トは 53 番であることは間違いな
    い。パケットフィルタリングの場合、ル−ル設定は緩やかにした方が無難かも知れない。
    --------------------------------------------------------------------------------