BINDの設定方法

目次

BIND8の環境は「BIND8の設定方法」を参照してください。新たにBIND9をインストールする場合、BIND8からBIND9に移行する場合は「BIND9 バージョンアップ」からご参照ください。

BIND8の設定方法
BIND9 バージョンアップ
BIND9へ移行
BIND9の設定
BIND9のrndc.key
BIND9の起動
BIND導入の注意点
戻る

BIND9 バージョンアップ

今回のサンプルはBIND9.2tar.gzです。インストール方法についてはメインページのインストールログを参照して下さい。
アップデートする場合、BIND8の設定ファイルをBIND9でほぼそのまま再利用する事ができます。

BIND8の設定方法はこちらです。

BIND9へ移行

今、現在の最新版は9.2です。http://planetmirror.com/pub/isc/bind9/などからダウンロードしてください。デフォルトのインストール先は/usr/local/sbinです。Solarisへインストールする場合はin.named(bind8.1.2)がもともとインストールされていますので、設定変更が必要です。他、変わった点としては、8系時代に、セカンダリへのゾーン転送にnamed-xferというプログラムがありましたが、9系ではnamedに統合されています。そのため、optionsの中の「named-xfer "/usr/local/sbin/named-xfer";」という行は必要なくなりました。また、コメントアウトとして、「;」だけで、1行すべてコメントアウトすることができなくなりました。「;」があくまで、行の終わりを認識させるための記号として認識されるようです。そしてzoneテーブルには必ず $TTL time を先頭に記述しなくてはいけなくなりました。zoneテーブルの使いまわしを考えているのなら、$TTLの追記は忘れずに行いましょう。Solarisのin.named(bind8.1.2)からbind9への移行はinit.dに依存しますので全ての設定がおわってから紹介します。

BIND9の設定

BIND起動用ユーザbindを作成します。

# useradd -s /bin/false -d /usr/local/bind bind
# chown bind /usr/local/bind
 

bindユーザーで起動したBINDからは/var/run/name.pidを作成できなくなりますので、named.pidの置き場所は/usr/local/bind/runにしておきます。

# mkdir /usr/local/bind/run/
# chown bind /usr/local/bind/run/

named.confにて
optionでpid-file "/usr/local/bind/run/named.pid";を指定します。

その他のnamed.confは以下を参照してください。

acl

named:サービスを許可する、あるいは禁止するIPアドレスのアクセス制御リストを設定します。たいていの場合、(10.0.1.0/24などの)個々のIPアドレスかIPネットワークの表記を使用して正確なIPを識別 します。また次の様な定義語を使う事もできます、
any:すべてのIPアドレスと一致。
localhost:ローカルシステムによって使用されているIPアドレスと一致。
localnets:ローカルシステムがそのインターフェイスで接続するネットワークのIPアドレスと一致。
none:どのIPアドレスとも一致しない。

controls
rndcコマンドを使ってnamedサービスを管理するのに必要なさまざまなセキュリティ要件を設定します。

include "<file-name>"
現在の設定ファイル内にある指定されたファイルをインクルードして、(keysなどの)機密設定データを許可つきの別 のファイルに置き、特権の与えられていないユーザーが読むのを防ぐことができます。

logging
ロギングの詳細(ログファイル、ファイルサイズ、ログ内容など)を定義します。

key "<key-name>"
名前ごとに鍵を定義します。鍵は、安全な更新やrndcコマンドの使用などさまざまな動作を認証するものです。keyでは、2つのオプションを使用することができます。
algorithm :使用されるアルゴリズムのタイプ。 dsaやhmac-md5など。
secret:"<key-value>" 暗号鍵。

options
フォワーダの使用、named作業ディレクトリの位置、さまざまなファイルの名前などの多種多様なオプションを割り当てます。
option-view
Bind9の新機能の一つであり、問い合わせを行ってきた相手によって違った答えを返す事ができます。

//サンプルA

options {
directory "/var/named";  ゾーンテーブルの保存先
pid-file "/usr/local/bind/run/named.pid";  name.pidの保存先
};
zone "0.0.127.in-addr.arpa" in { ローカルの逆マッピング (BIND4なら.revという使い方をします)
type master;
file "db.local"; 127.0.0.のテーブルファイル名
};
zone "." in { ルートDNSの情報定義
type hint;
file "named.root";
};
zone "hoge.com" in {  hogeゾーンのテーブルファイルの定義
type master;
file "hoge.com.zone";
};
zone "11.10.201.in-addr.arpa" in { hogeゾーンの逆マッピング
type master;
file "11.10.201.in-addr.arpa.zone";
};

 

//サンプルB

acl local {
10.0.2.0/24;
192.168.0.0/24;
};
acl extra {
10.0.1.0/24;
};
options {
blackhole { local; };
allow-query { extra; };
allow-recursion { extra; };
};

 

//サンプルA+サンプルB

acl local {
 192.168.0.0/24; localを定義
 127.0.0.1;
};

options {
 directory "/var/named"; ゾーンテーブルの保存先
 pid-file "/usr/local/bind/run/named.pid";  name.pidの保存先

 auth-nxdomain yes; NXDOMAIN で常に AA をセットします。
 allow-transfer { local; }; 
 allow-query { local; };

};

view "internal" {
 match-clients { local; };
 recursion yes;

 zone "." {
  type hint;
  file "named.root";
 };

 zone "0.0.127.in-addr.arpa"{
  type master;
  file "localhost.rev";
 };

 zone "syns.net"{
  type master;
  file "local.syns.zone";
 };

 zone "0.168.192.in-addr.arpa"{
  type master;
  file "0.168.192.rev";
 };

};

view "external" {
  match-clients { any; };

  allow-query { any; };
  recursion no;
  zone "." in {
  
type hint;
  file "named.root";
  };

};

 

//サンプルC

view "external" {
  match-clients { any; };
  allow-query { any; };
  recursion yes;
  zone "." in {
  type hint;
  file "named.root";
 };

 zone "syns.net" in {
  type slave;
  file "local.syns.zone";
  masters { 192.168.0.101; };
 };

 zone "0.168.192.in-addr.arpa" in {
  type slave;
  file "0.168.192.rev";
  masters { 192.168.0.101; };
 };

};

文法的なチェックは、次のように行います。

# /usr/sbin/named-checkconf /etc/named.conf.test 

エラーが出力されなければ、そのまま/etc/named.confに移動してnamedを再起動しても問題ないでしょう。チューニングはその後に行えばよいと思います。

BIND9のrndc.key

BIND9から起動時にrndc.keyの有無を問われます。無くても警告の後、問題なく動作しますが管理者が必要性を感じた場合は、次の様にして作成して下さい。

# /usr/local/bind/sbin/dnssec-keygen -a HMAC-MD5 -b 512 -r /dev/urandom -n USER bind

このコマンドにより Kbind.+157+XXXXX.key、 Kbind.+157+XXXXX.private という 二つのファイルがカレントディレクトリに作られます。 このうち Kbind.+157+XXXXX.key の内容のうち"bind. IN KEY 0 2 157 " 以降を エディターを使って /etc/rndc.key に保存してください。記述内容は下記の様になります。(*はKEY文字列の部分です)

key "key" {
algorithm hmac-md5;
secret "****************";
};

取り扱いに注意する為に権限をbindユーザの読み取り専用にします。

# chown bind:bind /etc/rndc.key
# chmod 400 /etc/rndc.key

BIND9の起動

in.namedからBIND9のnamedに切り替えます。普段Solarisのネームデーモンはinetsvcからin.namedが呼び出されていますのでそれを/usr/local/bind/sbin/namedに置き換えましょう。
/etc/rc2.d/S72inetsvc

引数 stopの定義
'stop')
#/usr/bin/pkill -x -u 0 'in.named|inetd'
/usr/bin/pkill -x -u 0 '/usr/local/bind/sbin/named|inetd'
exit 0

インストールしたnamedを起動させる。
#if [ -f /usr/sbin/in.named -a -f /etc/named.conf ]; then
# echo 'starting internet domain name server.'
# /usr/sbin/in.named &
#fi
if [ -f /usr/local/bind/sbin/named -a -f /etc/named.conf ]; then
echo 'starting internet domain name server.'
/usr/local/bind/sbin/named -u bind
(-t /usr/local/bind &)
fi
 

rootDNSサーバーの情報を定期的に更新しておく方が望ましいので
/usr/local/bind/bin/dig @e.root-servers.net . ns >/var/named/named.root
の出力をcronデーモンを使ってnamed.rootに追記します。
ただこのままではいけません。もしもdigの取得が失敗した場合、DNSが正しく機能しなくなってしまいますから以下に記した様にnamed.root.newを間にかませましょう。
SolarisのrootDNSサーバーメンテナンスのスクリプトを用意しましたので定期的に使って下さい。

#!/bin/sh
/usr/local/bind/bin/dig @e.root-servers.net . ns >/var/named/named.root.new 2>&1
case `cat /var/named/named.root.new` in
*NOERROR*)
# OK
:;;
*)
cat /var/named/named.root.new
echo "name.root file has FAILED."
exit 0
;;
esac

chown bind /var/named/named.root.new
rm -f /var/named/named.root.old
mv -f /var/named/named.root /var/named/named.root.old
mv -f /var/named/named.root.new /var/named/named.root
pkill -HUP named
echo "name.root file update"
exit 0


BIND導入の注意点

ファイアーウォールを導入すると、DNSサーバーに障害が起きる場合があります。

ファイアーウォールとDNSサーバー
DNSサーバーはDMZ上に置く事が一般的ですが、もし構成上ファイアーウォールの配下にDNSサーバーを置く場合、リゾルバーの問い合わせに使うポートはルーティングないしはフォワードしておかなくてはいけません。よく起こる失敗は53/tcpを開けている場合です。ルートネームサーバーは53/udpにて名前解決を求めてきます。tcpではありません。ですので開けるポートは53/udpにしておく必要があります。使わない53/tcpを開いているとセキュリティー上好ましくありません。もし内部にクラッカー共犯者がいる場合、telnetポートを53にかえられてしまえば53/tcpは外部からファイアーウォールを透過してリモートログインできる絶好の穴になってしまう恐れがあります。
しかし53/tcpを閉じてしまった後で、外部のセカンダリーDNSサーバーの情報が更新されていないといった障害は起こってはいませんか?実はセカンダリーDNSサーバーはルートネームサーバーを経由してプライマリーDNSサーバーに情報の更新確認をするのですが、その場合は53/tcpを使います。ですからファイアーウォールの外部にセカンダリーDNSサーバーがある場合は、53/tcpをルートネームサーバーからのみフィルターを透過させるか、仕方がなく全面 透過させるかにしておかなくてはいけません。普通は後者の方法をとるでしょう。
普段、ネットワーク管理者が53/tcp 53/udpの両方を開けているのはそういうことです。もちろん外部にセカンダリーDNSサーバーがない場合は53/tcpは閉じてもらうようネットワーク管理者に依頼しましょう。

 


<関連書籍の購入>
DNS&BIND(第4版)

DNS&BINDクックブック―ネームサーバ管理者のためのレシピ集


<戻る>