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 番であることは間違いな
い。パケットフィルタリングの場合、ル−ル設定は緩やかにした方が無難かも知れない。
--------------------------------------------------------------------------------