
 13-4. ＤＮＳの動作を調べる  

  (1) DNS キャッシュデ－タ   '96～

   * キャッシュデ－タとは

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


   * キャッシュデ－タの例

    ロ－カルでのみ使う 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    record specific information
    |@               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 やるまで３３秒
    ( 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 レ
    コ－ドが、ホスト名に対応するＩＰアドレスであり、nix.co.jj ドメインのオ－ソライズ
    されたデ－タである。 逆引きデ－タについても $ORIGIN 1.168.192.in-addr.arpa. とあ
    れば、192.168.1.0 ネットワ－クのホストＩＰアドレスを管理してますということである。
    そして上位ドメイン、つまりインタ－ネット上では、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 について気付いたこと。 この値を６０秒や１０秒にしてテ
    ストをやっていたところ、 問い合わせをした named サ－バにキャッシュされる時間がそ
    うならない。どうも５分が最低で、それ以下の値だと５分にしてキャッシュするようであ
    る。下のようなミニ・インタ－ネットで確認してみた。DNS のクライアントのホストから
    例えば $ ping D1.ddd.jj とやれば、ホスト E0 の named サ－バに D1.ddd.jj のＩＰア
    ドレスを問い合わせる。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 のキャッシュ時間は５分。
                              D2.ddd.jj のキャッシュ時間は１０分。

    ホスト 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      フォルトでこの値、６０秒をとる。
         ↑
        D2.ddd.jj はキャッシュ時間を６００秒と指定した。


  (2) nslookup コマンドと dig

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

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

    % nslookup                          << nslookup は、自ホストの /etc/resolv.conf
    Default Server:  hostC.sub.nix.co.jj   ファイルに書かれているＩＰアドレスのネ－
    Address:  192.9.200.6                  ムサ－バにアクセスする。
                                           
    > set all                           << set all は nslookup コマンドの問い合わせ
    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=                            ※querytype=A というのは、現在の問い合わせ
      srchlist=                            は > set type=a を指定しているということ。
    
    > set type=any                      << set type=any とやってドメイン名を入れると、
    > sub.nix.co.jj                        そのドメインの SOA と NS レコ－ド情報が出
    Server:  hostC.sub.nix.co.jj           て来る。set type=xx はこの他、a や ptr な
    Address:  192.9.200.6                  ど幾つかある。 set type=xx は set q=xx と
                                           しても同じである。xx 部は大文字でもいい。
    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  << 逆引きレコ－ドをみる。ＩＰアドレスを入れる。
    > 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 のＩＰアドレスを問
    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                   << ２回目、問い合わせたところ。 このネ－ムサ
    Server:   hostC.sub.nix.co.jj          －バは hostB.nix.co.jj のＩＰアドレスを覚
    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            << ＩＰアドレスを入れてもいい。
    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]


   * dig コマンドをパソコンで使う  `2g/07

    --------------------------------------------------------------------------------
    ＤＮＳを触り始めた頃、BIND の実装には dig コマンドはまだ無かった。いつから入った
    のかは定かではない。nslookup にはない応答時間も dig は出せる事を知って重宝してる。
    --------------------------------------------------------------------------------

    ＤＮＳの応答時間が長いとホ－ムペ－ジの表示に時間がかかることになる。どこのＤＮＳ
    を見るようにするかによってそれは左右される。 ＤＮＳの応答時間は dig コマンドで出
    てくる Query Time がそうである。 nslookup コマンドでは出ない情報で恥ずかしいこと
    に nslookup コマンドを打つなり、ブラウザからサイトが出てくる時間を心の中で１、２、
    ３と数えていた。今テストで使っている FortiGate v5.2.8 にはコマンドの nslookup と 
    dig が見当たらない。 前に FortiGate で nslookup は使ったことがあったように思うが。
    メ－ルリレ－の予備のマシンで Solaris9 に BIND の named をインスト－ルして dig コ
    マンドは入っている。このマシンはすぐ横に置いているがＤＭＺ設置な訳で、手元で使う
    には、ＩＰアドレスを社内ネットワ－クのに替えないといけない。Windows 7 でフリ－ソ
    フトの dig とかないか。探してみたがなさそう。パソコン用の BIND に入っている。

    パソコン用の dig は BIND を入れて、その中にあるのを使うしかない。 ちょっと大仰な
    話になる？、いや案ずるが生むが易しどうってことなかった。 BIND のサイトから安定版
    をダウンロ－ドしてくる。 デスクトップに BIND9.10.4-P2.x86 というフォルダができた。
    その中の BINDinstall.exe を実行、C:\Program Files\BIND9\ に入れるようにした。 小
    さな画面で Microsoft Visual C++, Redistributable(x86), Modify Setup と書かれたの
    がでてきたが右上の X をクリックし無視。 その後すぐに BIND installation completed 
    successfully と画面がでた。C:\Program Files\BIND9\bin\ に入り、 dig.exe をクリッ
    クしたらル－トＤＮＳのヒントファイルの内容が出てきた。 Visual C++ の実行環境がい
    るような雰囲気だが、気にせずインスト－ルして無しで使えた。これで自社ＤＮＳサ－バ、
    プロバイダのＤＮＳサ－バなど幾つかで、ＤＮＳの応答時間を計ってみるとしよう。

    >cd c:/program files/bind9/bin      ここから下は `2h/02/S 追記。
    >dig www.tcp-ip.or.jj
    ; <<>> DiG 9.10.4-P2 <<>> www.tcp-ip.or.jj
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2133
    ;; flags: qr rd ra: QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
        |
    ;; QUESTION SECTION:
    ;www.tcp-ip.or.jj.          IN  A
    ;; ANSWER SECTION:
    www.tcp-ip.or.jj.   300     IN  A   157.14.xxx.yyy  ※パソコンのネットワ－ク設定
        |                                                 でＤＮＳ 202.241.128.3指定。
    ;; Query time: 31 msec
    ;; SERVER: 202.241.128.3.65#53(202.241.128.3)
        |

    >dig @202.241.128.3 www.tcp-ip.or.jj  も同じこと。
    ; <<>> DiG 9.10.4-P2 <<>> @202.241.128.3 www.tcp-ip.or.jj
    ; (1 server found)

    >dig
    ; <<>> DiG 9.10.4-P2 <<>> 
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4855
    ;; flags: qr rd ra: QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
        |
    ;; QUESTION SECTION:
    ;.                          IN  NS
    ;; ANSWER SECTION:
    .                   340733  IN  NS  h.root-servers.net.   ※ル－トのＤＮＳサ－バ
        |                                                       が13個列挙されている。
    .                   340733  IN  NS  j.root-servers.net.
    ;; ADDITIONAL SECTION:
    i.root-servers.net. 427133  IN  A   192.36.148.17
        |

    >dig @IPprovider1_dns www.tcp-ip.or.jj 
        |
    ;; flags: qr rd: QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available
        |
    ;; Query time: 41 msec      ※IPprovider1_dns は契約プロバイダだが、契約回線から
    ;; SERVER: IPprovider1_dns    でないと設置ＤＮＳサ－バが利用できない代物。問合わ
        |                         せ時間は出ているが ANSWER SECTION:の結果は出てない。


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

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

    nix.co.jj の１次ネ－ムサ－バ                  
    cad.nix.co.jj の２次ネ－ムサ－バ              １本のネットワ－ク・セグメントを２
        -------                                   つのドメインに分ける。上位、下位ド
        |hostA| named                             メインを設定した。DNS の論理階層構
        -------             □ hostB              造である。２本のネットワ－クの間に
       ec0 | 192.9.200.1    ｜192.9.200.2         ゲ－トウェイがないことに注意したい。
       ----*------------------------------
                  |
                  |       ------- cad.nix.co.jj の１次ネ－ムサ－バ   
                  |       |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 ２次ネ－ムサ－バのゾ－ン転送

    上記の設定により 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 <mss 1420>
    hostC.cad.nix.co.jj.domain > 192.9.200.1.1040: S 1617600001:1617600001(0) ack 
                                                      845747511 win 61060 <mss 1460>
    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 によるＩＰアドレスの検索
    
    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 のＩＰアドレスを答えている。

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

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

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

    [ 補足説明 ]

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

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


   * snoop コマンドでも詳しく見てみた  `28/08

    JPドメインの    nix.co.jjのDNS  www.nix.co.jj                  JP DNS  nix.co.jj
      □ル－ト            □          □                           のroot  のDNS     
      ｜210.138.175.244   ｜2.2.2.2   ｜1.1.1.1                         (53)
    ---------------------------------------      hostA'               ↑｜   ↑｜               
    |                                     |        □                3｜｜4  ｜｜ 
    ---------------------------------------        ｜.3               ｜｜  5｜｜6
        ：                                       -------------        ｜↓   ｜↓
        □       hostA'□ 仮想ＩＰ                (53)     |(59503)     (39081)
        ｜             ｜.3                       ↑｜     |    2――→     □hostA
    -------------------------- 202.241.128.0     1｜｜8 ---@---  ←――7(53)｜
              ｜  hostA□ DNS (BIND 9.4.2)        ｜↓  |hostG|------------------ 
            .2｜.2     ｜.1                      (2138) -------  
    PC△ hostG□-------------- 192.168.2.0        PC△     |     PC は FireWall-1 で
      ｜      ｜.2                                  ｜     |     Hide behind Gateway
    -------------------------- 192.168.1.0       -----------------


    3)4)5)6) のパケットは hostA で見ると、 発信元 39081番ポ－トから外の 53番ポ－トと
    やりとりしている。hostG の @ インタ－フェ－スで見ると、 ＩＰアドレスが変換されて 
    202.241.128.3 の 39081番ポ－トから外の 53番ポ－トとやりとりしていると出る。 発信
    元 39081番ポ－トのことは "13-7.BIND 8,9 系列での設定" を見られたい。一応 39081番
    は固定だが、59503 と 2138 は 1024 以上の任意番号で例えばである。
    
    3)4) でル－トＤＮＳのＩＰアドレスを問い合わせしている。 210.138.175.244 がすぐに
    返事がかえっている。これは hostA のＤＮＳサ－バが JPドメインの情報をキャッシュし
    ていたためと考えられる。http://www.dns.jp/index-i.html の "JP DNSサ－バについて"、
    に a.dns.jp b.dns.jp d.dns.jp e.dns.jp f.dns.jp の記述があり運用ＩＰアドレスも書
    かれている。d.dns.jp は 210.138.175.244 と書かれている。


    PC> ping www.nix.co.jj

    hostA# snoop -r -V -d bge0           < -V で詳しく出て来る。以下表示は一部省略 >

    2) パソコン PC から自社のＤＮＳの hostA へ問い合わせ
    ________________________________
    202.241.128.2 -> 192.168.2.1    ETHER Type=0800 (IP), size = 73 bytes
    202.241.128.2 -> 192.168.2.1    IP  D=192.168.2.1 S=202.241.128.2  ID=11540
    202.241.128.2 -> 192.168.2.1    UDP D=53 S=59503
    202.241.128.2 -> 192.168.2.1    DNS C www.nix.co.jj. Internet Addr ?

    3) 自社のＤＮＳからル－トのＤＮＳへ問い合わせ
     192.168.2.1 -> 210.138.175.244 IP  D=210.138.175.244 S=192.168.2.1  ID=27237
     192.168.2.1 -> 210.138.175.244 UDP D=53 S=39081
     192.168.2.1 -> 210.138.175.244 DNS C www.nix.co.jj. Internet Addr ?

    4) ル－トＤＮＳから nix.co.jj のＤＮＳのＩＰアドレスを返してきた
    210.138.175.244 -> 192.168.2.1  IP  D=192.168.2.1 S=210.138.175.244  ID=33526
    210.138.175.244 -> 192.168.2.1  UDP D=39081 S=53
    210.138.175.244 -> 192.168.2.1  DNS R 

    5) 自社のＤＮＳから nix.co.jj のＤＮＳへ www.nix.co.jjのＩＰアドレスを問い合わせ
     192.168.2.1 -> 2.2.2.2         IP  D=2.2.2.2 S=192.168.2.1  ID=59299
     192.168.2.1 -> 2.2.2.2         UDP D=53 S=39081
     192.168.2.1 -> 2.2.2.2         DNS C www.nix.co.jj. Internet Addr ?

    6) nix.co.jj のＤＮＳから www.nix.co.jj のＩＰアドレスは 1.1.1.1 と返事
    2.2.2.2 -> 192.168.2.1          IP  D=192.168.2.1 S=2.2.2.2  ID=44311
    2.2.2.2 -> 192.168.2.1          UDP D=39081 S=53
    2.2.2.2 -> 192.168.2.1          DNS R www.nix.co.jj. Internet Addr 1.1.1.1

    7) 自社のＤＮＳからパソコンへ www.nix.co.jj のＩＰアドレスを返事
     192.168.2.1 -> 202.241.128.2   IP  D=202.241.128.2 S=192.168.2.1  ID=32003
     192.168.2.1 -> 202.241.128.2   UDP D=59503 S=53
     192.168.2.1 -> 202.241.128.2   DNS R www.nix.co.jj. Internet Addr 1.1.1.1


  (4) Cobalt Qube3 の DNS で遊ぶ

   * DNS サ－バで遊んでみる  

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

        [システム ]->[TCP/IP] で "ホスト名" を "web" とした。

        "ドメインネ－ム" は "localdomain"。"DNS サ－バ(省略可)" は何も書かない。

        [ネットワ－クサ－ビス]->[DNS] のメニュ－で "DNS サ－ビスを有効にする" に
        チェック。チェックするとその都度、新たに /etc/named.conf を作る事に注意。

        [DNS]->[プライマリサ－ビスを設定] では "web.localdomain A 192.168.1.10"。


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

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

    % telnet 192.168.1.10               << どこか別のＵＮＩＸからアクセスしている。
    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/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
    |   |


   * ラウンドロビンＤＮＳは

    # hostname                                     Apollo  PC   Qube3   WWW    WWW
    qube3.nix.co.jj                                  □    □    ■     □     □
                                                     ｜    ｜    ｜.10  ｜.11  ｜.12
    /etc/hosts                                     ---------------------------------
    --------------------------------------------
    |127.0.0.1    localhost localhost.nix.co.jj       WWW のホストはＷＷＷサ－バでな
    |192.168.1.10 qube3.nix.co.jj qube3               くてもいい。ただのホストでいい。
                                                      pingに応答する物なら何でもＯＫ。
    /etc/named/db.nix.co.jj                                          
    -------------------------------------------------------------
    |$TTL 86400
    |nix.co.jj. IN SOA qube3.nix.co.jj. admin.qube3.nix.co.jj. (
    |   | 略  )
    |nix.co.jj. IN  NS qube3.nix.co.jj.
    |                                    
    |www     in a 192.168.1.11
    |www     in a 192.168.1.12          << 同じＩＰアドレスで Aレコ－ドを追加する。
    |$INCLUDE db.nix.co.jj.include         Cobalt の管理画面からそのまま追加できる。

        ----------------------------------------------------------
        |プライマリサ－ビスのリスト                              |  Clobat Qube3の画
        |--------------------------------------------------------|  面でＤＮＳの制御
        |( SOAを修正 ) (全レコ－ドを削除)                        |  ファイルの記述が
        |--------------------------------------------------------|  簡単にできる。こ
        |   問い合わせ       レコ－ドの種類       回答      詳細 |  れだけの設定でdb
        | www.nix.co.jj      A                192.168.1.11       |  .nix.co.jjという
        | www.nix.co.jj      A                192.168.1.12       |  ファイルができる。
        ----------------------------------------------------------

    Apollo と PC のＤＮＳ設定のＩＰアドレスは 192.168.10.10 にする。それぞれのホスト
    から ping www.nix.co.jj と打ってみる。最初 PC から打ったら 192.168.1.11 が返って
    きて、次に Apollo から打ったら 192.168.1.12 が返ってきた。その後、何度やってもPC 
    からは 11 が、Apollo からは 12 が返ってきた。 ＤＮＳのラウンドロビン機能というの
    はどうも異なるホストからのアクセスには、異なるＩＰアドレスを返すということらしい。
    以前やった時のテストでは PC から C:\>ping www.nix.co.jj と繰り返し打ったら、11を
    返す時もあれば 12 を返す時もあったような気がする。もしできればうれしいことがあっ
    たのだが、それはこれらがＷＷＷサ－バで 11 にアクセスしたが止まっていた、それでも
    う１つのＩＰアドレスの方 12 にアクセスが行くということ。これはできない。


   * Qube3 の dig コマンドを使う  `2h/11/e

    管理画面の [ネットワ－クサ－ビス]->[DNS] のところ "DNSサ－バを有効にする" に〆し
    た。[システム]->[TCP/IP] 画面の "DNSサ－バ(省略可)" の所に [127.0.0.1 ] と記入し
    た、/etc/resolv.conf に "nameserver 127.0.0.1" が記載された。Qube3にパソコンから 
    telnet で入り dig コマンドを叩いた。ＤＮＳのル－トファイルは /etc/named/db.cache 
    である。ファイルの作成日は "last update: Aug 22, 1997"でだいぶル－トＤＮＳのＩＰ
    アドレスは変わっていた。A.ROOT-SERVERS.NET. は変わらず、B.ROOT-SERVERS.NET. は変
    わっていた。dig コマンドで同じサイトを叩くと、２回目は Query Time は数 msec にな
    り、でキャッシュされた情報を返すので速い。

    $ cat /etc/resolv.conf
    # /etc/resolv.conf
    # Auto-generated file.  Keep your customizations at the bottom of this file.
    nameserver 127.0.0.1
    search mydomain
    domain mydomain
    #END of auto-generated code.  Customize beneath this line.

    $ ps -ef | grep named
    root     18437     1  0 08:35 ?        00:00:00 named

    $ which dig
    /usr/bin/dig

    $ dig @127.0.0.1 www.iij.ad.jp
    ; <<>> DiG 8.2 <<>> @127.0.0.1 www.iij.ad.jp 
    ; (1 server found)
    ;; res options: init recurs defnam dnsrch
    ;; got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
    ;; QUERY SECTION:
    ;;  www.iij.ad.jp, type = A, class = IN
    
    ;; ANSWER SECTION:
    www.iij.ad.jp.      5M IN A     202.232.2.164    << ここにキャッシュされる時間が
                                                        表示されている。5Mは５分であ
    ;; AUTHORITY SECTION:                               る。この時間は iij.ad.jpを管
    iij.ad.jp.      1D IN NS    dns1.iij.ad.jp.         理するＤＮＳサ－バが決める。
    iij.ad.jp.      1D IN NS    dns0.iij.ad.jp.
    
    ;; ADDITIONAL SECTION:
    dns0.iij.ad.jp.     1D IN A     210.130.0.5
    dns1.iij.ad.jp.     1D IN A     210.130.1.5
    dns0.iij.ad.jp.     1D IN AAAA  2001:240::105
    dns1.iij.ad.jp.     1D IN AAAA  2001:240::115
    
    ;; Total query time: 44 msec
    ;; FROM: qube0.mydomain to SERVER: 127.0.0.1
    ;; WHEN: Thu Nov 23 08:44:53 2017
    ;; MSG SIZE  sent: 31  rcvd: 173


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

   * この事例はいかに

    http://jprs.jp/tech/ にある「ＤＮＳ再入門」"Internet Week 2002/DNS DAY"、P.13 自
    分のゾ－ン以外の NS指定設定例２(すべてのＤＮＳサ－バが外部名)、2002/12/19 森下泰
    宏氏作成。に記述されていることから。aaa.con ドメインのネ－ムサ－バはレジストリに
    192.168.1.1 で登録されている。 ユ－ザがホスト www.aaa.con にアクセスしようとする
    と 先ず 192.168.1.1 のネ－ムサ－バを見にいく。すると ns.bbb.con と ns.ccc.con の
    ２つのホストがあり、ラウンドロビンかランダムにホスト 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.      << ２つ。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 は、古いゾ－ン情報を出すことになる。 多
    分問い合わせ情報が、先ずそのネ－ムサ－バのキャッシュにあるか調べるのだろう。自分
    自身のドメインのゾ－ン情報はキャッシュに持っている。それですぐに問い合わせホスト
    のＩＰアドレスが返されるので、問題になるようなことはないのだろう。

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

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

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

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

    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 に対応するＩＰアドレスを検索する。もし<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
        -------------------|-----------------|--------------   <x>:ＩＰアドレス
            <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.X A   <1>      しているだけの意味しかない。記述しな
                             |2.X A   <2>      くても特に問題はないと思われる？。�


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

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

                                                ゾ－ン転送の named-xfer はＢからＣへ
                         named                  のアクセスである。Ｂは任意ポ－ト、Ｃ
                         -----                  は TCP/53 を使う。転送するかどうかの
                         | A |                  チェックには、両者 UDP/53 を使う。
                         ----- A.                                   
                           |                                         
          -----------------*----------------- root ドメイン
               |                       |
               |     named             |    named
               |    -----              |    -----    -----
               |２次| B |              |    | X |    | Z |
               |    ----- B.a          |    -----    -----
               |      |                |      |        |
       ---------------*---  a      -----------*--------*----  b  
         |                        
         |                        
         |       named            
         |       -----    ----- /etc/resolv.conf
         |  １次 | C |    | D | 
         | C.c.a -----    ----- % ping Z.b
         |         |        |         
      -------------*--------*----  c.a       


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

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

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


        ホストＤ --->  ホストＣ ---> ホストＢ ---> ホストＡ ----> ホストＸ    これは
                                                                              間違い。
       ( resolver )    ( named )     ( named )     ( named )      ( named )
      UDP/任意ポ－ト UDP/53  UDP/53                                UDP/53
            ↑          ｜  ↑                                        ｜
             ――――――    ―――――――――――――――――――――
                  ＩＰアドレスを答える                                                        

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