ローカルのネームサーバー
細かいことは知りませんが、現在 IPv4で機能するネームサーバーを家の中に立てています。家屋内のプライベートアドレスを割り振る DHCPサーバーに、ローカルのネームサーバーのアドレスを渡して、IPv4 / IPv6 アドレス共に名前解決をしています。
日本国内では、IPv4/IPv6が混在しているらしい
ゆくゆくはネット環境が、IPv6の世界に完全移行して不要になるのだろうと思っています。趣味で北海道とか出歩くこともあって、旅先からリモートで家に置かれた公開サーバーを操作することも時々あるのですが、場所によっては IPv4 だったり IPv6だったりしています。
IPv4 なら家に置かれたホームゲートウェイで、入口のグローバルアドレスから家屋内に置かれたプライベートアドレスの公開サーバーにアドレス変換して接続しますが、IPv6 のアドレスは家屋内の機器にも一律に割り振られていて、外部に置かれた DDNS で名前から直接アドレスが引かれると、そのままダイレクトに機器に接続されるイメージなので家屋内にローカルのネームサーバーは不要のようです。
たぶん当面はローカルのネームサーバーが必要かと
いずれにしてもローカルで、IPv4 を併用している機器が家屋内に現存している限り、ローカルのネームサーバーが必要なのだろうと思っています。
公開Webサーバーをローカルネームサーバー仕立てます
そこで、ハード的には余裕のあるオーバースペックのラズパイで、このブログが利用している公開サーバーをローカルのネームサーバーの１つとして機能追加しようと考えたのですが、過去の立上げから長い年月が過ぎているので作業内容も曖昧です。次があるのかは分かりませんが、トラブった時の参考資料としても有効かと思いまとめることにしました。
ネームサーバーのBIND9 をインストール
次のファイルリストが、ネームサーバーの BIND9 をインストールした時の初期状態のファイル群です。以前にカスタマイズした時は、 db.root のファイルがあったようですが、同様のファイルが別の場所に移されたようです。 → /usr/share/dns/root.hints
root@web-server:~# ls -l /etc/bind
合計 48
-rw-r--r-- 1 root root 2761 6月 21 2019 bind.keys
-rw-r--r-- 1 root root 237 6月 21 2019 db.0
-rw-r--r-- 1 root root 271 6月 21 2019 db.127
-rw-r--r-- 1 root root 237 6月 21 2019 db.255
-rw-r--r-- 1 root root 353 6月 21 2019 db.empty
-rw-r--r-- 1 root root 270 6月 21 2019 db.local
-rw-r--r-- 1 root bind 463 6月 21 2019 named.conf
-rw-r--r-- 1 root bind 498 6月 21 2019 named.conf.default-zones
-rw-r--r-- 1 root bind 165 6月 21 2019 named.conf.local
-rw-r--r-- 1 root bind 846 6月 21 2019 named.conf.options
-rw-r----- 1 bind bind 77 1月 1 12:10 rndc.key
-rw-r--r-- 1 root root 1317 6月 21 2019 zones.rfc1918
db.root の移行は、named.conf.default-zones の中の頭の部分に記載されています。
複数サーバーを立て、マスターとスレーブに仕立てます
このラズパイサーバーをマスターにして、他に稼働するネームサーバーをスレーブとしてデータを受取りながら稼働するサーバーに仕立てる予定です。
bind.keys …そのまま
db.0 …そのまま
db.127 …そのまま
db.255 …そのまま
db.empty …そのまま
db.local …そのまま
named.conf …そのまま
named.conf.default-zones …そのまま
named.conf.local …変更する (自分で定義したいゾーンをここで指定する)
named.conf.options …変更する (全体的な動作を定義するらしい)
rndc.key …そのまま
zones.rfc1918 …そのまま
ゾーンの定義はファイルを追加、ファィルとの対応を記述
自分で定義するゾーンファイルを作成して、このディレクトリに追加すると共に、このファイルが配布の元になるマスターか、配布されたコピーのスレーブなのか、更にはどこから配布を受取るのかや、どこに配布するのかも含めて、 named.conf.local ファイルに記述します。
サーバーの全体的な振舞を定義
また、ローカルのネットワークの流れや解決できない情報を上位のサーバーに渡す先についてのサーバー全体の動作に関する情報などは、 named.conf.options ファイルに記述するようです。
named.conf.options には、次のブルーの部分の追加と修正を行いました。どこからの情報かは不明ですが、いままで同様の設定で稼働しているので、深く考えずにそのまま移行します。
// LAN内のIPアドレスグループをLOCALと定義
acl "LOCAL" {
192.168.11.0/24;
240d:1a:34d:7f00::/64;
localhost;
localnets;
};
// ネームサーバー共通設定
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders { 8.8.8.8; 8.8.4.4;};
allow-query { LOCAL; };
allow-query-cache { LOCAL; };
allow-transfer { none; };
masterfile-format text;
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
192.168.11.0/24 が、IPv4 のローカルネットアドレスで、 240d:1a:〜::/64 が IPv6 のローカルネットアドレスです。
管理するゾーンの名前とアドレスの対応表を作ります
そして、自分で定義したゾーンファイルは、後で識別しやすいように 〜.zone をファイルの最後に付加しておくことにします。
sunao-mita.pgw.jp.zone …名前からアドレスに変換する定義
11.168.192.rev.zone …IPv4のアドレスから名前に変換する逆引きファイル
240d:1a:34d:7f00::.rev.zone …IPv6のアドレスから名前に変換する逆引きファイル
MyMemories.localdomain.zone …試験的に変換させるオマケのファイル
管理するゾーン定義の関連付け
初期の named.conf.local ファイルは、次のようになっているので対応するゾーンの定義と対応するファイル、マスターとして転送する場合は送り先のアドレス、スレーブとして受取るならマスターになるサーバーのアドレス等を記述します。
//
// Do any local configuration here
//
// この部分にゾーン情報を追加します
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918"; // コメントから有効に変更
定義の関連付け例
単純に単独で機能させるだけのサーバーなら、正引き逆引きの各ゾーン毎に定義して、次のような内容を追加します。この場合は、/etc/bind ディレクトリ下に sunao-mita.pgw.jp.zone と命名したファイルが置かれています。
シンプルな記述例、単独でファイル管理
zone "sunao-mita.pgw.jp" {
type master;
file "/etc/bind/sunao-mita.pgw.jp.zone";
};
マスターファイルを管理し、スレーブに転送
なお、複数のネームサーバーを稼働させていて、マスターのサーバーのデータを更新したら、スレーブ側のサーバーに自動転送させるには、各ゾーン毎に次のような記述を追加します。
zone "sunao-mita.pgw.jp" {
type master; // 転送先のスレーブサーバーを列記
allow-transfer { 192.168.11.23; 192.168.11.20; 192.168.11.21; };
notify yes;
also-notify { 192.168.11.23; 192.168.11.20; 192.168.11.21; };
file "/etc/bind/sunao-mita.pgw.jp.zone";
};
示したゾーンの定義は、マスターとして管理しスレーブ３台に配送する定義です。スレーブ側では、受取ったデータを自分で管理するマスターのデータと混乱しないように、slaves のディレクトリを作成してその中に受取るようにします。
スレーブで、マスターから受取るディレクトリを分ける
zone "sunao-mita.pgw.jp" {
type slave;
masters {
192.168.11.2; // マスターのデータを管理するサーバー
};
file "/etc/bind/slaves/sunao-mita.pgw.jp.zone";
};
マスターデータは、各ゾーン毎に定義するため、複数サーバーで、各ゾーン毎にマスターデータを管理するサーバーを決めて稼働することができます。
少し実行させてみて、スレーブ側のサーバーにマスターで更新した最新のシリアルナンバーのデータが配布されたようで、置かれているのを確認できたので、これで完了でしょう。
編集したマスターデータと配布されたコピー
スレーブにコピーされたデータは、マスター側の更新したデータを直接コピーしたものではなく、適度に編集されて配布されるようです。
参考までにマスター側の原本とスレーブ側のコピーの中身を表示しておきます。素人の記述内容に問題が多くて違いが大きいのかは分かりませんが…
;; sunao-mita.pgw.jp
$TTL 86400
@ IN SOA sunao-mita.pgw.jp. root.sunao-mita.pgw.jp. (
2020010202 ;Serial
3600 ;Refresh
900 ;Retry
604800 ;Expire
86400 ;Minimum TTL
)
IN NS dns.sunao-mita.pgw.jp.
IN NS dns2.sunao-mita.pgw.jp.
IN NS gate.sunao-mita.pgw.jp.
IN MX 10 mail.sunao-mita.pgw.jp.
IN A 192.168.11.2
IN AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
dns2 IN A 192.168.11.20
dns IN A 192.168.11.2
ubuntu-sv IN A 192.168.11.199
rpi1-disk IN A 192.168.11.23
rpi1-disk IN AAAA 240d:1a:34d:7f00:11cf:af0d:3b62:8501
ubuntu-dtp IN A 192.168.11.100
gate IN A 192.168.11.1
virt IN A 192.168.11.105
Radio IN A 192.168.11.20
DebianPogo IN A 192.168.11.22
DebianPogo IN AAAA 240d:1a:34d:7f00:225:31ff:fe00:9df0
mail IN A 192.168.11.2
mail IN AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
PogoV6 IN AAAA 240d:1a:34d:7f00:225:31ff:fe00:9df0
dns2 IN AAAA 240d:1a:34d:7f00:ba27:ebff:feac:28a8
dns IN AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
www IN A 192.168.11.2
www IN AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
RadioV6 IN AAAA 240d:1a:34d:7f00:ba27:ebff:feac:28a8
rpi1-com2 IN A 192.168.11.21
rpi1-com2 IN AAAA 240d:1a:34d:7f00:ba27:ebff:fe0c:5ef3
note IN A 192.168.11.51
note IN AAAA 240d:1a:34d:7f00:3906:1714:acef:3e46
web-server IN A 192.168.11.2
web-server IN AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
collection IN CNAME virt
share IN CNAME rpi1-disk
なお、動きが把握できていませんが、記述ミスに気が付き修正してマスター側で bind9 を restart すると、内容が直ぐに反映しましたが、その後も配布されているにも関わらずスレーブ側のデータ内容は古いシリアルの物を受取っているままでした。
$ORIGIN .
$TTL 86400 ; 1 day
sunao-mita.pgw.jp IN SOA sunao-mita.pgw.jp. root.sunao-mita.pgw.jp. (
2020010202 ; serial
3600 ; refresh (1 hour)
900 ; retry (15 minutes)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS dns.sunao-mita.pgw.jp.
NS dns2.sunao-mita.pgw.jp.
NS gate.sunao-mita.pgw.jp.
A 192.168.11.2
MX 10 mail.sunao-mita.pgw.jp.
AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
$ORIGIN sunao-mita.pgw.jp.
collection CNAME virt
DebianPogo A 192.168.11.22
AAAA 240d:1a:34d:7f00:225:31ff:fe00:9df0
dns A 192.168.11.2
AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
dns2 A 192.168.11.20
AAAA 240d:1a:34d:7f00:ba27:ebff:feac:28a8
gate A 192.168.11.1
mail A 192.168.11.2
AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
note A 192.168.11.51
AAAA 240d:1a:34d:7f00:3906:1714:acef:3e46
PogoV6 AAAA 240d:1a:34d:7f00:225:31ff:fe00:9df0
Radio A 192.168.11.20
RadioV6 AAAA 240d:1a:34d:7f00:ba27:ebff:feac:28a8
rpi1-com2 A 192.168.11.21
AAAA 240d:1a:34d:7f00:ba27:ebff:fe0c:5ef3
rpi1-disk A 192.168.11.23
AAAA 240d:1a:34d:7f00:11cf:af0d:3b62:8501
share CNAME rpi1-disk
ubuntu-dtp A 192.168.11.100
ubuntu-sv A 192.168.11.199
virt A 192.168.11.105
web-server A 192.168.11.2
AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
www A 192.168.11.2
AAAA 240d:1a:34d:7f00:a284:cc24:64bd:daae
マスターの更新を直ちにスレーブに反映させるには
修正を直ちに反映させるためには、何かのアクションが必要のようです。ネットで調べてみると reload のキーワードが見付かりました。他にも強制的に配布するコマンドもあるようです。
# service bind9 reload
実行してみるとスレーブ側のデータも最新のシリアルに更新されたようです。 定義の中に、$TTL 86400 ; 1day の記述がありますが、更新されても１日は前の情報を保持する指定なのでしょうか。
