家屋内のネームサーバー

ローカルのネームサーバー

細かいことは知りませんが、現在 IPv4で機能するネームサーバーを家の中に立てています。家屋内のプライベートアドレスを割り振る DHCPサーバーに、ローカルのネームサーバーのアドレスを渡して、IPv4 / IPv6 アドレス共に名前解決をしています。

日本国内では、IPv4/IPv6が混在しているらしい

ゆくゆくはネット環境が、IPv6の世界に完全移行して不要になるのだろうと思っています。趣味で北海道とか出歩くこともあって、旅先からリモートで家に置かれた公開サーバーを操作することも時々あるのですが、場所によっては IPv4 だったり IPv6だったりしています。

IPv4 なら家に置かれたホームゲートウェイで、入口のグローバルアドレスから家屋内に置かれたプライベートアドレスの公開サーバーにアドレス変換して接続しますが、IPv6 のアドレスは家屋内の機器にも一律に割り振られていて、外部に置かれた DDNS で名前から直接アドレスが引かれると、そのままダイレクトに機器に接続されるイメージなので家屋内にローカルのネームサーバーは不要のようです。

たぶん当面はローカルのネームサーバーが必要かと

いずれにしてもローカルで、IPv4 を併用している機器が家屋内に現存している限り、ローカルのネームサーバーが必要なのだろうと思っています。

公開Webサーバーをローカルネームサーバー仕立てます

そこで、ハード的には余裕のあるオーバースペックのラズパイで、このブログが利用している公開サーバーをローカルのネームサーバーの1つとして機能追加しようと考えたのですが、過去の立上げから長い年月が過ぎているので作業内容も曖昧です。次があるのかは分かりませんが、トラブった時の参考資料としても有効かと思いまとめることにしました。

ネームサーバーの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";
};

示したゾーンの定義は、マスターとして管理しスレーブ3台に配送する定義です。スレーブ側では、受取ったデータを自分で管理するマスターのデータと混乱しないように、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 の記述がありますが、更新されても1日は前の情報を保持する指定なのでしょうか。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)