hikaku-server
BINDの設定方法（オープンリゾルバ対策含む）
BIND 9の設定方法です。
BIND 9は脆弱性が発見されることが非常に多いです。
運用中に度々対応するようにした方が良いです。
また、自分でDNSサーバを構築した場合は、ネームサーバ運営のためレジストリへの
申請依頼とWHOIS情報のネームサーバ項の変更を忘れずに行いましょう。
BINDのセットアップからWHOIS情報登録までの一連の流れについて、
以下のページに記載しました。
その他、本サイト内の関連ページ
またJPRSが2016年1月に作成された資料が、
BINDの設定にあたり参考になります。
こちらはJPRSによる、DNSに関する過去の履歴です。
本ページの目次
オープンリゾルバにしない設定
オープンリゾルバであるかどうかは以下のサイトで確認できます。
wgetでの確認方法も記載されていました。
[root@dti-vps-srv94]# wget -qO - http://www.openresolver.jp/cli/check.html
Configured DNS server: [NOT open] 202.216.224.10(nsc0-06.dti.ad.jp)
Source IP address: [NOT open] 27.120.*.*(v-27-120-*-*.ub-freebit.net)
1行目はresolv.confでの（負荷分散後）DNSサーバ、
2行目は自サーバ（wgetを実行したサーバ）の結果です。
※また、家庭用ルータがオープンリゾルバになっている設定例が
以下のサイトに記載されていました。
権威DNSサーバとDNSキャッシュサーバを兼ねたサーバの場合
※権威DNSとキャッシュDNSの兼用サーバは、ISCとしては推奨していません。
acl "internal" {
192.168.1.0/24;
localhost;
};
options {
recursion yes;
// 再帰検索可能（＝リゾルバの動作可能）
allow-query { any; };
//全ての通信元のクエリを許可する
allow-recursion { internal; };
//通信元が内部からである時のみ再帰検索可能にする
allow-query-cache { internal; };
//通信元が内部からである時のみキャッシュを回答する
//※allow-query-cacheはBIND 9.4.0以降
};
view "viewname1" {
match-clients { internal; };
以下、ゾーンファイル情報を記載
};
view "viewname2" {
match-clients { any; };
以下、ゾーンファイル情報を記載
};
DNSキャッシュサーバの場合
acl "internal" {
192.168.1.0/24;
localhost;
};
options {
recursion yes;
// 再帰検索可能（＝リゾルバの動作可能）
allow-query { internal; };
//通信元が内部からである時のみクエリを許可する
allow-recursion { internal; };
//通信元が内部からである時のみ再帰検索可能にする
allow-query-cache { internal; };
//通信元が内部からである時のみキャッシュを回答する
//allow-query-cacheはBIND 9.4.0以降
権威DNSサーバの場合
options {
recursion no;
// 再帰検索不可（＝リゾルバの動作不可）
allow-query-cache { none; };
// 全ての通信元に対してキャッシュを回答しない
参照サイト
named.confのステートメントごとの設定
オープンリゾルバについて
BIND9.4以降のallow-query、allow-query-cache、allow-recurtionについての挙動の説明
同じゾーン名のゾーンファイルが複数ある場合のゾーン転送方法
初期設定ではセカンダリDNSサーバへのゾーン転送時、セカンダリDNSサーバ
としては同じゾーン名のゾーンファイルが複数ある場合はゾーンファイル名が
違っても同じものとして扱われるようでした。異なったゾーンファイル名で
2つ取得できたとしても、中身を見ると同じ内容になってしまっている。
そもそも同じゾーン名でゾーンファイルを複数作成する意味は以下の理由です。
DMZにDNSサーバがある場合を想定しています。
インターネット側からの問い合わせに対しては、DMZにあるWEBサーバの
IPアドレスについて、FWでNATを行う前のグローバルIPアドレスを返答したい。
他方、内部からの問い合わせに対してはDMZのWEBサーバの素のプライベート
IPアドレスを返答したい。
対策方法
外部用view、内部用viewでそれぞれ定義した外部用ゾーン「a.jp」の
ゾーンファイル「a.jp_external」と、内部用ゾーン「a.jp」のゾーンファイル
「a.jp_internal」をそれぞれ転送し貰ってくる場合に、
プライマリDNSサーバのACLの定義で
internal
!192.168.1.2; ←セカンダリDNSサーバのサブインタフェースのIPアドレス
192.168.1/24; ←内部セグメントのサーバ（PC）群のIPアドレスレンジ
external
any;
と設定する。
※ACL「external」はany;のみなので定義しなくても良いかもしれません。
その後、
内部用ゾーンのviewの「match clients」はACL「internal」、
「allow-transfer」はセカンダリDNSサーバのeth0のIPアドレス「192.168.1.1」
外部用ゾーンのviewの「match clients」はACL「external」、
「allow-transfer」はセカンダリDNSサーバのサブインタフェースであるeth0:1の
IPアドレス「192.168.1.2」
そしてセカンダリDNSサーバのnamed.confに「transfer-source」を記載し
プライマリDNSサーバへゾーンファイルを取りに行くIPアドレスをそれぞれ変える。
すると正しくそれぞれのゾーンファイルを取得出来ます。
その他の対策方法
・それぞれプライマリDNSサーバとする
一般的なmaster/slaveでの冗長DNSサーバ構成では無く、
内部用ゾーン「a.jp」のプライマリDNSサーバ、
外部用ゾーン「a.jp」のプライマリDNSサーバ
をそれぞれ別のサーバで構成する
・ゾーン転送は行わず、ゾーンファイルはコピーで対応する
そもそもDNSのゾーン同期機能を使用せず、rsyncやスクリプト等で
ゾーンをコピーする
サブインターフェイスを作成した際の留意点
eth0を停止したままeth0:1から起動、などのeth0:1を主とさせる動作を行った場合
それ以降eth0:1が代表IPアドレスになってしまう。
プライマリDNSへ問い合わせに行く際、eth0:1のIPアドレスで問い合わせに
行ってしまうことに注意すること。
セカンダリDNSサーバのreslov.confで優先DNSサーバをプライマリDNSサーバ
に設定していた場合、internalにのみallow-recursionしている設定では、
まず「!192.168.1.2;」に引っ掛かってしまい、再帰問い合わせ不可になる。
DNSに関する用語
■リゾルバ
爆風スランプの大ヒットシングル
DNSサーバーへアクセスし、ドメイン名前空間から
任意のノードの情報を取得する機能。
■ゾーン
ほぼ、「ドメイン」と同じ。
■Unbound
BINDの代替を目指したDNSキャッシュサーバ
■NS(Name Server)レコード
BINDの設定で、ドメイン名のゾーン情報が登録されている
DNSサーバを指定するためのレコード。
■MX(Mail eXchange)レコード
メールサーバを指定するためのレコード。
複数指定できる。優先順位も設定できる。
■グルーレコード(glue record)
親ドメインの定義に記載されたサブドメインのNSレコードの事。
BINDの設定方法
※以下のページの方が分かりやすいかもしれません。
BINDをCentOS5で設定します。
本来はchrootで動作させた方が良いかと思います。
自動起動の確認
[root@aaa ~]# chkconfig --list | grep named
自動起動させる
[root@aaa ~]# chkconfig named on
namedデーモンの再起動
[root@aaa ~]# service named restart
named.confの編集
vi /etc/named.conf
※以下のorangeゾーンを追加しました。
zone"orange.local" IN {
type master;
file"orange.local.zone";
allow-update { none; };
};
サンプルのゾーンファイルをコピーし作成
named.confに追記したゾーン「orange.local」情報を
ゾーンファイルに書き込みます。
1から作るのは面倒なためゾーンファイルをコピー。
[root@aaa etc]# cd /var/named/chroot/var/named
[root@aaa named]# cp -p localdomain.zone orange.local.zone
7行目の「1D ) ; minimum」までの編集箇所
・localhostを自ホスト名のaaaに変更
・SOAレコードのシリアル番号を 2010100800 へ変更
※SOAレコードの書き方は、ゾーンファイルの更新日（YYYYMMDDnn）
など10桁の数字記述が一般的です。また、DNSサーバの入れ替え時には
TTLを短くしたりします。
8行目以降は以下のようにしました。
IN NS aaa.orange.local.
IN MX 10 mail.orange.local.
aaa IN A 192.168.183.131
www IN A 192.168.183.131
mail IN A 192.168.183.131
vhost1 IN A 192.168.183.131
vhost2 IN A 192.168.183.131
※NSやMXのFQDNの末尾に「.」を付けること。
※SOAレコードについて
namedの再起動・状態確認・ログ確認
tail -f /var/log/messages
/etc/init.d/named restart
/etc/init.d/named status
動作確認
[root@aaa]#nslookup www.orange.local
server: 192.168.183.131
Address: 192.168.183.131#53
Name: www.orange.local
Address: 192.168.183.131
DNSサーバーを指定した上での問い合わせ
[root@aaa]#nslookup www.orange.local 192.168.183.131
server: 192.168.183.131
Address: 192.168.183.131#53
Name: www.orange.local
Address: 192.168.183.131
問題無く名前解決が行われました。
digコマンドでゾーン情報を確認する。
[root@aaa ~]# dig orange.local axfr
※digコマンド実行時、DHCP環境ではdhclient-scriptが作成した
resolv.confの内容を参照するため、今回は静的IPアドレスを振りました。
[root@aaa ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.183.131
NETMASK=255.255.255.0
[root@aaa ~]# service network restart
※この時点でresolv.confは空ファイルになります。
vi resolv.conf
nameserver 192.168.183.131
再度digコマンドでゾーン情報を確認する。
[root@aaa ~]# dig orange.local axfr
[root@aaa ~]# dig orange.local mx
ゾーン情報を正しく見ることが出来ました。
DNSサーバーを指定してdigコマンドを実行するには
[root@aaa ~]# dig orange.local @192.168.183.131 axfr