システム奮闘記：その22

BINDでDNSサーバー構築

はじめに

  DNSの設定。
  さて、設定に関する知識を問われると、いつものように正直に事を書きます。
  
  今まで、本の丸写しで設定していました (^^;;

  なぜ、丸写しだったのか?
　そのわけは・・・

  DNSの本を開けても目が点になるもーん (^^)

  こんな感じだから、DNSに関する知識と言えば、ドメインからIPを調べる
「正引き」と、IPからドメインを調べる「逆引き」しか頭になかった。


  設定変更さえしなければ、本の丸写しでも支障はないと思う (^^;;
  しかし、本の丸写しだと、ちょっとしたDNSのトラブルに対応できなかったり
場合によっては、パニックに陥る。
  つまり、眠れる獅子を起こすと大変な事になる。

  そこで、眠れる獅子(DNS)が目を覚めしても、対処できるように、
獅子使いならぬ「DNS使い」になる必要が出てくる。


  ところで、1年くらい前までは、ネットワークの知識などが乏しかったため、
例え、本を読んでも目が点になって「わかんない！」で終わっていた。
  しかし、今年になり、いくつあるのか見当すらつかないパンドラの箱を開ける
作業を行なっている。終わりなき自分の知識や技術のボロ出し大作戦を行なっている。
  そのお陰で、ある程度の知識がつき、DNSというパンドラの箱を開ける状態になった。

  まずは、ボロだし大作戦の話をする前にDNSに関する知識がなかったために、
起ったトラブルなどの実話を3つほど、紹介します。


実話1:逆引きが、できへんよ〜

  逆引きの話が出た所で「システム奮闘記・その2」で出てきた話
(Linuxでサーバー構築)と重複しますが、より突っ込んだ内容で
逆引きができない話を書くことにしました。


  2000年、サーバー構築時に、はじめてDNSサーバーを構築した時、
逆引きができなかった。
  その時は、DNSに関する知識がないため、逆引きができない原因が
全くわからずに、止む得ず放置していた。

  逆引きができないために、起った現象として、telnetやftpで
他のホストへの接続に時間がかかっていた事だ。

  しかし、当時は、接続の遅さの原因が、逆引きができなかったためだという事を
全く見当すらつかず、「逆引きができなくても、支障なし！」と思い込んでいた。

  逆引きができるようになったキッカケ。DNSを立ち上げて1年ぐらいたった後、
ある飲み会で、うそぐれす（Usogres）の開発者の細川さんが私に対して
「ログの監視をしていて、ドメインでなく、IPアドレスでの記録があるから
何だろうとJPNICのホームページで調べたら＊＊＊＊会社だった」と言った。
  （＊＊＊＊会社は私の勤務先）

  さすがに、ちょっとカッコ悪いので「逆引きできるようにせにゃ」と思った (^^;;

  しかし、何がどう間違えているのか、さっぱり見当がつかなかった。

  ある日の事、DNSの設定事例を探していたら、うちの会社に似たような
ネットワークの環境の設定を発見した。
  IPアドレスが8つ割り当てられている場合の設定例だった。

  /etc/named.confの中身の記述に問題があった

  本来なら、うちの会社のDNSが管理するIPのゾーンを記述する所だが、
当時、知識がなかったため、本の丸写ししかできず、クラスCの設定と同じように
してしまった。
  ゾーンなどについて、詳しい話は後述しています。

  「秘技・本の丸写し」という方法を使って、設定変更を行なった。
  設定を変更をしたお陰で、逆引きができない問題は解決できた (^^)V

  逆引きができないと、接続が遅くなったりする。
  この時、はじめて逆引きの必要性が理解できた。


実話2:メールの受信障害

  うちの会社がインターネット接続時のサーバー構成は次のような感じだった。

初期のネットの構成

  この時、NATとメールサーバーは兼用になっていた。
  1台のマシンでサーバー機能をてんこ盛りにしていた。

  実は、メールの受信に問題があった。

  メールの受信に時間がかかっていた!

  だいたい20〜30秒くらいかかったりした。
　ひどい時は1分以上かかったり、たまに受信の失敗があった。
  もちろん、なぜなのか調べるだけの知識もなかったため、長年の謎だった。

  この時、逆引きが原因とは、全く想像していなかった。


  その後、ADSL導入時に下図のようなサーバー構成に切り替わった。

ADSL導入後のネットの構成

  この構成にした時から、メールの受信がスムーズになった。
  社内でも「なんで、急にスムーズになったんやろか？」という声があった。

  でも、スムーズになった理由がわからなかった。
  だが、ある時、ふとした事で原因がわかった！

  それは「最新DNS&BIND」（イスクブレイン著：秀和システム）を
パラパラと見ていた時だった。
  P108に「逆引きは必要なのか」の記述があった。

  内容は、POPサーバーが、アクセスしてきたクライアントのIPを見て、
逆引きができないと、メールの受信が遅くなったり、受信拒否をしたりするという。

  これを読んで「なるほど！」と思った。

  初期の設定（と言っても、NAT&メールサーバーは3年近く続いたが）だと、
クライアントのIPは、プライベートアドレスで、メールサーバーにアクセスする。
  プライベートアドレスだと、DNSに登録されていないため、逆引きはできない。
  つまり、逆引きができなかったため、メールの受信に時間がかかったり、
受信ができなかったりしていた。

  ADSLへ切り替えた後、メールサーバーにアクセスする場合、
一度、NATを通過する。IPがNATのグローバルアドレスに変換されている。
  そのため逆引きが可能になり、メールの受信がスムーズにいくようになった。

  ここで、私からのアドバイス。
  NATのマシンで、色々なサーバー機能を持たせると不都合が生じるので、
あまりお勧めできません　 ←　経験者は語る　 (^^;;


実話3:名前解決の最初の問い合わせ先は親サーバーから

  今となっては設定ファイルが残っていないので、原因の追求をするができないが、
DNSサーバーを立ち上げた時、まともに稼働していなかった。

  nslookupのコマンドを打つと次のエラーが出ていた。

[server]# nslookup
*** Can't find server name for address XXX.YYY.ZZZ.RRR: No response from server
*** Default servers are not available

  今になって考えられる理由は、逆引きの設定ができていなかったのが
原因だと思われる。
  実際に、逆引きの設定が正常になった時、このエラーが出なくなった。
  しかし、今となっては証拠がないため、確信は持てない  (^^;;;
  
  この時、困った。なにせDNSサーバーを初めて立ち上げていたのだが、
本の丸写しで、DNSに関する知識がなかった。
  しかし、普通では考えもしない技を見せる私

  回避方法として、resolv.conf のネームサーバーの記述の所を
うちの会社のDNSサーバーのIPではなく、うちの会社が加入していた
プロバイダーのDNSサーバーのIPアドレスを記述した。

  そういうアイデアが出たのは、名前解決の方法について、どこで得た知識が
覚えていないが、次に挙げるような誤解をしていたからだった！！

私が誤解していた「名前解決の方法」
上図の流れの解説(私が誤解していた内容)
(1)	クライアントは、うちの会社のDNSサーバーに問い合わせする。
(2)	うちの会社のDNSではわからないため、coドメインを管理している DNSサーバーに問い合わせする。 (親DNSに問い合わせると思い込んでいた)
(3)	そして、jpドメインを管理しているDNSへ問い合わせる。
(4)	acドメインを管理しているサーバーに問い合わせ
(5)	gaigakuドメインを管理しているDNSサーバーに問い合わせ
(6)	該当のIPがあるので、うちの会社のDNSへ返答する。
(7)	クライアントは該当のIPアドレスを受け取る

  そのため、resolv.confファイルのネームサーバーは親のDNSを書くと思い
プロバイダーのDNSサーバーのIPアドレスを打ち込んだ。

  そうすると・・・

　問題なく稼働した!!

　だった。

  うまく動いたお陰で、DNSを使った名前解決の方法を誤解している事に
気づくのに、3年かかる事になった (^^;;;;

  resolv.confのネームサーバのIPをプロバイダーのDNSサーバーの
IPアドレスを入力していると、次のような現象が起こる。

社内サーバーの検索でも一度は外部へ出ていた (^^;;
名前解決の際、最初にプロバイダーのDNSサーバーに 問い合わせる形になっていた。そのため社内のドメインでも 一度はプロバイダーに問い合わせるようになっていた。 もし、プロバイダーのDNSサーバーが障害を起こして 動いていない場合、社内で名前検索ができなくなる問題があった。

　案の定、プロバイダーのDNSサーバーが障害を起こすと

  社内でネットが使えなくなる!!

  困った事に、社内間のメールも使えなくなる。


  私が設定間違いをしているため、こういう事態になるのだが、
当時は、自分が間違いをしているとは夢にも思っていなかった。

  そのため障害が起こる度に・・・

　プロバイダーは、軟弱なサーバーを使っているのか!

　と思っていた。
  プロバイダーに電話して

　おたくのDNSがコケているのですが・・・

　と切り出して早く復旧するように要請した。
  こういう時、ちゃっかりしていて、pingが通らない証拠も用意していた。
  
  月に2、3回の割合でプロバイダーのDNSが動かなくなる事もあった。
  でも、プロバイダーの対応は丁寧だったので、私も、普通に復旧を要請していた。


  しかし、一度、ケンカになりかけた事があった。
  
  プロバイダーに電話した時だった。

  確かに、今、思えばプロバイダーは関係ないはずなのだが
当時は、私が間違った設定をしているとは思っていなかった上
過去に、何度かプロバイダーのDNSが障害で動かなかった事があるため
次のように言い放った。

　うちのDNSの親は、おたくでしょ!

　おたくのサーバーがコケると、うちは何もできなくなるんだよ!

　だいたい、過去に何度もサーバーをダウンさせていながら、

　客のせいにするんか！  pingが通らない証拠はあるんや!

　それでもサーバーが落ちている事を、認めへんのか!

　と強い調子で言い返した。


  多分、対応した人は

　こんな、わけのわからん客は困る

　と思っていただろう (^^;;

  しかし、私は、変な所で知識があって pingが通らない証拠を突きつけているため、
プロバイダー側としても、DNSサーバーが障害を起こしている事を認めざるえない。

  そのため、プロバイダー側は、厄介な客との揉め事を避けたいため、
渋々、DNSサーバーが落ちているの事実を認めた。

　そして私は社内では・・・

  プロバイダーのサーバーが落ちているためで、私の責任ではありません

　と涼しい顔をしていた  (^^;;


  この問題、DNSサーバー構築から1年ぐらいたって、逆引きができるようになり、
resolv.confの中身をプロバイダーのDNSサーバーから、自社のDNSサーバーに
書き換えた時に、解消された。

  しかし、この時、不思議に思っていたことがあった。
  名前解決の問い合わせで、自社サーバーが情報を持っていなかったら、
すぐ上にある親サーバーに問い合わせるものと思い込んでいた。
  そのため、resolv.confに親サーバーの情報を書いていないのに、
どうやって親サーバーを見つけて、DNSが稼働するのかが謎だった。
  でも、うまく稼働していたので「まぁ、ええか」と思って放置していた。
            ↑
　ホンマに、ええんかい！ 管理者失格や！

  その謎（というより誤解）がわかるのは、それから2年ぐらい経った
2003年7月で、DNSの知識のボロ出し作戦を行なってからだった。
       ↑
　つい最近まで誤解していました。敢えて恥をさらします  (--;;;

正しい名前解決の方法
上図の流れの解説
(1)	リゾルバ(自分の所のDNS)へ問い合わせる
(2)	ルート(.)を管理しているDNSサーバーへ問い合わせる。
(3)	jpを管理しているDNSサーバーを紹介してもらう。
(4)	jpを管理しているDNSサーバーに問い合わせる。
(5)	coを管理しているDNSサーバーを紹介してもらう。
(6)	coを管理しているDNSサーバーに問い合わせる。
(7)	kaishaを管理しているDNSサーバーを紹介してもらう。
(8)	kaishaを管理しているDNSサーバーに問い合わせる。
(9)	www.kaisha.co.jpのIPを教える。
(10)	クライアントに、www.kaisha.co.jpのIPを教える。
(注意) キャッシュについては、後述していますので、ここでは 突っ込みを入れないでくださいね (^^)

  この時、はじめて、自社のDNSサーバーに情報がない場合、
はじめに、ルートドメインを管理しているサーバーに問い合わせして、
ドメインの階層の上から下へ検索している事を知った。

  これだと、named.ca というDNS設定ファイルに、ルートネームサーバーの
情報（IPアドレス）が記述されているので、名前解決せずに接続できる。

  3年かけて、DNSの名前解決の仕組みを知るのであった (^^;;


DNSの仕組みの勉強

  そんなこんなで、DNSに関する失敗談(?)を3話ほど紹介しました。

  さすがに、DNSの知識がない状態だと、トラブルが発生しても対応できない。
そこで「最新DNS&BIND」（イスクブレイン著：秀和システム）を片手に
DNSのお勉強を始めることにした。

リゾルバ

  意気揚々と進もうとするが、すぐに用語で立往生した。

  リゾルバって何やねん?

  そこで、本を進めていくことにした。
  リゾルバの綴りは「 resolver 」となる。
  ネットワーク設定の時に、DNSサーバーに設定しているホストの事を言う。
  うちの会社の場合、自社のDNSサーバーが、リゾルバになる。
  英語の綴りを見て、resolv.confの意味がわかった。
  要するに、自分が使うDNSサーバーという意味だ。


  少し賢くなった所で、DNSの名前解決の方法を読む。

  実話3でも紹介しましたように、私はDNSの名前解決の方法を誤解していた。
  Linuxサーバーを立ち上げた後、3年たって誤解が解けた。

正しい名前解決の方法
上図の流れの解説
(1)	リゾルバ(自分の所のDNS)へ問い合わせる
(2)	ルート(.)を管理しているDNSサーバーへ問い合わせる。
(3)	jpを管理しているDNSサーバーを紹介してもらう。
(4)	jpを管理しているDNSサーバーに問い合わせる。
(5)	coを管理しているDNSサーバーを紹介してもらう。
(6)	coを管理しているDNSサーバーに問い合わせる。
(7)	kaishaを管理しているDNSサーバーを紹介してもらう。
(8)	kaishaを管理しているDNSサーバーに問い合わせる。
(9)	www.kaisha.co.jpのIPを教える。
(10)	クライアントに、www.kaisha.co.jpのIPを教える。

  正しいDNSの名前解決の方法を知る。
  しかし、あまり感激はなかった (^^;;

  本には「キャッシュ」という文字があった。
  だいぶ前から、キャッシュがあるのは経験的にある事を知っていた。

> www.nasa.gov.
Server:	        XXX.YYY.ZZZ.RRR
Address:	XXX.YYY.ZZZ.RRR#53

Non-authoritative answer:
www.nasa.gov	canonical name = www.nasa.gov.speedera.net.
・・・・・・・・・・(続く)

  この時、Non-authoritative answer:という文字が出ている。
  私は「権威がない」のを見て、どこかのキャッシュという風に思った。
  結果的には、正しい推測だった。DNSにはキャッシュ機能がある。
本を読むと、全ての名前解決で、ルート（.）へ問い合わせを行なうと
ルートを管理するDNSがパンクしてしまう。
  そこで、混雑緩和のため、キャッシュを設けている。

　ところで、この時・・・

  「権威」って何やねん?
 
　知らない事だらけなのだ。「権威」については、後述しています。

  この時、キャッシュの部分は、深く突っ込まなかった。
  特に、キャッシュさせる時間についてなどは考えていなかった。

FQDN

  先へ進むことにした。また、用語で立往生。

  ところで、FQDNって何？

  最近になって「FQDN」の用語をよく見る。
  でも、今まで調べなかった　(^^;;  ←　おい！

  この際だから、知らない用語は潰しておこうと思った。
  FQDNとは完全なるドメイン名という意味だという。

  だから、FQDNは何やねん?

  というので本をしっかり見ることにした。
　つまり、こういう事だった。

  ピリオドはDNSの階層構造の頂点を意味している。

ドメインの階層構造
一番上にあるのがルート（.）となる。 普通、トップはjpやcomなどを考えそうだが、ルートが存在している。

  普通なら省略可能なピリオドだが、nslookupコマンドを利用する時は、
完全なるドメイン名でないと、エラーがでる。
  BINDの設定などでも完全なるドメイン名（FQDN）を使う必要がある。

  今まで、ピリオドを付ける理由が全くわからなかったが、
ここにきて、ようやく理解できた  (^^)V


  次に「ドメイン」と「ゾーン」という言葉が出てきた。
  この２つ、ぼんやりとは、意味を捉えていたが、しっかり人に説明できなかった。
  要するに、わかっていなかったのらー！！  ←　自慢にならんぞ！　(^^;;

  本には、ドメインの説明が書いてあった。

　でも・・・

  だから、ドメインって何やねん?

　だった。そして・・・

  その前に、ノードって何やねん?


　だった。
  そこで、まず「ノード」を調べてみた。というより、前のページに
ノードの説明が書いてあったが、自分が納得がいく説明でなかったため、
読み飛ばしていました (^^;;;;

  わかったような、わからない説明。禅問答のような感じがする。
  こういう時は、英和辞典で「ノード（node）」の意味を調べるのが早いと思った。

  意味は

　「こぶ」 「節目」 「つなぎ目」 「交点」

　などがある。
　DNSでは、どんな意味で使われているのだろうかと思いながら
 本にある図を見た。

ドメイン空間と階層構造
この図を見て、ようやくノード、ドメインが何がわかった。 ノードは分岐点（節目）を意味する言葉なので そこを指す意味を考えた。 この場合、節目には「jp」や「co」などがある。 そこで、節目の「jp」や「co」の個々の要素を指す意味だと考えた。 ノード管理者という言葉を聞いたことがあるが、 それは例えば、「kaisha」の部分を管理していたら、 kaishaのノード管理者ということになる。 ドメインは、そのノード以下の空間を表す。 例えば、jpドメインといえば、jpという節目（ノード）の 下の部分を表すし、co.jpドメインといえば co.jp以下の部分を表す。

  さて、「ゾーン」という言葉の意味を理解する必要がある。

  この説明は、すぐに理解できた。
  例えば、うちの会社のドメインを kaisha.co.jpとする。
  この時、うちの会社のDNSサーバーが管理している部分は、
kaisha.co.jpなので、「kaisha.co.jp」の範囲をゾーンという。

  ストライク・ゾーンという言葉もある通り「範囲」の意味だから
結構、早く馴染める言葉だ。

DNSでの権威とは

  「権威」という言葉が出てきたが、これも上の説明で納得できた。
  うちの会社は、自社でDNSサーバーを立ち上げている。
ということは、kaisha.co.jp のドメインを管理できる権威（権限）がある。

  ふと思った。

　権威だと日本語として違和感がある!

　権限の方がピッタシだ!

　さすがはアメリカで作られた技術だ。
英語だと「Authority」で意味が通じているが日本語に直訳すると
馴染まない。言葉の違いを感じた。


  「権威の委譲」という言葉もある。
  あるゾーン内を管理する権限を与えてもらう意味だ。
  例えば、うちのDNSサーバーが kaisha.co.jpドメインの管理する権限を
親サーバーから貰っている。
  その親サーバーは、jpドメインを管理するサーバーから、co.jpドメインを
管理する権限を貰っている。要は権限委譲の事だ。

権威の委譲
上位のサーバーは下位のサーバーにゾーン管理の権限を委譲している。 人間社会なら既得権を守るため権限委譲をしない場合があるが、 DNSの世界だと、ホストが多いため、権限を委譲しないと、 特定のサーバーに負荷がかかりパンクしてしまう。 また、ゾーン管理を分散させることで、末端で自由に設定変更が可能になる。 昔は、DNSがなく、/etc/hostsファイルに全てのホストのIPを登録していたが、 管理しきれなくなり、DNSが編み出された。 どんどん下位のサーバーに権限を委譲（丸投げ？）することにより、 巨大なドメイン空間の管理ができている事は言うまでもない。 （注意） ここの文章で「権威」と書くべき所を「権限」に置き換えている。 DNS用語では「権威」が正しいが、日本語的に読みやすくするため、 「権限」に置き換えました。

  ところで、DNSの権威の委譲の仕組みを知るのは重要なのだが、
「権威」と「Authority」の言葉の違いの方に関心を寄せてしまう。
　そこで調べてみる事にした。

  話は、どんどん脱線していくが、私はこう主張します！

   この場合、「権威」ではなく「権限」と訳しましょう！

  正しい訳をする事によって、物事の理解はしやすくなるだけでなく、
英語の「Authority」には「権限」の意味もある事がわかり、英語の勉強にもなります。
  そういう意味では、直訳するのは、いかがな物かと考えてしまう。


  （閑話休題）

  話をDNSに戻して、本を読み進めることにした。
  そして、IPアドレスとツリー構造の話が出てきた。

  ドメインとツリー構造なら、今回のボロ出し作戦する前から、
ツリー構造なのは知っていたが、IPアドレスとツリー構造の関連性は、ピンとこない。
  しかし、先へ進むため、本のページをめくる事にしたら、次の図が出てきた。

IPアドレスの階層構造
IPアドレスが「31.104.76.215」の場合 (注意) このIPの数字は私が勝手に思いついた数字です。

  こんな図は、初めて見た。うーん、なんか違和感があるような感じがした。

  続けて、本を見ると、こんな説明があった。

IPアドレスの階層構造
ドメインの場合、左から右になれば上位へ向かう。 IPアドレスの場合、逆に、左から右だと下位へ向かう。

  この段階だと「当たり前やん、それが、どないしてん」となる。
実際、私は、そう思った。
  しかし、それは、次の話へ進めるための伏線だったのは気づかなかった。

  さて、本を進めると、いきなり、IPアドレスの並びを逆転させた上で、
追加させている。

IPアドレスの並びを逆転。そして追加。
IPアドレスの並びを逆転させた上、「in-addr.arpa」を付け加えている

  何やら、こんな説明が書かれているから、何か意図があるのかと思う。

  その答えが次の図で明らかになった。
  なんと、IPアドレスと階層構造、及びドメインとの関係を見事に表す図だった。

IPアドレス、階層構造、ドメインとの関連性の図

  なんと、IPアドレスがドメインと同じ次元の階層構造で表現されている！！
  しかも、ルート（.）を頂点に、同じようなツリー構造で表現されている！！

  ここでDNSの設定ファイルを思い出した。
  同じように、IPアドレスを逆転させて、「in-addr.arpa」を付け加えた
IPアドレスを記述している設定部分がある事だった。

  論より証拠で確かめる事にした。
  named.confのファイルの中身だった。
  逆引きで管理するゾーン部分を記述する部分だ。

zone "208.76.104.31.in-addr.arpa" IN {
	type master;
	file "208.76.104.31.db";
	allow-update { none; };
};

  これで、named.confファイルに、IPを逆転させて、「in-addr.arpa」を追加させた
IPアドレスを記述する理由が初めてわかった。

  でも、これだったら、疑問が残る。
  ドメインのような表現といっても、便宜的な物だろうか？
  ホントに「arpaドメイン」が存在するのか、もしくは、その下にある
「in-addr.arpaドメイン」が存在するのか気になる。
  存在するならば、ドメインのような扱い方をしても、正常に動くはずだ。

  そもそも、「arpaドメイン」や「in-addr.arpaドメイン」を管理している
DNSサーバーが実在するのか？

  こういう時は、nslookupコマンドで確認するのが一番なので、
nslookupコマンドを使って、それぞれのゾーンを管理するサーバーがあるかどうか
確かめてみた。

[root@server]# nslookup
> set type=SOA
>
> arpa.
Server:		XXX.YYY.ZZZ.RRR
Address:	XXX.YYY.ZZZ.RRR#53

Non-authoritative answer:
arpa
	origin = A.ROOT-SERVERS.NET
	mail addr = NSTLD.VERISIGN-GRS.COM
	serial = 2003091001
	refresh = 1800
	retry = 900
	expire = 604800
	minimum = 86400

Authoritative answers can be found from:
arpa	nameserver = H.ROOT-SERVERS.NET.
arpa	nameserver = I.ROOT-SERVERS.NET.
arpa	nameserver = K.ROOT-SERVERS.NET.
arpa	nameserver = L.ROOT-SERVERS.NET.
arpa	nameserver = M.ROOT-SERVERS.NET.
（以下、ネームサーバーが続く）

[root@server]# nslookup
> set type=SOA
>
> in-addr.arpa.
Server:		XXX.YYY.ZZZ.RRR
Address:	XXX.YYY.ZZZ.RRR#53

Non-authoritative answer:
in-addr.arpa
	origin = A.ROOT-SERVERS.NET
	mail addr = bind.ARIN.NET
	serial = 2003091016
	refresh = 1800
	retry = 900
	expire = 691200
	minimum = 10800

Authoritative answers can be found from:
in-addr.arpa	nameserver = E.ROOT-SERVERS.NET.
in-addr.arpa	nameserver = F.ROOT-SERVERS.NET.
in-addr.arpa	nameserver = G.ROOT-SERVERS.NET.
in-addr.arpa	nameserver = H.ROOT-SERVERS.NET.
in-addr.arpa	nameserver = I.ROOT-SERVERS.NET.
（以下、ネームサーバーが続く）

  nslookupで見た限り、ドメインのような書き方を使っても、見事に使えし、
「arpaドメイン」や「in-addr.arpaドメイン」を管理しているDNSサーバーが
実在する事が確認できた (^^)V

  IPアドレスがドメインと同じ次元でツリー構造で表現できる！
  この発見は、私が思ってもみなかっただけに、凄い発見をした気になった (^^)V

  しかし、これでIPアドレスが、ドメインと同じ表現で使えるわけでない。
  そこで、社内のマシン（IP:XXX.YYY.ZZZ.KKK）へpingを飛ばしてみた。

  なんと「そんなホスト、知らねぇなぁ」というエラーを吐いた。
  これを見て、IPアドレスをドメインのように表記したのは、
ゾーン管理のための便宜的な表現なのかなぁと思った。
  実際は、どうなっているのかは、わからないが、私の推測では、そう思う。


BINDの設定

  さて、本を読み進めることにした。
  DNSの仕組みや概念の話から、実際に、BINDの設定の話になった。
  本には、BIND9の設定が書かれていた。
  と書いても、BINDの場合、8系、9系は細かい所をのぞけば、
設定は、ほとんど同じだが・・・。

  そういえば、うちのBINDのバージョンは何？

  なんと、自分の会社のBINDのバージョンを把握していなかった (^^;;;;

  本の丸写しで設定で、しかも、付録のC-ROMでインストールしていると
バージョンまで把握していないこともある。
　そこでBINDのバージョンを調べてみると9系だとわかった。

  まずは、BIND9のインストールの方法が書かれている。
既に、インストールはされているので流し読みをしようと思ったが、
そうは問屋が降ろさなかった。
  いきなり、OpenSSLのインストールの話が書いていたからだった。

　なんで、BINDにOpenSSLやねん?

　と思った。
  そこで、本をしっかり読むことにした。

  本には、BIND9には、OpenSSLは必須と書かれている。
  これは、BIND9になってから、ゾーン転送する際に、ゾーンの内容を
暗号化して送ることができるようになった。暗号化するために、OpenSSLが
必要になったと言える。

  それにしても、ソフトの依存性の問題。何も知らないと混乱してしまう (--;;
  Linux(UNIX系)にも、Windowsにもある問題だけに・・・

　どっちもやめてくれー!!

　と思いたくなる今日この頃 (--;;

  幸い、RedHatの場合、インストール画面を使ってインストールを行なうと、
ソフトの依存性を考慮してくれるため、それが救いだと思う (--;;
  他のディストリビュートの場合は、調べてませんので、ソフトの依存性については
何とも言えません・・・。
  だって、検証したくても、余っているサーバーがないもん (^^)


  さて、ようやく設定部分のページに差し掛かった。
  まずは、named.confというファイルの設定だった。

options {
	directory "/var/named";
};

  ゾーンファイルの置場所を決めている。
  ゾーンファイルは、DNSが管理するゾーンの内容が書かれたファイルの事。

zone "ゾーン名" クラス名 {
	type タイプ名;
	file "ゾーンの設定ファイル名";
};

  これだけだったら、わかりにくいので、実際の設定ファイルを見ていくことにします。

zone "." IN {
	type hint;
	file "named.ca";
};

zone "kaisha.co.jp" IN {
        type master;
        file "kaisha.co.jp.db";
	allow-update { none; };
};

zone "RRR.ZZZ.YYY.XXX.in-addr.arpa" IN {
	type master;
	file "RRR.ZZZ.YYY.XXX.db";
	allow-update { none; };
};

zone "localhost" IN {
	type master;
	file "localhost.zone";
	allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "named.local";
	allow-update { none; };
};

include "/etc/rndc.key";

  こうして見ていくと、named.confファイルの記述の意味がわかってくる。
  今まで、本の丸写しだったので、例え「なんで、こういう書き方なの」と
疑問に思っていても、理由までは、わからなかった。

  このファイルは、自分の所に名前解決のための問い合わせが来た際に、
ゾーンの管理の場所によって、どのファイルを参照するのかを振り分ける役目になる。

  そこで、次に、kaisha.co.jpゾーンを管理するファイル（kaisha.co.co.jp.db）の
中身を見ることにしてみた。

@			IN SOA	server.kaisha.co.jp. root.kaisha.co.jp. (
					2003022408	; serial (d. adams)
					3600 		; refresh
					300		; retry
					360000		; expiry
					84600 )		; minimum
			IN	NS	server.kaisha.co.jp.
			IN	NS	dns.*****.ne.jp.

kaisha.co.jp.	IN	MX	10	mail.kaisha.co.jp.

localhost		IN	A	127.0.0.1

server			IN	A	XXX.YYY.ZZZ.RRR
mail			IN	A	XXX.YYY.ZZZ.SSS

www			IN	CNAME	server
smtp			IN	CNAME	mail

  結構、長いファイルになってしまうのだが、個々に見ていくことにしてみた。

@			IN SOA	server.kaisha.co.jp. root.kaisha.co.jp. (
					2003022408	; serial (d. adams)
					3600 		; refresh
					300		; retry
					360000		; expiry
					84600 )		; minimum

			IN	NS	server.kaisha.co.jp.
			IN	NS	dns.*****.ne.jp.

kaisha.co.jp.	IN	MX	10	mail.kaisha.co.jp.

localhost		IN	A	127.0.0.1

server			IN	A	XXX.YYY.ZZZ.RRR
mail			IN	A	XXX.YYY.ZZZ.SSS

www			IN	CNAME	server
smtp			IN	CNAME	mail

  一通り説明しました。

  一見、わかった風に書いていますが、実は、重要なはずのSOAレコードについて
全く、わかっていませんでした (^^;;

  MXレコード、Aレコード、CNAMEレコードは、わかりやすいので、
どういう意味なのかは、わかっていました。

  ここで一つ「へぇ」と思うことを発見した。
  Aレコードの定義部分で、次のようなことができる。

server			IN	A	XXX.YYY.ZZZ.AAA
server			IN	A	XXX.YYY.ZZZ.BBB
server			IN	A	XXX.YYY.ZZZ.CCC

  なんと、1つのホストに3つのIPアドレスを定義している！！
  この設定は「ラウンドロビン」と呼ばれる設定で、
サーバーの負荷分散に使われる一つの方法だ。
  DNSに問い合わせが来た際に、この3つを順番に紹介するため、
IPを取得したホストは、サーバーへのアクセスは、綺麗に３分割される。
  サーバーへの負荷が、だいたい3分の1になるという具合いだ。
  こんな事ができるのかと、感心してしまった (^^)

  ところで、私は上の設定ファイルの説明書きの部分で

      （必要な記述）
      $ORIGIN kaisha.co.jp.
      $TTL    84600

と書きました。この2つが抜けている原因は、本の丸写しにありました。
  「RedHat7.3対応で作るLinux7」（サーバー構築研究会：秀和システム）で
説明書きには、キチンと「$TTL」は必要だと書かれていますが、
設定例の部分では、端折っていました。
  もちろん、DNSの設定が、わかっていなかった私は、設定例を真似しますので、
必然的に、「$TTL」が端折られた形になります。
  この本は、結構、便利なので、折角、良い本なので、必要な所は、
キチンと記述して欲しいと思いました。


  次に、逆引きの設定ファイルを見てみます。

@       IN      SOA     server.kaisha.co.jp. root.server.kaisha.co.jp.
  (
                                      2003022407	; Serial
                                      3600       ; Refresh
                                      300	 ; Retry
                                      360000    ; Expire
                                      86400 )    ; Minimum
              IN      NS      server.kaisha.co.jp.
              IN      NS      dns.****.ne.jp.

		IN	PTR	kaisha.co.jp.
		IN	A	255.255.255.248

RRR		IN	PTR	server.kaisha.co.jp.
SSS		IN	PTR	mail.kaisha.co.jp.

  これを詳しく見ていくことにします。

@       IN      SOA     server.kaisha.co.jp. root.server.kaisha.co.jp.
  (
                                      2003022407	; Serial
                                      3600       ; Refresh
                                      300	 ; Retry
                                      360000    ; Expire
                                      86400 )    ; Minimum

              IN      NS      server.kaisha.co.jp.
              IN      NS      dns.****.ne.jp.

		IN	PTR	kaisha.co.jp.

		IN	A	255.255.255.248

RRR		IN	PTR	server.kaisha.co.jp.
SSS		IN	PTR	mail.kaisha.co.jp.

  ここは簡単に説明しました。


  設定部分を見ていくことによって、初めてわかった事などが出てくる。
  そう考えると、丸写しのままだと、成長はないなぁと改めて感じる。


（2004年6月9日：訂正のお知らせ）

  逆引きの設定の部分で、大ウソを書いていましたので、訂正しました。

  $ORIGIN RRR.ZZZ.YYY.XXX.in-addr.arpa.と書くべき所を
  $ORIGIN kaisha.co.jp.と書いていました (--;;

  2004年6月にDNSの設定変更の際、キチンとファイルを書く変えようと考え、
その奮闘記を参考にしながら、設定をすると、逆引きができなくなった。
  慌てて調べると、奮闘記の記述に間違いがあった事がわかりました。
  この奮闘記を書いた時に検証しておくべきだったと思う今日この頃・・・ (^^;;



  さて、そういえば、キャッシュとゾーン転送についてですが、
色々な所で、取り上げましたので、話としては伝わっていますが、
でも、伝えきれていない部分があるので、補遺という形で書きました。

  キャッシュは、リゾルバ（自分の所のDNS）が名前解決のため、
ルート（.）のサーバーに問い合わせるが、いつも、そんな事をしていると、
ルートを管理するサーバーがダウンしてしまう。
  そこで、リゾルバはキャッシュを持っていて、一度、取得した情報を
一定期間内に持っておく。
  その期間の設定は、相手のDNSサーバーに依存している。
  ゾーンを管理するファイルの、SOAレコードにあります。

  そのため、nslookupコマンドで、正引きした場に、該当のドメインの情報が、
既に、キャッシュにある情報の場合、次のように出る。

>www.nasa.gov.
Server:		XXX.YYY.ZZZ.RRR
Address:	XXX.YYY.ZZZ.RRR#53

Non-authoritative answer:
www.nasa.gov	canonical name = www.nasa.gov.speedera.net.
・・・・・・・・・(以下続く)

  この時、赤字の部分が出てくる。「権威のある答えちゃうで」の意味。
  これは、ゾーン管理しているサーバーから直接、得た情報じゃないために、
こういう表示をしている。

  ところで、権威と使うと、また、違和感のある日本語になってしまう。
  ここで、また「権威」と「Authority」の違いを取り上げてます。

  私は、専門家へのお願いとして、この場合「権威のある」と訳すと、
日本語的にわかりにくくなるので、日本語に合う訳「信頼できる」に欲しいと願います。

  適切な訳ですと、初心者が言葉でつまづく事なく、学習が円滑になるだけでなく
「Authoritative」に「信頼できる」という意味があることがわかり、
英語の勉強になると思います。
  まさに、一石二鳥なので、適切な訳をお願いしたいと思います m(--)m


  さて、キャッシュについての、今だから笑える話を紹介します。
  キャッシュの影響を知ったのは、いつか覚えていませんが、
インターネットを立ち上げてから間もない時は、そんな知識はありませんでした。
  Webサーバーを導入した時、ゾーン管理ファイルにWebサーバーを追加しました。  
  しかし、当時は、実験サーバーがなかったため、Webサーバーを生け贄にして
Web機能を、メールサーバーなどに移す事をやっていた。
  生け贄が終わると、Webサーバーを元に戻していた。

比較的、頻繁に動いていたWebサーバー
元々、サーバー構築時には、Webサーバーを構築しなかった。 その後、Webサーバーを構築した時、どこで仕入れた知識が覚えていませんが、 サーバーは分散させた方が良いということで、Webサーバーは別に立ち上げました。 しかし、当時、実験サーバーがなかったため、Webサーバーを生け贄にして、 その間、メールなどの多重兼任サーバーに移していました。 実験サーバーの役目を終えると、また、Webサーバーにしていました。

  そんなわけで、DNSの設定変更はよく行なっていた。

  しかし、当時は、キャッシュとは何かを全く知らなかったし、
ましてや、キャッシュに保管される生存時間なんぞ知るわけがない。
  DNSの設定変更すれば、それですぐに変更できると思っていた。
  そのため、Webサーバーのマシンが入れ替わった時、
当時、生存時間を86400秒（24時間）だったので、キャッシュの影響で、
変更してから最大24時間は混乱することがある。
  しかし、そんな事を知らず、結構、頻繁に入れ替えたりしていた。

  ちなみに、なぜ、当時の設定ファイルが残っていないのに、当時のDNSの
キャッシュの生存時間がわかるのか。
  だって、本の丸写しだから、当時、丸写しした本を見れば、わかるのらー！！  

  まぁ、幸い、その当時は、うちの会社に、ほとんどWebのアクセスがなかったため
苦情も何もありませんでした。
  それに、例え、サーバーが止まっても、上からは「復旧は明日でも良いよ」と
本気で言っていた時代でもありました (^^)


  さて、次にゾーン転送の話をします。

  ゾーン転送。プライマリ─の情報を、セカンダリ─に転送することで、
既に、書きましたが、今年になって、初めて、どういう事か知りました (^^;;

ゾーン転送の様子
ゾーン転送は、上のように、プライマリ─の情報を、セカンダリ─に 転送する事です。 ゾーン転送は、セカンダリ─側が要求して、プライマリ─が渡します。 どれくらいの間隔で要求するかは、ゾーン管理のファイルのSOAレコードに 設定があります。既に、取り上げましたので、ここでは触れません。

  ゾーン転送に関する実話を書きます。
  インターネット立ち上げて、しばらくあったある日、ある会社がキャンペーンで、
無料でセキュリティー・チェックのサービスを行なっていました。
  さっそく、無料チェックを依頼した所、「ゾーンの情報、まる見え」という
結果が出てきました。
  実は、DNSの設定ファイルの中身が外に丸見えだったわけですが、
その時、ゾーンの情報が何か知らず、放置していました。そして、忘れていました。
最近になり、その話を思い出し、「すげー事を放置していたなぁ」と
我ながら感心しました (^^;;

  BINDの設定で、初期設定のままだと、簡単に関係のないマシンから
ゾーン転送の要求ができるみたいなので、セカンダリ─以外のマシンからは
要求できないようにする必要がある。

  それは、named.confのファイルに、次の部分を追加すれば良い。

options {
	directory "/var/named";
        allow-transfer { XXX.YYY.ZZZ.LLL ; };
};

XXX.YYY.ZZZ.LLLは、セカンダリ─のIPアドレス
赤い部分が、ゾーン転送を特定のIPの所だけに限定する設定

実は、赤い部分は誤りがありましたので、2006/6/27に修正いたしました。

  正直に白状しますと、私は、これを知ったのは、最近なので、
それまでは、ゾーン情報を気前良く公開(?)していたわけです。
  もし、私がベンダー勤務だったら、クビが飛んでいたかも (^^;;


(2006/6/27 追加)

　田中さん＠札幌から以下のご指摘を頂きました。

*****************************************************
ゾーン転送の限定

options {
        directory "/var/named";
        transfer-allow { XXX.YYY.ZZZ.LLL ; };
};

XXX.YYY.ZZZ.LLLは、セカンダリ─のIPアドレス
赤い部分が、ゾーン転送を特定のIPの所だけに限定する設定
*****************************************************

上記は  allow-transfer の誤りではないでしょうか。

  田中さんからのご指摘を頂き、早速、調べてみると、
ご指摘通り、私の記述誤りでした。

  ご指摘してくださった田中さんへは感謝いたします。


  閑話休題。ここで、セカンダリ─に関する実話を公表します。
  実は、2003年2月までは、うちの会社はセカンダリ─サーバーは
ありませんでした。
  なぜ、セカンダリ─を置かなかったのか。当時、知識がなかったため、
今では、どう考えても首をひねる理由で置きませんでした。
  その話を紹介します。

  インターネット接続した時、サーバーは1台だけでした。

初期のネットの構成

  この時、私はサーバーがコケたら、DNSのセカンダリ─が動いていても
意味がないと思った。
  少しでも運用経費削減のため、プロバイダーが提供しているサービスで、
セカンダリ─サーバー代行費(1000円)を無駄だと考えて、
セカンダリ─代行を申し込まなかった。

  今、考えると、DNSだけがコケる場合もある事がわかるが、
当時は、「サーバーがコケる＝全てがコケる」と思っていたため、
DNSだけがコケる場合は考えていなかった。

  そのプロバイダーに大学時代の友人N君が勤めていた。
  彼が「お前、セカンダリ─はやっとけよ」と助言してくれたが、
私は「でも、サーバーがコケたら、意味あらへんで」で答えていた。

  オマケに、当時、ゾーン転送なんぞ知る由もなかったので、
うちのDNSにホストの情報を追加しても、プロバイダーには連絡していないから
ホストの情報が反映されるとは全く思っていなかったため、
セカンダリ─サーバーの利点が、全くわからなかった！！

  セカンダリ─サーバーの意味や利点を知らなかったため、損した事もある。
  詳しくは「システム奮闘記・その21」(iptablesの設定入門)を
ご覧になってみてください。


  まだ、話は続きます。線路は続くよ〜、どこまでも〜♪
  もう少しで最終駅なので、お付き合いくださいね (^^)

  DNSといえば、nslookupのコマンドを連想するが、
BINDのバージョンが9になってから、こんなコメントが出るようになった。
  

[server]# nslookup
Note:  nslookup is deprecated and may be removed from future releases.
Consider using the `dig' or `host' programs instead.  Run nslookup with
the `-sil[ent]' option to prevent this message from appearing.

  nslookupコマンドがなくなるかもしれない。ちょっとショック。
  dig や hostコマンドを覚えないといけないと思うと、面倒だなぁ。

  でも、nslookupがなくなるまで、まだ、時間がありそうなので、
これから勉強すれば、ええわという悠長な構えでいきまーす！！ ←　おい！


まとめ

  「徹底的にボロ出しを行なうぞ！」と意気込んだ結果、膨大な量になりました。
  でも、私の失敗談が反面教師になり、システム管理者の卵の方に
役に立てば幸いです (^^)

  逆引きができないサーバーが結構あるという話を聞きました。
  私は体験談から言います。逆引きは大事なので、キチンと設定しましょう！