ここでは、bindでDNSサーバを運用する際に、気を付けなければいけない点や動作確認の方法などミスなく安全に運用するためのノウハウを紹介します。ご利用の環境によって、使えるノウハウになるか不明ですが、こちらで構築したDNSサーバをベースに紹介いたします。
セカンダリサーバのnamed.conf
セカンダリサーバのnamed.confは以下の通り設定します。
acl "naibu" {
! 192.168.0.25;
192.168.200.0/24;
localhost;
127.0.0.1;
};
options {
listen-on port 53 { 192.168.0.25; 192.168.200.12; 127.0.0.1; };
// listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
allow-query { any; };
allow-transfer { none; };
allow-query-cache { none; };
allow-update { none; };
version "unknown";
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion no;
dnssec-enable no;
dnssec-validation no;
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
include "/etc/crypto-policies/back-ends/bind.config";
notify no;
masterfile-format text;
};
logging {
category lame-servers { null; };
channel "default-log" {
file "/var/log/default.log" versions 5 size 10M;
severity debug;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query-log" {
file "/var/log/query.log" versions 5 size 10M;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
category default {"default-log";};
category queries {"query-log";};
};
view "internal" {
match-clients { naibu; };
allow-query { naibu; };
allow-recursion { naibu; };
allow-query-cache { naibu; };
recursion yes;
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "hogehoge.local" IN {
type slave;
file "slaves/hogehoge.local";
masters { 192.168.200.11; };
};
};
view "external" {
match-clients { any; };
recursion no;
zone "hogehoge.jp" {
type slave;
file "slaves/hogehoge.jp";
masters { 192.168.0.23; };
};
};設定が終わったら、サービスを再起動して設定を反映させます。
セカンダリサーバの動作確認はゾーンファイルのコピーが存在するか
セカンダリサーバが問題なく設定できているのかは、ゾーンファイルがプライマリサーバからコピーされていることを確認すればよいです。
具体的には、セカンダリサーバにあるゾーンファイルを一旦削除して、bindのサービスを再起動すると、プライマリサーバよりコピーされ、ファイルが存在することが確認できればOKです。初回はゾーンファイルは無いと思いますので、サービス再起動後に生成されていればOKです。
IPv4のみ対応するオプションの設定
# vi /etc/sysconfig/namedのファイルに、
OPTIONS="-4"を追記します。
bindのログファイルのリンク作成
実体は、 /var/named/chroot/var/log/ にありますが、/var/log/named にシンボリックリンクを作成し、他のログと同じ場所にあるように設定しておきます。
# ln -s /var/named/chroot/var/log/ /var/log/namedrndcコマンドによるゾーンファイルの修正反映
今回作成した環境は、viewでinternalとexternalを分けているので、それぞれを指定する必要があります。
# rndc reload example.jp in external「in external」がないと、internalとどっちのゾーンファイルを更新するのか不明なためエラーがでますので、ご注意ください。
その他トラブルシューティング
rndc コマンドでサービスの再読み込みをしたのち、名前解決が出来ない！
namedからSERVFAILが帰ってきまして、ログを見たら以下のログが出ていました。
（この時は、zoneファイルのパスを変更した後）
22-Nov-2022 18:09:08.210 security: info: client @0x7ff0500a2600 192.168.0.23#47989 (dnstest.example.jp): view external: query ‘dnstest.example.jp/A/IN’ denied
22-Nov-2022 18:09:08.210 query-errors: info: client @0x7ff0500a2600 192.168.0.23#47989 (dnstest.example.jp): view external: query failed (REFUSED) for dnstest.example.jp/IN/A at ../../../bin/named/query.c:7311
ZONEファイルのジャーナルファイル(.jnl)があって、そいつと編集したZONEとの関係がおかしくなってしまったようなのです。
サービスの再起動、
# systecctl stop named-chroot
# systecctl start named-chroot
で問題が解消された。
パッチ適応時にも同じような現象が再現した。その時、よりセキュアにしようと、
named.confファイル内で、
allow-query { none; }
にしていたが、こちらを
allow-query { any; }
に戻すと問題が解消された。
上記再起動を実施しても解消せず、焦ったが、どうも allow-query { none; } ということ自体がイレギュラーな設定値になると思われる。
今回はここまでです。最後までお読みいただきありがとうございました。