MENU

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