DNS の導入/設定 (BIND9)

Domain Name Systemの導入と設定（BIND 9編）

電子メールアドレスの @ の右側にくる名前（ドメイン名）や www.example.com などのような URL の一部を構成する名前は、すべて Domain Name System (DNS) と呼ばれるシステムにより検索されます。基本的に DNS は、あるコンピュータの名前からそのコンピュータの IP アドレスを得たり、IP アドレスからコンピュータ名を得るための仕組みです。

ここでは、DNS を実装するためのシステムの一つである BIND (Berkeley Internet Name Domain) の設定について記述してあります。BINDは、サーバ(named)、リゾルバ(libresolv.a)、管理用プログラム(nslookup, dig) などから構成される一連のプログラム群です。現在は、Internet Software Consortium によってサポートされています。

インストール

BIND 8 から BIND 9 に変わったことで、設定方法が変更されたので新たに変更部分を含めて説明し直します。前回は、パッケージのインストール方法を省略しましたが、セキュリティーホールが見つかってパッケージを再インストールする機会が増えてきたのでここで解説しておきます。まず、最近はセキュリティー確保のために、スーパーユーザーでサーバーを起動しないことが多いようにネームサーバーも専用にアカウントを用意します（ここでは、bind というユーザーを例に説明します）。実際にアカウントや BIND のインストール先については自分の環境に合うように指定してください。

# groupadd bind
# useradd -g bind -s /bin/false -d /usr/local/bind -m bind
# mkdir /usr/local/bind/var
# mkdir /usr/local/bind/var/run
# chown bind /usr/local/bind/var/run

標準的なパッケージ作成しか説明しませんが、シェアードライブラリーの作成(--with-libtool)やOpenSSL を利用(--with-openssl=/openssl-prefix)、BIND 8 resolver ライブラリーの作成(--enable-libbind)も可能です。
デフォルトのまま configure を起動すると、/usr/local の下にいろいろインストールされます。しかし、セキュリティーを考慮してネームサーバーを管理したいので、 bind のホームディレクトリーに必要なモジュールをインストールし、設定ファイルを /etc にインストールするようにします。

# gzip -dc bind-9.2.2.tar.gz | tar xf -
# cd bind-9.2.2
# ./configure --prefix=/usr/local/bind --sysconfdir=/etc
# make
# make install

これを、Redhat Linux 8 の環境に合わせたい場合、以下のように実行し、pid-file を /var/run/named の下に作成するように設定します。これを実行すると、元々 Redhat Linux にインストールされていた BIND パッケージを上書きしてしまうので注意してください。

# gzip -dc bind-9.2.2.tar.gz | tar xf -
# cd bind-9.2.2
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
# make
# make install

BIND9 では、セキュリティー強化のため DNSSEC(DNS SECurity) と TSIG (Transaction SIGnature) というものをサポートしています。これらを利用するには、キーによる認証がなされていなければなりません。そこで、まずキーを作成します。キーのアルゴリズムとビットサイズは以下のいずれか一つを選択します。また、これらを設定することにより、rndc (remote name server daemon control)を利用して、ネームサーバーの動作状態の確認やゾーンファイルなどのリロードを行うことができます。

アルゴリズム	ビットサイズ
RSA	512 から 2048 の間
DSA	512 から 1024 の間で 64 の倍数
DH (Diffie Hellman)	128 から 4096 の間
HMAC-MD5	1 から 512 の間

これらは、DNSSECと TSIGをどう利用するのかによって推奨されるアルゴリズムがかわります。ここでは、一般的な TSIG で HMAC-MD5 を利用します（というより現バージョンでは HMAC-MD5 のみサポートされている）。詳細はARM（Administrator Reference Manual）を読んでください。キーの作成は、BIND パッケージを作成した際に作られた dnssec-keygen コマンド（ここでは、/usr/local/bind/sbin/dnssec-keygen）を利用します。また、FreeBSD を利用している場合、乱数を得るために -r /dev/urandomコマンドラインオプションを指定する必要があるようです。以下の、53380 の部分はハッシュ値のため任意の５桁の数字です。

# dnssec-keygen -a HMAC-MD5 -b 256 -n USER rndc
Krndc.+157+53380
# cat Krndc.+157+53380.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: XGmLSloxkQyBUvdiPBN6Y8VxSajqoc+vGFVY0+gWqR4=

キーの作成ができたので、rndc の設定を行います。この設定は、rndc.conf ファイル（ここでは /etc/rndc.conf）を作成します。

// rndc の動作の設定
options {
    default-server localhost;
    default-key "rndc_key";
};

// localhost のネームサーバーのキーの設定
server localhost {
    key     "rndc_key";
};

// rndc_key というキーの内容を設定
key "rndc_key" {
    algorithm hmac-md5;
    secret "XGmLSloxkQyBUvdiPBN6Y8VxSajqoc+vGFVY0+gWqR4=";
};

この時点で、dnssec-keygen によって作られた Krndc.+157+53380.key, Krndc.+157+53380.private という二つのファイルは削除してしまいます。

セキュリティーの強化という点では、ルートディレクトリーを変更することで上位の階層を隠すことができる chroot の機能も備えています。導入はさほど難しくないので、詳細はドキュメントを参照してください。（named のコマンドラインオプション -t を利用します。）

ドメインに関する Tips

各種設定ファイルを記述する前に、ちょっと DNSに関する Tips を記述しておきます。

ドメイン名は、アルファベット(A-Z)、数字(0-9)、マイナス(-)、ピリオド(.)からなる 24文字までの文字列で表されるもので、ピリオドはドメイン形式名の区切りとしてだけ利用されます。大文字小文字の区別はありません。マイナスやピリオドで終わってもいけません。
ホスト名に関しては RFC 953 。
DNS の RFC はたくさんあるのですが、メインは RFC 1034, 1035 。
ネームサーバは、ドメインおよびそのデータに関する情報を貯えるサーバプログラムです。一般に、管理すべきドメイン空間のサブセットに関する全ての情報を持っています。
リゾルバは、クライアントからの要求に対して、ネームサーバーからの情報を取り出すプログラムです。少なくとも一つのネームサーバにアクセスして、要求に対する回答を得ます。

各種設定ファイル

インストールが完了したら、運用に必要な各種設定ファイルを記述します。

named.conf

このファイルは、メインのサーバーである named が最初に読み込む初期設定ファイルです。（ここでは、/etc/named.conf になります） named.conf を記述する際には、C++ 言語のように、最後のセミコロンが必要なことに注意して下さい。また、コメント行についても C++言語とおなじです。C言語やシェルで使われるコメントの記述も可能です。

key, controls ステートメント	キーに関する設定を記述します。
key "rndc_key" { algorithm hmac-md5; // rndc.conf で設定したキーを指定してください。 secret "XGmLSloxkQyBUvdiPBN6Y8VxSajqoc+vGFVY0+gWqR4="; }; controls { // rndc の制御の許可/拒否を設定します。 inet 127.0.0.1 allow { 127.0.0.1;} keys {"rndc_key";}; };

options ステートメント	named 全体の動作に関連した option の設定です。
options { // ゾーンファイル等を格納するディレクトリを指定します。 // デフォルトは、カレントディレクトリである"."です。 directory "/etc/nsdb"; // ゾーン転送の許可／不許可の指定。namedがゾーン転送に応じる相手を限定します。 // デフォルトは、すべてのゾーン転送の要求に応じる "{ any; };" です。 allow-transfer { 192.168.0.1; // 特定のアドレス形式による指定方法（許可） 192.168.1.0/24; // ネットワーク形式による指定方法（許可） !192.168.2.123; // 特定のアドレス形式による指定方法（拒否） }; // 問い合わせの許可／不許可の指定。namedが問い合わせに対して答える相手を限定します。 // デフォルトは、すべての問い合わせに応じる "{ any; };" です。 // 不正アクセスの拒否等に利用します。別に blackhole というのもあります。 allow-query { 192.168.0.200; // 特定のアドレス（許可） 192.168.1.0/24; // ネットワーク（許可） !192.168.2.1; // 特定のアドレス（拒否） }; // Dynamic DNS機能を用いる場合以外は "{none;};" にしておくのが良いでしょう。 // Dynamic DNSを利用するクライアント等のアドレスリストを記述します。 // デフォルト値は "{none;};" です。 allow-update { none; }; // yes - サーバが信頼できなかったとしても、NXDOMAINレスポンスの時に // 常にAAビットを有効にする。（意味がわからなければ、yes にしてください） auth-nxdomain yes; // PID ファイルの指定（デフォルト） pid-file "/usr/local/bind/var/run/named.pid" 　　　// バージョンの問い合わせに対しての応答（デフォルトは、バージョン番号を返す） version "surely you must be joking" };

zone ステートメント hint (root cache)	ルートサーバを見付けるための hint となるデータベースファイル（ヒントファイル）を指定します。ネームサーバは、問い合わせのあったドメインについての情報を全く持っていない場合、ルートサーバを参照します。そのときに、ルートサーバのIPアドレスをヒントファイルを用いて調べます。最新の hint ファイルは、ftp://rs.internic.net/domain/named.rootにあります。以降、最新版の root.cache ファイルを入手するには dig コマンドを使用することができます。 # dig @ns.internic.net . ns > named.root
// ヒントサーバ zone "." in { // ゾーンタイプ type hint; // ルートサーバを見付けるためのヒントファイル file "named.root"; };

logging ステートメント	ログの記録を、syslogや指定したファイルなど、カテゴリー別にきめ細かく指定できます。 channel (記録ファイル名や記録レベルを指定する)フレーズで定義したオリジナルのログファイルを、 category フレーズに指定することで、syslog とは別の独立したファイルを作成することが出来ます。
logging { // オリジナルの channel を定義します。 channel bind_log { // パス名の指定 file "/var/log/named.log"; // 優先順位 severity info; }; // ゾーン転送が生じたら記録する category xfer-out { // channel 名 bind_log; }; // デフォルト category default { // syslogファイル default_syslog; }; };

zone ステートメント master (primary)	管理するドメインに関するデータベースを指定します。ネームサーバが、自前でデータベースをもつゾーンをプライマリゾーンと呼びます。ゾーンファイルと呼ばれるデータベースファイルを指定します。
// 正引きデータベースの指定 // このブロックは、zone "domainname"というブロックではじまります。 // domainnameには、ゾーンのドメイン名が入ります。 zone "foobar.co.jp." in { // ゾーンタイプ type master; // ゾーンファイル名 file "foobar.zone"; }; // 逆引きデータベースの指定 // このブロックは zone の次に、使用する IPアドレスを RFC1101 に従って指定します。 zone "1.168.192.in-addr.arpa." in { // ゾーンタイプ type master; // ゾーンファイル名 file "foobar.rev"; }; // ループバックアドレス zone "localhost." in { // ゾーンタイプ type master; // ゾーンファイル名 file "localhost.zone"; }; zone "0.0.127.in-addr.arpa." in { // ゾーンタイプ type master; // ゾーンファイル名 file "localhost.rev"; };

zone ステートメント slave (secondary)	同じゾーンを持つマスターサーバから、ゾーンをコピーしてサービスに備える場合は、slave についてのゾーンの記述が必要です。（Slaveサーバーを構築する場合必要になります）
zone "baz.ne.jp." in { // ゾーンタイプ type slave; // 障害対策のために、ネットワーク経由で入手したゾーン情報をファイルにバックアップします。 file "baz.cache"; // master サーバの IP アドレス(複数可) // ゾーン転送元となるホストを指定する。リストの先頭からデータの転送を試みますが、 // 失敗した場合は次のサーバーにアクセスします。 masters { 192.168.0.1; 178.23.0.3; }; };

もっとも単純な named.conf ファイル
key "rndc_key" { algorithm hmac-md5; secret "XGmLSloxkQyBUvdiPBN6Y8VxSajqoc+vGFVY0+gWqR4="; }; controls { inet 127.0.0.1 allow { 127.0.0.1;} keys {"rndc_key";}; }; 　 options { directory "/etc/nsdb"; }; // hint server (root chache) zone "." in { type hint; file "named.root"; }; // for zone "foobar.co.jp." in { type master; file "foobar.zone"; }; // for reverse zone "1.168.192.in-addr.arpa." in { type master; file "foobar.rev"; }; // for loopback zone "localhost." in { type master; file "localhost.zone"; }; zone "0.0.127.in-addr.arpa." in { type master; file "localhost.rev"; };

記述したら、named-checkconf （ここでは、/usr/local/bind/sbin/named-checkconf）コマンドを使用して文法のチェックを行います。

# named-checkconf /etc/named.conf

エラーメッセージが出力されなければ、正常に記述されています。最小限必要なものだけを取り上げましたが、この他にも acl などといった便利なステートメントがあります。詳細は、BIND 9 のドキュメントを参照して下さい。

ゾーンファイル

ドメイン名が必要となるサービスなどを提供するホストのドメインについてのデータベースファイルを作成する。
SOA レコードに記述する時間値に H(hour)、D(day)、W(week)、 M(month)などの略称が利用できます。ゾーンファイルは、named.conf で指定したディレクトリーに作成します。（ここでは /etc/nsdb）

【正引きデータベースファイル: foobar.zone】

; BIND 8.2 以降、デフォルトの TTL 値を記述しておく必要があるみたい
$TTL 86400
@       IN SOA      ns.foobar.co.jp. postmaster.foobar.co.jp. (
        199912131   ; シリアル
        10800       ; リフレッシュ   < 3 時間  3H と記述しても良い >
        3600        ; リトライ       < 1 時間 >
        360000      ; 期限切れ       < 100 時間 >
        86400       ; TTL            < 1日 1D と記述しても良い >
        )
 
        IN NS       ns.foobar.co.jp.
        IN NS       ns.baz.ne.jp.
;
        IN MX 10    mail.foobar.co.jp.
        IN MX 20    mail.baz.ne.jp.
;
; Name Server
ns      IN A        192.168.1.1
        HINFO       "Ultra SPARC" "Solaris 7"
;
; Mail Server
mail    IN A        192.168.1.2
pop     IN CNAME    mail
;
; Network Service Server
www     IN A        192.168.1.5
ftp     IN CNAME    www

【逆引きのデータベースファイル: foobar.rev】

; BIND 8.2 以降、デフォルトの TTL 値を記述しておく必要があるみたい
$TTL 86400
@       IN SOA      ns.foobar.co.jp. postmaster.foobar.co.jp. (
        199912131   ; シリアル
        10800       ; リフレッシュ   < 3 時間  3H と記述しても良い >
        3600        ; リトライ       < 1 時間 >
        360000      ; 期限切れ       < 100 時間 >
        86400       ; TTL            < 1日 1D と記述しても良い >
        )
;
        IN NS       ns.foobar.co.jp.
        IN NS       ns.baz.ne.jp.
;
1       IN PTR      ns.foobar.co.jp.
2       IN PTR      mail.foobar.co.jp.
5       IN PTR      www.foobar.co.jp.

【ループバック用正引きのデータベースファイル: local.zone】

; BIND 8.2 以降、デフォルトの TTL 値を記述しておく必要があるみたい
$TTL 86400
@       IN SOA      ns.foobar.co.jp. postmaster.foobar.co.jp. (
        199912131   ; シリアル
        10800       ; リフレッシュ   < 3 時間  3H と記述しても良い >
        3600        ; リトライ       < 1 時間 >
        360000      ; 期限切れ       < 100 時間 >
        86400       ; TTL            < 1日 1D と記述しても良い >
        )
        IN NS       ns.foobar.co.jp.
;
localhost. IN A     127.0.0.1

【ループバック用逆引きのデータベースファイル: local.rev】

; BIND 8.2 以降、デフォルトの TTL 値を記述しておく必要があるみたい
$TTL 86400
@       IN SOA      ns.foobar.co.jp. postmaster.foobar.co.jp. (
        199912131   ; シリアル
        10800       ; リフレッシュ   < 3 時間  3H と記述しても良い >
        3600        ; リトライ       < 1 時間 >
        360000      ; 期限切れ       < 100 時間 >
        86400       ; TTL            < 1日 1D と記述しても良い >
        )
        IN NS       ns.foobar.co.jp.
;
1       IN PTR      localhost.

上記レコードの型(type)の概略を簡単に記述します。

SOA

SOA (Start of Authority)レコードは、ゾーン管理の開始であることを意味します。
@ の部分は、本来ならドメイン名が入ります。もし、@ と記述されている場合（ほとんどの場合 @ です）、named.conf に記述されたドメイン名（foobar.co.jp）が記述されているのと同じ意味になります。逆引のゾーンファイルに記述されている @ は、named.conf に記述された「1.168.192.in-addr.arpa」と同じ意味になります。
SOA には続いて、ネームサーバのホスト名、連絡者のメールアドレス（@を . に置き換えたもの）が入ります。

シリアル	ゾーンファイルのシリアル番号です。いつ修正したかわかるように、西暦日付＋修正回数のような意味で YYYYMMDDR のように記述していますが、1 から始まっても構いません。ただし、忘れてはならないのが、このゾーンファイル(逆引きファイルも含む)を修正した場合、このシリアル番号に +1 以上加算する必要があります。slave サーバーは、master のシリアル番号を見てキャッシュの内容を更新します。そのため、ゾーンファイルを書き換えても、このシリアル番号をあげ忘れると slave サーバのデータは更新されません。シリアル番号の上げ忘れには、十分に注意してください。また、`rndc reload`を実行してネームサーバーにゾーンファイルを再読込させてください。ここで、ちょっと気になるのがシリアル番号(32bit値)は無限ではないということです。そのため、RFC 1982 にシリアル番号の計算方法の記述があります。要約すると、シリアルが限界に達した場合、最初に戻る（１の方が大きくなる）ということです。
リフレッシュ	どのくらいの頻度（時間の間隔）でデータの正確さを master に確認しにいくかを、slave に対して指定します。間隔が長過ぎると更新にタイムラグが発生し、短過ぎると問い合わせが多発します。
リトライ	slave サーバが master サーバにアクセスしても応答がない場合に、slave サーバが master サーバへのアクセスをリトライする時間の間隔です。通常は「リフレッシュ」より短い値を指定します。
期限切れ	ここで指定された期間以内に slave サーバが master サーバにアクセスできなかった場合、slave サーバはそのゾーンについてのデータを全て破棄します。破棄された後に、slaveサーバに対してゾーンについて問い合わせがあっても slaveサーバは回答しません。古い内容で返答するよりも、返答しない方が良いからです。期限切れの時間は、リトライ時間やリフレッシュ時間よりも長く設定しなければなりません。
TTL	TTL(Time To Live:生存時間) ：リソースレコードをキャッシュに保持できる最小時間を設定します。ホストごとに明示的に TTL を設定したい場合； www 90000 IN A 192.168.1.5 のように IN の前に指定します。

NS (Name Server)レコードは、ドメインに対して認証されたネームサーバを指定します。本来 IN の前には、ネームサーバによって保持されているドメイン名(foobar.co.jp)のゾーンデータを記述します。しかし、省略するができます。省略した場合、直前のレコードと同じものを指定していることになります。(ここでは、直前の SOA レコードの @ つまり foobar.co.jp が入ります)。省略せずに記述した場合、以下のようになります。

foobar.co.jp.  IN NS       ns.foobar.co.jp.

注意しなければならないことに、最後が . (ピリオド) で終わっている必要があるということです。もし foobar.co.jp のようにピリオドがない場合、named は、foobar.co.jp.foobar.co.jp と補完してしまいます。

MX (Mail Exchange)レコードは、ドメイン名に対するメール交換を行うホストを指定します。MXレコードは、ドメイン名に対して優先値とメールサーバのホスト名を持っています。この優先値が小さいメールサーバから、メールの送信を試みます。

A (Address)レコードは、ホスト名に対応する IP アドレスを記述します。DNS を利用する目的である、IP アドレスと名前の関連づけるために必要なレコードが A レコードです。
上記の例では ns というマシン名ですが、ピリオドが省略されているので 192.168.1.1 という IP アドレスは ns.foobar.co.jp という名前が関連づけられます。

HINFO

HINFO (Host Information)レコードは、利用している CPU や OS などの情報を記述します。といっても、あまり詳しくこの情報を記述すると、「こんなマシンを使っているのか...」とわかってしまいハッキングの対象にされやすくなることがあります。社内専用のネームサーバの場合、有効的なレコードとなるでしょう。

CNAME

CNAME (Canonical Name)レコードは、別名を指定する際に利用します。
A レコードに記述されるホスト名が正式名となるが、そのホストに別名を付けたい場合に CNAME レコードを使用します。メールサーバーは、何かと情報がメールのヘッダに付くので CNAME で与えた名前を設定せずに A レコードで記述したほうが良い。

PTR

PTR (Pointer)レコードは、IP アドレスに対応するドメイン名を記述します。
上記の例では、クラスC の IP アドレスであるため 192.168.1.1 の最後の 1 だけ記述されています。もし、クラス B の IP アドレスの場合、アドレスが 172.114.10.3 であっらなら RFC 1101 に従い 3.10 となります。このレコードの場合、右側のホスト名を省略された形で書いてはいけない。これを ns と省略して書いてしまうと、補完して解釈するためホスト名が ns.1.168.192.in-addr.arpa となってしまうからです。さらに最後は .(ピリオド) で終わる必要があります。

resolv.conf

このファイルは、ホストがどのネームサーバを利用するか記述しておくものです。（/etc/resolv.conf）

domain	デフォルトドメインを設定することができます。ここで指定するドメイン名は、ピリオドやスペースで終わってはいけません。
search	デフォルトドメインを設定した時にできるデフォルトの検索リストを用いたく無い時に使用する。resolv.confには、domain命令とsearch命令のいずれか一方があれば良いのだが両方記述しても構いません。その場合、後に書かれた方が優先されます。
nameserver	master, slave といったネームサーバについて記述しました。しかし、ネームサーバは動かしたくないけど DNSは利用したいようなホストがあると思います。全てのホストでネームサーバを動かすのはナンセンスですね。そんな時に、参照するネームサーバを指定するのが nameserver 命令です。

システムがネームサーバとして動作している場合、自分自信なので以下のように書きます。

nameserver      127.0.0.1
search          foobar.co.jp

named の起動とテスト

各ファイルの設定が完了したら named を起動させ、きちんと名前が引けるかテストをします。起動後は、正常に起動しているかどうか syslog を必ず確認してください。また、それぞれのファイルのパーミッションをきちんと設定しておきます。

# chown root:named /etc/named.conf /etc/nrdc.conf
# chmod 640 /etc/named.conf /etc/nrdc.conf
# chown -R named:named /etc/nsdb
# chmod 640 /etc/nsdb/*
# /usr/local/bind/sbin/named -u bind

最終的には、起動スクリプトを作成してシステム起動時に実行されるように設定してください。/etc/rc.d/init.d や /etc/init.d などに起動スクリプトを作成する。

名前引きのテスト

nslookup を利用して、自分が設定したドメイン名が正しく引けるかどうかをテストします。

Default Server:  localhost
Address:  127.0.0.1
 
>
> www.foobar.co.jp.
Server:  localhost
Address:  127.0.0.1
 
Name:    www.foobar.co.jp
Address:  192.168.1.5
>
> 192.168.1.5
Server:  localhost
Address:  127.0.0.1
 
Name:    www.foobar.co.jp
Address:  192.168.1.5
>
> set type=mx
> foobar.co.jp.
Server:  localhost
Address:  127.0.0.1
 
foobar.co.jp        preference = 10, mail exchanger = mail.foobar.co.jp
mail.foobar.co.jp   internet address = 192.168.1.2
> 
> set type=ns 
> foobar.co.jp.
Server:  localhost
Address:  127.0.0.1
 
foobar.co.jp        nameserver = ns.foobar.co.jp
ns.foobar.co.jp     internet address = 192.168.1.1

ゾーンファイルなどを変更した際にアップデートする方法

ゾーンファイルなどを変更したなら、rndc コマンド（ここでは /usr/local/bind/sbin/rndc）を利用ます。

# rndc
    Usage: rndc [-c config] [-s server] [-p port]
            [-k key-file ] [-y key] [-V] command
 
    command is one of the following:
 
      reload        Reload configuration file and zones.
      reload zone [class [view]]
                    Reload a single zone.
      refresh zone [class [view]]
                    Schedule immediate maintenance for a zone.
      reconfig      Reload configuration file and new zones only.
      stats         Write server statistics to the statistics file.
      querylog      Toggle query logging.
      dumpdb        Dump cache(s) to the dump file (named_dump.db).
      stop          Save pending updates to master files and stop the server.
      halt          Stop the server without saving pending updates.
      trace         Increment debugging level by one.
      trace level   Change the debugging level.
      notrace       Set debugging level to 0.
      flush         Flushes all of the server's caches.
      flush [view]  Flushes the server's cache for a view.
      status        Display status of the server.
      *restart      Restart the server.
 
    * == not yet implemented
    Version: 9.2.1
# rndc reload

DNS ラウンドロビンを利用した負荷分散

これは、同一ドメインに複数の IPアドレスを指定した場合、アドレスが返される順序がその都度変わるという仕組みを利用してサーバの負荷分散を行なう手法です。

www     IN A        192.168.1.5
www     IN A        192.168.1.6

上記のように、一つのドメインに複数のサーバーを指定しておきます。

【クライアントＡ】
# dig @192.168.1.1 www.foobar.co.jp
 ...
;; ANSWER SECTION:
www.hdrc.com.           43200   IN      A       192.168.1.5
www.hdrc.com.           43200   IN      A       192.168.1.6
 ...
#

【クライアントＢ】
# dig @192.168.1.1 www.foobar.co.jp
 ...
;; ANSWER SECTION:
www.hdrc.com.           43200   IN      A       192.168.1.6
www.hdrc.com.           43200   IN      A       192.168.1.5
 ...
#

クライアントから問い合わせてみると、上記のように返されるアドレスの順番が変わります。複数のアドレスを受け取ったクライアントは、最初に受け取ったアドレスを目的のホストのIPアドレスとして解釈するので結果として負荷分散に利用できるというわけです。もう少し効率的に分散の効果を行いたいなら、以下のように各レコードのTTLを短い時間で明示的指定します。

www     1h   IN A        192.168.1.5
www     1h   IN A        192.168.1.6

この DNS ラウンドロビンを利用した負荷分散は、それぞれのマシンの能力似合わせて負荷分散してくれるわけではなということと、サーバーに問題が発生した場合に IPアドレスを返すのをやめるという機能はないということに注意してください。

ちょっと IPv6

IPv6 になると、どのように記述するのか？と疑問が湧くかも知れませんが基本的にはかわりません。ただし、128ビットなので以下のようになります。A が従来の IPv4 のアドレスとなり、AAAA が IPv6 でのアドレスになります。

【正引き】

; IPv6 Sample
$TTL 86400
@               IN SOA ns.ipv6.foobar.co.jp. postmaster.ipv6.foobar.co.jp. (
                199912131   ; Serial (yyyymmddr)
                10800       ; Refresh 3 hours
                3600        ; Retry   1 hour
                360000      ; Expire  1000 hours
                86400)      ; Minimum 24 hours
                IN NS       ns.ipv6.foobar.co.jp.
                IN NS       ns.ipv6.baz.ne.jp.
;
localhost       IN A        127.0.0.1
;
newer           IN A        128.173.88.82
newer           IN AAAA     5F05:2000:80AD:5800:0058:0800:2023:1D71
                IN HINFO    UltraSPARC  Solaris7
                IN MX       100         mail.ipv6.foobar.co.jp.
;
older           IN A        128.173.88.83
older           IN AAAA     5F05:2000:80AD:5800:0058:0800:2023:2F8E
                IN HINFO    PDP11/80    UNIX
;
soso            IN A        128.173.88.78
soso            IN AAAA     5F05:2000:80AD:5800:0058:00AA:00B7:AF2B
                IN HINFO    P700        WIN2000

【逆引き】

; IPv6 Sample rev
$TTL 86400
;
@               IN SOA ns.ipv6.foobar.co.jp. postmaster.ipv6.foobar.co.jp. (
                199912131   ; Serial (yyyymmddr)
                10800       ; Refresh 3 Hours
                3600        ; Retry   1 hour
                3600000     ; Expire  1000 hours
                86400 )     ; Minimum 24 hours
                IN NS       ns.ipv6.foobar.co.jp.
                IN NS       ns.ipv6.baz.ne.jp.
;
1.7.d.1.3.2.0.2.0.0.8.0     IN PTR      newwer.ipv6.foobar.co.jp.
e.8.f.2.3.2.0.2.0.0.8.0     IN PTR      older.ipv6.foobar.co.jp.
b.2.f.a.3.2.0.2.0.0.8.0     IN PTR      soso.ipv6.foobar.co.jp.

注意点

最もよくありがちな問題について取り上げます。

シリアル番号を増やし忘れる	ゾーンファイルを変更したのに、slave がその変更を感知しないことがある。これは、シリアル番号が同じであるため slave がゾーンデータに変更が無いと思ってしまうのです。これをチェックするには、シリアル番号を覚えている以外に、変更したかどうか知る方法はありません。最良の方法は、nslookup を使用して master と slave の返すデータを比較することです。
ネームサーバへ HUP シグナルを送り忘れる	ネームサーバは、新しいデータを読み込まなければ変更に気が付きません。更新したゾーンファイルをネームサーバに読み込ませるには、HUPシグナルを送って下さい。
PTRレコードを加え忘れる	Aレコードを加えるのは、ホストに追加に /etc/hosts を追加するのに慣れているので忘れることはないが、PTRレコードは忘れる時がある。PTRレコードを加え忘れると、そのホストの認証チェックが必要なrsh, rcpの実行の失敗につながります。 nslookup コマンドで、名前と IPアドレスによるチェックを行って下さい。
設定ファイルやゾーンファイルの文法エラー	ネームサーバを起動した時にエラーがでなくても、syslog に出力されている可能性があるので注意して確認して下さい。
名前の最後に "." をつけ忘れる	ゾーンファイルを編集している時、最後のピリオド"." をつけ忘れることがあります。正引きのゾーンファイル中のホスト名で、最後のピリオドが無い場合ものにはすべてドメイン名が付加さて解釈されます。ホスト名だけの記述なら構いませんが、ドメイン名まで指定してピリオドが無かった場合、二重にドメインが付いた名前となってしまいます。
ヒント（キャッシュ）データが無い	なんらかの原因でヒントデータが無かった場合、ネームサーバは自分が権威を持っているデータに含まれていない名前を解決することが出来ません。syslog中に "No root nameservers for class 1" といったようなエラーがあった場合、ヒントデータが無いことを意味します。
resolv.conf ファイルの文法エラー	リゾルバは、resolv.conf の記述が間違っていてもエラーにならず無視してしまいます。そこで、resolv.conf の設定が正しいか nslookup コマンドを使用して確認して下さい。set all に対する出力が期待通りか調べて下さい。ドメイン名の後ろにスペースがあると、うまく動作しないことがあります。
デフォルトドメインが設定されていない	デフォルトドメインが設定されていないと、ホスト名だけでは認識されないが、ドメイン名を含めると認識されるなどといった不具合が生じます。この問題は、nslookupコマンドの set all に対する出力で、ドメイン名やサーチリストが設定されていないことに気付くことで発見できます。

BIND 9

Domain Name Systemの導入と設定（BIND 9編）

インストール

ドメインに関する Tips

各種設定ファイル

named の起動とテスト

DNS ラウンドロビンを利用した負荷分散

ちょっと IPv6

注意点

メインメニュー

Languages

Web

Wizardry

Design

Trivia

Links