DNSコンテンツサーバの構築メモです。
調べていて気付いたのですが、DNSコンテンツサーバは「権威DNSサーバ」とも呼ぶそうです。JPNICやIIJのサイトでは「権威DNSサーバ」と表記されていますので、もしかしたらこちらが正式な名称かもしれません。
コンテンツサーバとキャッシュサーバの違い
DNSサーバには「DNSコンテンツサーバ」と「DNSキャッシュサーバ」の２種類があり、どちらもインターネットの根幹を支える重要なサーバです。
DNSコンテンツサーバは、ドメイン名とIPアドレスを対応づけたドメイン情報を持っていますが、DNSキャッシュサーバはドメイン情報を持っていませんので、クライアントから問合せを受けると、別のDNSサーバに問合せを行い、結果をクライアントに返します。これを「再帰検索」といいます。DNSコンテンツサーバはこの「再帰検索」行わないのが特徴です。
設定次第では、DNSコンテンツサーバとDNSキャッシュサーバを同居させることも可能ですが、DNSキャッシュサーバはセキュリティ対策のため、組織単位でアクセスを制限するのが必須になっているのに対して、DNSコンテンツサーバは必ず全世界に公開しなければなりませんので、個別のサーバで運用することが求められます。
DNSコンテンツサーバの構成
今回は、VirtualBox上のCentOS6.5仮想マシンにインストールしましたので、IPアドレスがプライベートIPになっていますが、実際にはグローバルIPアドレスになりますので、ご自分の環境にあわせて読替えてください。
また、DNSコンテンツサーバのアドレスは、レジストラに登録してもらう必要があります。以前は申請書を提出したりと大変でしたが、最近ではレジストラが提供するWEBコンパネから、手軽にDNSコンテンツサーバのアドレスを登録できるところが増えているようです。
・プライマリ
ホスト名：ns1.apar.jp
IPアドレス：172.16.1.8
・セカンダリ
ホスト名：ns2.apar.jp
IPアドレス：172.16.1.9
本番ではプライマリとセカンダリのDNSコンテンツサーバは、まったく別のネットワークに配置することが必要です。 レジストラによってはセカンダリDNSを無料で提供していますので、そちらを利用するのも手かもしれません。
BINDのインストールと設定
インストール
DNSサーバソフトウェアのBINDをインストールします。サービス識別子は named になります。
yum -y install bind yum -y install bind-chroot
設定
・BIND関連ファイルの場所
/etc/named.conf ・・・コンフィグファイル
/var/named/master/ ・・・ゾーンデータファイル
/var/named/chroot/var/log/named.log ・・・ログファイル
/etc/rndc.key ・・・rndn鍵
設定の前に、念のためオリジナルのコンフィグをキープしておきます。
mv /etc/named.conf /etc/named.conf.org
rndn鍵の作成とオーナー変更
rndc-confgen -a -r /dev/urandom chown named:named /etc/rndc.key
named.conf の作成
vi /etc/named.conf
options {
// 相対パスで指定したファイルはこのデイレクトリがベースになる
directory "/var/named";
// named の pidファイル
pid-file "/var/run/named/named.pid";
// どこからの問合せでも受け付ける
allow-query { any; };
// 再起検索要求を受け付けない
recursion no;
// ゾーン転送を明示的に禁止、許可の設定は個々のzoneステートメントにて行う
allow-transfer { none; };
// BINDバージョンの隠匿
version "unknown";
// キャッシュ内容を保存するファイル(rndcで利用)
dump-file "data/cache_dump.db";
// 名前解決の回数などを統計データとして保存するファイル(rndcで利用)
statistics-file "data/named_stats.txt";
// サーバ終了時にメモリ使用統計について出力するファイル(rndcで利用)
memstatistics-file "data/named_mem_stats.txt";
};
// rndc の共有鍵ファイル
include "/etc/rndc.key";
// rndc の制御を受け付けるアドレス・ポートとそれに対応する共有鍵を定義
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { rndc-key; };
};
// ログの設定
logging {
// ログの出力先
channel default-log {
file "/var/log/named.log" versions 60 size 20m;
print-time yes;
print-severity yes;
print-category yes;
};
// 出力するカテゴリーの設定
category queries { default-log; };
category default { default-log; };
category config { default-log; };
category security { default-log; };
category xfer-in { default-log; };
category xfer-out { default-log; };
category notify { default-log; };
category update { null; };
};
// localhostゾーンの定義
include "/etc/named.rfc1912.zones";
// 管理するゾーンの設定
zone "apar.jp" {
type master;
file "master/apar.jp";
allow-transfer{ 172.16.1.9; };
};
ログの出力先へのリンク作成
ln -s /var/named/chroot/var/log /var/log/named
ゾーンファイルの保存場所作成
mkdir /var/named/master chmod 750 /var/named/master/ chown root:named /var/named/master/
ゾーンファイルの作成
vi /var/named/master/apar.jp
$TTL 3600
@ IN SOA ns1.apar.jp. ns1.apar.jp. (
2014100801 ; Serial
3600 ; Refresh
900 ; Retry
2419200 ; Expire
600 ; Negative cache TTL
)
IN NS ns1.apar.jp.
IN NS ns2.apar.jp.
ns1 IN A 172.16.1.8
ns2 IN A 172.16.1.9
www IN A 172.16.1.10
ゾーンファイルのパーミッション設定
chown root:named /var/named/master/* chmod 640 /var/named/master/*
IPv6の無効設定
vi /etc/sysconfig/named 下記を最終行に追加します。
OPTIONS="-4"
作成したコンフィグにエラーがないか確認
named-checkconf /etc/named.conf
何も表示されなければOKです。
最後に named を起動します。
service named start
正常に問合せできることを確認します。
dig @172.16.1.8 www.apar.jp
;; ANSWER SECTION: www.apar.jp. 3600 IN A 172.16.1.10
上の例ではゾーンファイル14行目のAレコードが、正しく問合せできています。
BINDの設定確認
DNSサーバの設定ミスは、セキュリティ攻撃を受ける脆弱性につながります。必ず確認しましょう。
namedのバージョン非表示確認
dig @172.16.1.8 chaos txt version.bind
version.bind. 0 CH TXT "unknown"
バージョンが「unknown」と表示されていればOKです。
再起検索要求を拒否するか確認
dig @172.16.1.8 www.yahoo.co.jp
;; QUESTION SECTION: ;www.yahoo.co.jp. IN A
IPアドレスを返さなければOK
セカンダリ以外にゾーン転送しないことを確認
dig @172.16.1.8 apar.jp axfr
; <<>> DiG 9.8.3-P1 <<>> @172.16.1.8 apar.jp axfr ; (1 server found) ;; global options: +cmd ; Transfer failed.
転送失敗（4行目）となっていればOKです。
最近ではレジストラ等のDNSサーバサービスが充実しているので、DNSコンテンツサーバを構築する機会も少なくなってきていると思いますが、WEBインフラのしくみを理解するのにはDNSの理解は必須です。多少のリスクはありますが、もし機会があったらDNSコンテンツサーバを構築してみるのもよいかと思います。
コメント