カテゴリー

アクセスカウンター


since 1996/06/14

Count per Day

  • 2今日の訪問者数:
  • 38昨日の訪問者数:
  • 809月別訪問者数:
  • 0現在オンライン中の人数:

DNSの研究

Contents

DNSとは

 ここは別に読まなくてもいいけど、DNSがさっぱりで読む暇がある人は読んでみてください。
 ちゃんとDNSの仕組みを理解するのであれば、分厚いけどオライリーのDNS&BINDあたりを読んでおくべきだろう。

 DNS(Domain Name System)とは、書くまでも無いかも知れませんが、IPアドレスを人にやさしい名前に変換する仕組み、またはその反対のことをするシステムです。
 たとえばこのサイトにアクセスするときにhttps://www.d77.jp/と入力しますが、インターネットの世界ではサーバにアクセスするのにIPアドレスが無いとダメです。この「www.d77.jp」の部分をIPアドレスに変換したり、その逆のことができる為のデータベースのようなものです。なんでこんな仕組みがあるかって、やっぱり数字の羅列よりかは楽だからでしょう。

 DNSの前身は今でも残っていますがhostsです。Linuxの場合は「/etc/hosts」で、Windows2000の場合は「x:\winnt\system32\driver\etc\hosts」にあります(何でdriverなの?とか思ったりしますが、、、)。
 このhostsファイルに、

192.168.1.1 hogehoge

とか書いておけば、「ping hogehoge」と打つと、自動的に192.168.1.1にpingしてくれます。

 昔はhostsでも十分だったんですが、インターネットの規模が大きくなるにつれ、管理が大変になり、またサーバへの負荷もかなりヤバい状態になってきたので、それを解決する為に、DNSが作られました。

 DNSは分散データベースになってるので、負荷も分散されます。その気になれば、自分のドメインの中でも負荷を分散することが出来ます。

 また、ゾーン転送やDNSへの問い合わせの仕組みにより、私のサーバのDNSに情報を書き込むだけで、世界中のインターネットにつながったサーバから名前解決を行うことが出来ます。
 

ツールの入手とインストール

 DNSサーバとしてよくbindというものが使われています。これはInternet Software Consortium (ISC) によって提供されており、無料で入手することが出来ます。このソフトはLinuxだけでなく、Windows用もあるので、非常に広い範囲で使用されています。

 bindにはいくつかのバージョンがあります。大きくbind4系、bind8系、bind9系のバージョンがあります。ここの文を書いた時はbind4やbind8がまだ主流でしたが、このところbind9も多くなってきました。

 今回はbind8を使います。bind4を使ってもいいですが、機能的に劣るのと、記述方法がbind8とbind9で似てるので、将来移行するのが楽だからです。

 bindはISCでダウンロードしてください。bindは結構凶悪なセキュリティホールが見つかることがあるので、バージョン管理に気をつけてください。bind8の最新版ならOKです。
 ここを書いてるときは8.2.5が最新なので、それを入手し解凍します。ここで注意ですが、bindは自分のディレクトリを作らないでいきなり解凍します。他のファイルと混ざってわかりづらくなるときがあるので、ディレクトリを作ってから解凍しましょう。
 

$ mkdir bind8
$ cp bind-8.2.5-src.tar.gz ./bind8
$ cd bind8
$ tar zxvf bind-8.2.5-src.tar.gz

んでコンパイル
 

$ cd src
$ make stdlinks
$ make clean
$ make depend
$ make all

 最後に管理者になってインストールです。
 

$ su
# make install

 これで実行ファイルが入りました。でもいきなり実行は出来ません。設定ファイルが必要です。
 

bind9を入れてみる

 基本的にはbind8の設定のまま移行可能です。
いくつかワーニングが出ますが、エラーにはほとんどなりません。
 詳細については別記「bind9」を参照してください。

DNSの基礎

 DNSに関する基礎的な情報です。
 

DNSとnamedとbind

  • DNS(Domain Name System)
    名前解決のシステムを示してます。
  • named(name deamon)
    サーバ上で動くデーモン(サービス)の種類です。 
  • BIND(Berkeley Internet Name Domain)
    ISCで配布してるバークレーで開発されたソフトの名前です。

ドメインとゾーン

 ドメインはドットで区切られたグループを示しています。たとえば、ここのサーバ「www.d77.jp」は「jpドメイン」の中にあり、その中の「d77.jpドメイン」に「www」というサーバが存在しています。

 ゾーンとは、あるネームサーバが管理する範囲を示しています。たとえば、「d77.jpドメイン」に「hoge.d77.jp」というサブドメインを作り、独自のネームサーバ立てた場合、「hoge.d77.jp」は新たな「ゾーン」になります。「hoge.d77.jp」は「d77.jpドメイン」ではあるが、「d77.jpゾーン」では無くなるというわけです。

 この辺の関係がnamed.confのzoneにかかわってます。
 

DNSのツリー構造

 DNSはツリー構造になっています。

 たとえば(あくまでもたとえです)、ここのサーバ(www.d77.jp)を「hogehoge.com」に属する人が検索する際、まず、「ルートネームサーバ」に問い合わせます。
 ルートネームサーバとはDNSのツリー構造のもっともレベルが高いところに存在します。その為これが止まると世界中の人が困ります。そのようなことがないように世界に十数台設置されています。
 ルートネームサーバは基本的に「comドメイン」「jpドメイン」を管理するサーバを知っています。ここのサーバは「jpドメイン」なので、「jpドメイン」を管理するサーバを教えてくれるでしょう。
 次に「jpドメイン」を管理するサーバに問い合わせると、「d77.jp」の所在を教えてくれます。

 このように徐々にDNSのツリー構造の分岐点に問い合わせることにより、最終的にサーバの所在が明らかになると言うわけです。

masterとslave

 DNSはよく「プライマリDNS」と「セカンダリDNS」の2つをセットで用います。これは主に対障害性を高めるのが理由ですが、、、。

 「プライマリDNS」は別名(いや、こっちが本名か?)「Primary Master Name Server」であり、「セカンダリDNS」は「Slave Name Server」です。

 何が違うかと言うと、「Primary Master Name Server」は、自らがデータベースファイルを持ち、それを利用して名前解決を行います。
 「Slave Name Server」はデータベースファイルを初めから持っているわけではなく、「Primary Master Name Server」からネットワーク経由で「ゾーン転送」を行ってその情報を蓄え、それを利用して名前解決をします。

※機能的には上記なんですけど、「Slave Name Server」がデータベースファイルを持つことは出来ます(と言うかループバックとルートデータは普通持ってます)。

 bind8の設定ファイルで「type master」とか「type slave」とかがありますが、これらは「自分でデータベースを持っている」のと「他人からゾーン転送でデータを貰う」という意味だと思ってください。
※ちなみに「type hint」は自分がそのゾーンの情報を持ってないけど、「知ってるところはどこそこのサーバだよ」というのを定義してます。
 

設定ファイル

 bindを正しく稼動させるには、ドメインやIPアドレスに関連したデータベースファイル(RFC1034あたりに説明があります)と、bind特有の設定ファイルが必要です。

 通常、bind特有の設定ファイルは「/etc/named.conf(bind8の場合)」あたりにあり、データベースファイルの位置やそれらの役割に関して記述してあります。
 

named.conf

 bindの基本的な設定はnamed.confに書きます。bindの設定ファイルはこれだけではありませんが、この中に各ファイルの所在なども記述します。基本的にbindの設定ファイルは事前にあるものを使うのではなく、1から作るのが普通です。始めはイヤかも知れませんが、慣れるまでガマンしてください。

 Linuxの場合はデフォルトは「/etc/named.conf」です。Windowsはよく知りません。でも書き方はほとんど同じです。

 以下の例は「d77.jp」ドメインで、そのIPアドレスが「111.222.333.444」の場合の例です。
※実際のd77.jpのドメインのIPアドレスは違いますけど、ここでは一例です。
 

// オプション
options {
    directory "/var/named";
};

// ルートキャッシュデータ
zone "." {
    type hint;
    file "named.ca";
};

// ループバックデータ
zone "0.0.127.in-addr.arpa" {
    type master;
    file "named.0.0.127";
};

// 正引き(順引き)データ
zone "d77.jp" {
    type master;
    file "named.d77.jp";
};

// 逆引きデータ
zone "333.222.111.in-addr.arpa" IN {
    type master;
    file "named.rev";
};

 空白の部分はスペースでもタブでもOKです。逆に無いとエラーになる場合があるので、それだけは注意してください。
 また、セミコロン「;」が無いとエラーになる場合もあるので忘れないようにしましょう。

 この設定ファイルにはコメントが可能です。一部書いてありますけど、「//」から行末までがコメントです。
あと「/*…*/」や「#」も使えます。使い方は「//」と「#」は同じです。「/*…*/」は「…」の部分がコメントになります。

例)
/*ここがコメント
 ここもコメント
 ここまでコメント→*/

named.conf-option部(2001/12/27)

// オプション
options {
    directory "/var/named";
};

 ここには各設定ファイル(named.conf以外のファイルね)がある位置を指定します。
 他にも重要なことが書けますが、bindを動かすには最低限コレが必要です。詳しい説明は別途書きます。

named.conf – ルートキャッシュデータ

// ルートキャッシュデータ
zone "." {
    type hint;
    file "named.ca";
};

 この内容はルートネームサーバ(.)に関係するデータベースファイルの情報を書いています。

 ゾーン(zone)はルートを示す「.」です(DNSではルートを「.(ドット)」もしくは「何も指定しない」ことにより指し示します。どちらを書くかは書く場所に応じて変わりますが、ここでは「.」です)。

 ここで定義しているのは、ルートネームサーバの設定ではありません(私が世界のルートでは無いですからね^^;)。DNSは自分で名前を解決できない場合(そして、対象サーバの近隣情報がキャッシュされていない場合)、ルートネームサーバへ問い合わせします。そのルートサーバの所在を示す情報(ヒント:hint)を示しています(だからtype "hint"です)。

 なお、ここではルートキャッシュデータファイルとして、「named.ca」を参照している。「named.ca」がある位置はoptions部のdirectoryです。

named.conf – ループバックデータ

// ループバックデータ
zone "0.0.127.in-addr.arpa" {
    type master;
    file "named.0.0.127";
};

 ここでは自分自身を表す「127.0.0.x(xは通常1だけど、、、)」というIPアドレスから名前解決する為のデータが記述されている。
 「127.0.0.1」の「1」の情報に関しては、参照先のファイル「named.0.0.127」で定義している。

 実際に設定を定義しているので当然「type master」です。

named.conf – 正引き(順引き)データ

// 正引き(順引き)データ
zone "d77.jp" {
    type master;
    file "named.d77.jp";
};

 ここでは、サーバ名(xxx.d77.jp)からIPアドレスを調べる(これを「正引き」とか「順引き」と言う)為の情報を記述している。
 ここは、「d77.jpゾーン(zone "d77.jp")」関する情報を示しており、「type master(このゾーンに関しては私が情報を持っている)」なので、サーバ名「xxx.d77.jp」の「xxx」の部分にどのような文字が入るかや、それらがどういったIPアドレスになってるかなどは、参照先のファイル「named.d77.jp」に記述されている。
 

named.conf – 逆引きデータ

// 逆引きデータ
zone "333.222.111.in-addr.arpa" IN {
    type master;
    file "named.rev";
};

 ここではIPアドレスから、サーバ名を調べる情報が記述されている。通常正引きの場合、ルートネームサーバから、DNSのツリー構造順に検索していくが、IPアドレスはどうなのかと言うと、IPアドレスも基本的には同様です。
 実はIPアドレスの場合、「arpa」→「in-addr」の順に検索し(これは概念云々よりもそういうルールだと覚えたほうが楽)、その後IPアドレスの頭から順に追う形になります。その為「333.222.111.in-addr.arpa」という定義になります。この情報も当然データベースを自分で持っているので「type master」となり、IPアドレスの最後の「444」の情報は(444なんてありませんけど初めに書いたとおりこれは例ですよ)、参照先のファイル「named.rev」に記述されている。

※注意:ここの記述内容はISPによっては特殊な記述方法が指定されてる場合があります。
 

ゾーン転送を制限する(2002/09/04)

 ゾーン転送とはセカンダリDNSがプライマリDNSから情報を貰う為のデータ転送です。基本的に何も設定しないと何処からでもゾーン転送できますが、そうした場合第三者にサーバ構成が知られてしまい、不正アクセスしやすくなります。その為、プライマリ側で、ゾーン転送を許可するセカンダリを指定する必要があります。設定はnamed.confの「option部」に書きます。
 セカンダリのIPアドレスが「222.222.222.222」の場合は以下のような記述になります。
 

// オプション
options {
    directory "/var/named";
    allow-transfer {
        222.222.222.222;
    };
};

 これで、「222.222.222.222」以外のセカンダリサーバはゾーン転送を要求出来なくなります。

セカンダリ(slave)を設定する(2002/09/04)

 セカンダリの設定はプライマリより楽です。なにせプライマリーからコピー(ゾーン転送)するだけですから、、、。
 プライマリでゾーン転送が制限されてるとコピーされないので注意してください。

 設定はnamed.confのみです。
 セカンダリでは、プライマリからゾーン転送をするという設定をしますが、ループバック(zone "0.0.127.in-addr.arpa")とルートキャッシュ(zone ".")はゾーン転送の設定をする必要はありません。転送する必要は無いし、設定する分トラフィックの無駄になるからです。

 ゾーン転送の設定は簡単です。まず、プライマリが以下のような設定になってるとします。
 

// 正引き(順引き)データ
zone "d77.jp" {
    type master;
    file "named.d77.jp";
};

 セカンダリ側ではこのデータをゾーン転送で貰うのに、以下のように書きます。

// 正引き(順引き)データ
zone "d77.jp" {
    type slave;
    file "named.d77.jp";
    masters { 111.111.111.111; };
};

 「file」に指定されたファイルは作成する必要はありません。自動的に作成されます。mastersではプライマリDNSのIPアドレスを指定します。プライマリが複数ある場合も、「masters { 111.111.111.111; 222.222.222.222 ;};」と複数指定することが出来ます。

 逆引きも同様に設定します。
 

各設定ファイルの解説

 named.confはbindというソフトウエア独自の記述形式ですが、named.confから参照される各ファイルはRFC1034等に定義されている形式になります。
 

ルートキャッシュデータファイル

 「xxx.co.jp」というドメインの人が、「yyy.ne.jp」というドメインを参照する際は、「.jp」ドメインを管理するDNSに問い合わせればいいですが、「zzz.com」というドメインを参照する際は、ドメインルートのDNSを検索しなければなりません。
 ルートキャッシュデータファイルには、そのドメインルートのDNSへのアクセス先の手がかり(hint)を記述します。
 ドメインルートに位置するDNSは世界中に10数個存在し、不変ではありません。これを自分ひとりで管理するのは不可能なので、管理しているところから入手します。
 Internicのftp(ftp://ftp.rs.internic.net/domain/)にあるnamed.root(ftp://ftp.rs.internic.net/domain/named.root)というのがソレです。

 ルートキャッシュデータファイルは海外のメーリングリストとかで常に最新の情報流れているらしいですけど、私は見たことが無いです(^^;
 

$TTL

 「No default TTL ($TTL <value>) set云々、、、」というエラーがログに残ることがありますが、これは各設定ファイルに「$TTL」というパラメータが指定されてない場合に発生します。

 これは正引き/逆引きファイルに指定するパラメータで比較的最近になって要求されるようになりました(その為bind8が出た当時の書物には触れられてません)。

 「$TTL」はそのファイルの生存時間を示すもので、現在は必須となってます(bind8系は無くても動くけど。bind9は必須になってると思います)。記述は以下のようにSOAレコードの前に書きます。
 

$TTL 86400
@ IN SOA hoge.d77.jp. root.hoge.d77.jp. (
・・・

参照:RFC2308のセクション4
 

SOAレコード

 次の設定ファイルの説明に入る前に、全ての設定ファイルに書かれるSOAレコードの記述形式に関して解説します。
 

@ IN SOA hoge.d77.jp. root.hoge.d77.jp. (
2002010101      ; Serial
10800           ; Refresh
3600            ; Retry
604800          ; Expire
86400   )       ; Minimum

 SOAレコードにはDNSの更新に関する情報を記述します。この情報はそのままセカンダリDNSなどに渡されて、その設定に応じてセカンダリが問い合わせを行います。

 まず1行目ですが、「@」はゾーン名を省略した値で、named.confで定義されている「zone "d77.jp"」の部分がそのまま入ります。ですので「@」を「d77.jp.」と書いてもOKです。

※注意:named.confではドメインルートを空白で表現しますが、各設定ファイルは「.(ドット)」で示します。ですので、named.confでは「d77.jp」でも、SOAの方では「d77.jp.」と後ろにドットを付けます。

 「IN SOA」の後はプライマリマスタのホスト名(つまり自分のホスト名)、そして管理者のメールアドレス(「@」は「.」にする)を記述する。

 次の行のSerial(セミコロン以降はコメントなので、わざわざ;Serialと書かなくてもいいですけど書いた方がわかりやすい)は、設定ファイルのシリアル番号で、設定ファイルを更新する度に値を増やさなければなりません。一般的には年、月、日、2桁の数値で表現します(これは必須ではないので、単に1からカウントアップしてもいいです)。2002年の元旦に更新した場合は「2002010101」ですし、同じ日に2回更新したなら「2002010102」になります。

 Serial以降はDNSの更新頻度に関する設定で、更新間隔、失敗時のリトライ間隔、期限切れ時間、キャッシュの保持時間の順に秒単位で書きます。この値は自由に設定していいのだが、RFC1537では以下の値を推奨している

  86400 ; Refresh     1日
   7200 ; Retry        2時間
2592000 ; Expire      1ヶ月
345600 ; Minimum TTL  4日

ループバックデータファイル

 「自分自身(127.0.0.1)」を定義してるファイルです。
書かないと、自分自身を名前解決する際に失敗することがあるので書きましょう。

@ IN SOA hoge.d77.jp. root.hoge.d77.jp. (
2002010101      ; Serial
10800           ; Refresh
3600            ; Retry
604800          ; Expire
86400   )       ; Minimum

  IN NS hoge.d77.jp.
  IN NS ns1.hogehoge.com.

1 IN PTR localhost.

 ここでの「@」は「0.0.127.in-addr.arpa.」の省略形です。「IN NS」の前にもこの記述が必要ですが、何も書かないと省略していることを意味するので「IN NS hoge.d77.jp.」は「0.0.127.in-addr.arpa. IN NS hoge.d77.jp.」と同じです。
 「IN NS」とかかれているNSレコードは参照先のDNSを示しています。2行あるのはプライマリマスタとセカンダリです。
 PTRレコードは特定のIPアドレスに対応するホスト名を示します。ここでのIPアドレスは「1」なんですが、このように後ろに「.(ドット)」を付けない場合は「0.0.127.in-addr.arpa.」を省略しているとみなされます。ですので、ここの記述は「1.0.0.127.in-addr.arpa. IN PTR localhost.」であると思ってください。
つまり、このPTRレコードは「127.0.0.1」は「localhost.」だと言うことを示しています(localhostの後ろに「.」が付いてるので、「localhost.d77.jp.」では無い)。

 この設定ファイルを書くことによって、127.0.0.1はlocalhost.と名前解決することが出来ます。
 

正引き(順引き)データファイル

 多分、この設定ファイルが一番書くことが多いでしょう。このファイルは「名前」から「IPアドレス」を検索するのが目的ですが、「名前」自体、「別名」を定義したりとか、ホスト名を省略した際の参照先などを定義してやらないといけないからです(逆引きにはIPアドレスの別名などあり得ないので不要)。
 なお、ここの例では「@」や最後に「.(ドット)」の付いていないホスト名には、「d77.jp.」が補完されます(しつこいようですが、named.confに「zone "d77.jp"」と書いてあるからです)。

@ IN SOA hoge.d77.jp. root.hoge.d77.jp. (
2002010101      ; Serial
10800           ; Refresh
3600            ; Retry
604800          ; Expire
86400   )       ; Minimum

  IN NS hoge.d77.jp.
  IN NS ns1.hogehoge.com.

localhost    IN A 127.0.0.1
hoge.d77.jp. IN A 111.222.333.444
d77.jp.      IN A 111.222.333.444

d77.jp.      IN MX 10 111.222.333.444

www  IN CNAME hoge
mail IN CNAME hoge

 NSレコードはループバックデータファイルで解説した通り、ネームサーバを指し示しています。
 つぎの「localhost IN A 127.0.0.1」ですが、ループバックデータファイルがあるのに何故この行が??と思うかもしれませんが、localhostに「.」が付いてないので、省略名を補完した「localhost.d77.jp.」のIPアドレスを示しています。
 「hoge.d77.jp. IN A 111.222.333.444」では「hoge.d77.jp.」のIPアドレスは「111.222.333.444」だというのを指し示しています。「d77.jp.」は省略可能なので「hoge IN A 111.222.333.444」でも大丈夫です。
 「d77.jp. IN A 111.222.333.444」は、「ドメイン名のみで名前解決を試みた場合」にIPアドレスを引けるようにする為のものです。

 「d77.jp. IN MX 10 111.222.333.444」は、メールの配送先の指定です。たとえば、d77.jpドメイン宛にメールを送った場合は、ここの値を参照して、参照先のメールサーバへメールを送ります。
 MXの後ろの「10」は優先順位を示しています。これはメールサーバの負荷分散に役立つのですが、以下のような記述をした場合、、、

d77.jp. IN MX 10 mail1.d77.jp.
d77.jp. IN MX 20 mail2.d77.jp.

 優先順位は値が低いほど優先されるので、「mail1.d77.jp.」にメールを配信し、そのサーバが反応しない場合は「mail2.d77.jp.」へメールを送ります。
 ちなみに、

d77.jp. IN MX 10 mail1.d77.jp.
d77.jp. IN MX 10 mail2.d77.jp.

 と、書いた場合はどちらかのメールサーバに送信を試み、エラーの場合はもう一方への送信を試みます(同じサーバに2度試みることはありません)。

 「www IN CNAME hoge」はサーバの別名を定義しています。「www.d77.jp」で名前解決した場合は「hoge.d77.jp」のIPアドレスを返します。「hoge.d77.jp」のIPアドレスは、少し上の行で定義してるものです。ここでは、「mail IN CNAME hoge」という定義もあるので、たとえば1台のサーバでWebサイトへのアクセスは「https://www.d77.jp/」にして、メール送信には「mail.d77.jp」を使うなんて使い分けも出来るわけです。
※特に各デーモンの方で設定を変更しなければ、「http://mail.d77.jp/」でもWebサイトを見れてしまうのですが、、、(^^;

※注意
 CNAMEで定義されたホストの別名を、別の設定に書いてはいけません。たとえば、「mail IN CNAME hoge」と定義した上で、「d77.jp. IN MX 10 mail」と定義するとエラーになります。
 

逆引きデータファイル

 このファイルは「IPアドレス」から「名前」を検索するのが目的です。正引きファイルのような別名定義などは無いので、あるがままに書きましょう。

 正引きと同様に、「@」や最後に「.(ドット)」の付いていないIPアドレスには、「named.conf」で「zone」に定義された値が補完されますが、正引きとは見かたが変わります。逆引きファイルで定義した値が「444」の場合、「333.222.111.in-addr.arpa」が補完され、「444.333.222.111.in-addr.arpa.」になります。この定義は「.in-addr.arpa.」を省いて後ろから読むので、「111.222.333.444」というIPアドレスを示すことになります。
 

@ IN SOA hoge.d77.jp. root.hoge.d77.jp. (
2002010101 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
86400 ) ; Minimum

IN NS hoge.d77.jp.
IN NS ns1.hogehoge.com.

444 PTR hoge.d77.jp.

 NSはネームサーバの指定です。
 「444 PTR hoge.d77.jp.」は、このIPアドレスが示すホストを指定しています。既に解説した通り、「444」の後ろにドットが付いてないので、「111.222.333.444」というIPアドレスは「hoge.d77.jp」というホストだと言うことを示しています。省略しないで指定するときは「444.333.222.111.in-addr.arpa.」となるわけです。
※当然ながらホスト名を省略して「hoge」と書くと、正引きファイルじゃないので、「hoge.d77.jp」ではなく「hoge.333.222.111.in-addr.arpa」を示すことになりますので、ここではホスト名の省略はできません。
 

Windowsでbindを動かす

 ここではWindowsでbindを動かす方法を簡単に解説します。
※あまり詳しく書いてません(^^;。

入手/インストール

 Windows版のbindもISC(http://www.isc.org/)で入手可能です。今回はWin2000にインストールしたのでWinNT/Win2000版を導入してみます。

 ダウンロードするとzipで圧縮されてるので、適当なフォルダーにダウンロードします。そして、「BINDInstall.exe」というファイルがあるので実行します。

 デフォルトはWindowsのsystem32ディレクトリ内にdnsというフォルダを作成し、そこに導入されます。

 このインストール作業で、スタートメニューへの追加(スタート→プログラム→ISC)とサービスの自動起動設定(ISC BIND)が追加されます。

設定

 ここでは試しにキャッシュ専用サーバを立ててみました。設定は簡単です。まず、named.confを用意します。
※ここではインストール先を「C:\WINNT\system32\dns」と仮定します。
 

options {
directory "C:\WINNT\system32\dns\etc";
};

zone "0.0.127.in-addr.arpa" {
type master;
file "db.127.0.0";
};

zone "." {
type hint;
file "db.cache";
};

※「directory」項目の最後に「\」を付けると、何故かエラーになります。

 キャッシュ専用サーバの設定はこの程度です。ループバックデータファイル(db.127.0.0)とルートキャッシュデータ(db.cache)は別途用意します(既に解説済みなのでここでは省略します)。

 テストでは、bindを起動する為に「bindctrl.exe」を使用します(スタートメニューにも入ってます)。

 「Start」を押せば起動します。

 正しく稼動しているかは、イベントビューワを見ましょう。ログがわざわざ1行1行出るので見るのが大変です。幾つか警告が出ても、エラーが無ければ正しく動作しています。動作チェックはコマンドプロンプトからnslookupで行えます。
※例(コマンドプロンプトで実行)

nslookupenter
server 127.0.0.1enter
set type=txtenter
set class=chaosenter
version.bindenter

 これで稼動しているbindのバージョンが出るので、ダウンロードしたbindのバージョンと一致すれば、まぁOKでしょう。

トラブルシューティング

 ここでは、基本的なDNSの問題解決方法を記します。

DNSを起動したが、psコマンドにnamedが無い。

 それはエラーがでて停止してることが考えられる。
syslog(RedHatでは/var/log/messages)をじっくり見よう。
 namedが起動するときは「starting」という文字と、bindのバージョン番号が表示されます。まずはそこを探し、それに続く行でエラーが無いか調べます。ログにはどの設定ファイルにどういうミスをしたかしっかりと書いてますので、よく見ればすぐにわかるはず。

 設定ファイルがちゃんと読み込まれていれば、「master zone "xxx" loaded」と、読み込み完了を示すメッセージが表示されます。
 

エラーが多すぎて何が悪いのかわからない。

 原因は幾つか考えられる。
 

  1. 本当に記述ミスが多い。
  2. 括弧(「{」や「}」)の数があっていない。
  3. (named.confなどで)、閉じ括弧(})の後ろにセミコロンが付いていない。
  4. コメントを示すマークが間違えている(named.confでは/*…*/、//、#で、その他の設定ファイルは「;」です)。named.confで「*/」と「/*」を書き間違えてたのを見たこともある(^^;。

 上記の記述ミスをすると、異常な量のエラーが出る場合があります。
 あまり良いやり方ではありませんが、エラーの一番最初だけを修正して、namedを再起動して、また次のエラ−を直すのもいいかも。
 

起動したようだが、本当に動いているのか確認したい。

 nslookupを使うといいだろう。まずはDNSを起動したホストで検査し、それがうまくいったら他のパソコンから調べればいい。

 UNIXでもWindowsでも、コマンドラインから「nslookup」で対話モードで起動する。
起動したら「server DNSサーバ名(もしくはIPアドレス)」と入力しよう(当然nslookupを起動したパソコンが、名前解決できない状態でホスト名を入れても意味がない)。
 あとは以下のコマンドでいろいろと確認が出来る。
 

> ドメイン名
応答として、DNSホスト名とIPアドレスが表示される。

 

>ホスト名
ホストのIPアドレスが表示される。

 

> set type=mx[Enter]
> ドメイン名[Enter]
 ※EnterはそこでEnterキーを押す。
 MXレコードの内容が確認できる。

しばらくすると、USAGEとかNSTATS、XSTATSというログがでる。

 それはDNSの動作状態を示す統計情報で、デフォルトで1時間毎にログに出力される。
 不要であれば以下の内容をnamed.confに書けば、出力されなくなる。
 

logging {
    category statistics { none; };
};

 別ファイルに出力したいなら、
 

logging {
    channel stat_file {
        file "/var/log/named/named.stat";
            severity info;
    };
    category statistics { stat_file; };
};

 、、、という書き方で別のファイルに出力することも出来る(ファイルは事前に作成しておく)。
 ちなみに出力したファイルはちゃんとローテーションしないと肥大していく一方になります。
 

時々「Lame server on …」というログが出力される。

 正引き(もしくは逆引き)情報をもってるはずのDNSが、その権限を持っていないので参照できないことを示す。
 単なるパケットの遅延が原因のときもあるらしい。
 取り合えず(自分でなければ)、ほおって置くしかない。
 

ログにNo default TTL ($TTL <value>) set・・・

 「$TTL」パラメータを書けばなおります。
 「各設定ファイルの解説」→「$TTL」を参照してください。
 

まったく記述ミスが見つからないのにシンタックスエラーが出る。

 設定ファイルでスペースが必要な個所にスペースが無かったりすると、エラーになります。たとえば、、、

誤)@_IN_SOA_hoge.d77.jp._root.hoge.d77.jp.(
正)@_IN_SOA_hoge.d77.jp._root.hoge.d77.jp._(
※便宜上、スペースの入るところにアンダーバー(_)を入れてます。

 上記のように、括弧の前にスペースが無いだけでエラーになることもあります。

bind9

 ここではbind9の運用について解説します。
私の環境ではbnd8からの移行なので、それに沿った形での解説になりますが、なるべくbind9を新規でインストールした方でもわかるように解説しようと思います。
 

bind9のインストール

 今回使用したバージョンはbind-9.2.1.tar.gzです。bind9系はバージョンによっていろいろと障害が出るようなので、バージョンが違う場合はここの解説では足りなくなるかも知れません。
※ここの解説はLinuxベースなんで、BSD系の方も十分注意すべきだと思います。

 まず、ソースを入手します。ソースはbind8と同様にisc(http://www.isc.org/)から入手できます。
 コンパイルにはroot権限は必要ありません。

 まず解凍します。

$ tar zxvf bind-9.2.1.tar.gz
$ cd bind-9.2.1

 ここでREADMEをチェックしておきます。読めなくても読みましょう。高校の時に英語30点(100点満点中)だった私も読んでるので大丈夫です(何が?)。
 コンパイルに関わることは「Building」とか「Compile」とかいう項目を探せばOKです。

 次に環境設定ですが、通常では「./configure」で大丈夫ですが、今回はbind8からの移行もあったので、意図的に新しいディレクトリを指定します。指定しなくても後で変更可能なので安心してください。

$ ./configure –prefix=/usr/local/bind9 –sysconfdir=/etc –enable-threads=yes –localstatedir=/var

 

 prefix・・・インストール先
 sysconfdir・・・named.confの位置
 enable-threads・・・マルチプロセッサ対応
 localstatedir・・・ログの類

 環境設定後は、Makefileを見ると各インストール先がかかれているので、make前なら修正可能です。

 prefix =        /usr/local/bind9
 exec_prefix =   ${prefix}
 bindir =        ${exec_prefix}/bin
 sbindir =       ${exec_prefix}/sbin
 includedir =    ${prefix}/include
 libdir =        ${exec_prefix}/lib
 sysconfdir =    /etc
 localstatedir = /var
 mandir =        ${prefix}/man

 そしてコンパイル

$ make all

 最後にインストールですが、root権限が必要です。

$ su
# make install

 あとは「/usr/local/bind9/sbin/named」で起動することが出来ます。
 

bind8の設定ファイルのまま起動した時のログ解析

 とりあえず、起動した場合のログをチェックしてみましょう。
※以下のログは日時等の表示を省略してます。
 

starting BIND 9.2.1

 ここからbindの起動プロセス開始。
 

loading configuration from '/etc/named.conf'

 named.confの読み込み。読み込み権限が無い時や位置が間違ってるとここで止まります。ちなみに「-c」起動オプションで位置の指定も可能。
 

option 'check-xxx' is not implemented

 出力するログのファシリティレベルなどの設定は著しく変わってるようで、この辺は全部無視されます。
 

no IPv6 interfaces found

 ちゃんと設定してやればIPv6にも対応(ここでは非対応)。
 

listening on IPv4 interface lo, 127.0.0.1#53

 どのポートからのDNSクエリーを受け付けるかが表示されます。

none:0: open: /etc/rndc.key: file not found

 これはbind9特有の設定が不足しているメッセージ。解決方法は次の項で解説します。
 

couldn't add command channel 127.0.0.1#953: file not found

 bind9では「command channel」としてポート953を使うようです。これも次の項にて解説。
 

unknown logging category'statistics' ignored

 「logging」セクションを設定している場合、ここのカテゴリもかなり変わってるのでワーニングになり無視されます。
 

zone xxx/IN: loaded serial xxx

 これはゾーンファイルの読み込み。各ゾーンの読み込みが成功しているか確認する。

 ログに関するワーニングは書き方自体がかなり変わってしまっている為、消して書き直すしかありません。何も書かなければデフォルト値でsyslogに出力されます。

 また、rndc.keyやcommand channel等の追記に関しては次項で解説します。
 

rndc.keyとcommand channelの設定

 bind9からは署名付きの更新が可能らしく、その関係でkeyを作成しなければならない(らしい←まだ詳しく勉強してない)。
 ここではとりあえずの解決方法を記します。
 まず、以下のコマンドを実行。
 

# /usr/local/bind9/sbin/rndc-confgen

 そうすると設定例が出力されます。
 

# Start of rndc.conf
key "rndc-key" {
〜云々〜
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
〜云々〜
# };
# End of named.conf

 とりあえず、後半の方の「# Use with the following in named.conf〜」から「# End of named.conf」をnamed.confに書き加えます。途中コメント「#」されている設定はコメントを外してください。これでワーニングは解決します。
 

# Use with the following in named.conf, adjusting the allow list as needed:
key "rndc-key" {
algorithm hmac-md5;
secret "xxxxxx";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# End of named.conf

bind9特有の設定

 まだ、調べてる途中なのでそのうち書きます。

参考

 DNSに関する情報です。

関連ドキュメント

 以下の文書はhttp://www.google.com/あたりの検索サイトで「RFCxxxx」で検索すれば、参照することが出来ます。
 

  • DNSに関すること(一度書き直されているものは、2つの番号がある)

    • RFC882:
      RFC1034:
      DOMAIN NAMES – CONCEPTS and FACILITIES
    • RFC883:
      RFC1035:
      DOMAIN NAMES – IMPLEMENTATION and SPECIFICATION
    • RFC1537:
      Common DNS Data File Configuration Errors
  • トップレベルドメイン(.jpとか)に関すること

    • ISO3166
  • その他

    • RFC952:(ホスト名の命名規則)
      DOD INTERNET HOST TABLE SPECIFICATION
    • RFC952:(メール配送経路関連、MXが関係してる)
      MAIL ROUTING AND THE DOMAIN SYSTEM
    • RFC2136:(bind8.1.2より追加された機能)
      Dynamic Updates in the Domain Name System (DNS UPDATE)

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

Time limit is exhausted. Please reload CAPTCHA.