はじめに

DNSコンテンツサーバーが唯一ドメイン内のすべてのIPアドレスとFQDNの紐づけ一覧表を保持している。
しかし障害があった場合、名前解決ができずネット通信できなくなってしまうための冗長化として、
予備のコンテンツサーバー（Slave）にzoneファイルをバックアップさせる必要があります。
しかしslave SVはIPアドレスでのみマスターを識別しているため、マスターSVのIPを偽装した
「なりすましサーバ」が出現した場合はまったくの無防備になります。

そこで、TSIG（Transaction Signature）技術が使われる。
TSIGはサーバとクライアントで共通の秘密鍵を保有しデータと共通鍵に対しハッシュ関数を適用し、
ハッシュ値(HMAC)を導出しなりすまし防止する。

【TSIG仕組み】

出典：【セキュリティ】メッセージ認証コード・デジタル署名の仕組みについて解説します

①送信側SV：共通鍵生成
②受信側SV：共通鍵を送信側SVからダウンロード
③送信側SV：送りたいデータ(zoneファイル)と共通鍵に対しハッシュ関数を使い、
ハッシュ値(HMAC)を導出
④送信SV：データ(zoneファイル)とHMACを受信SVに送信
⑤受信SV側；送信されてきたデータ(zoneファイル)とHMACを分離
⑥データ(zoneファイル)に対し、②でダウンロードした共通鍵を使いハッシュ値(HMAC)を導出
⑦⑤で分離したHMACと⑥のHMACを照合し、同値ならデーターは改竄されていないと確認

TSIG利用したDNSサーバー(Master-Slave)構築

2台のSVを起動し、まずDNSマスターSVの方で作業する。
Bindの設定ファイル関係はすべて、/etc/named 配下。
作業ディレクトリの場所は丸暗記するのではなく、設定ファイルに必ず記載がある。
今回のbindの場合の設定ファイルには次のように記載があることから、
/var/namedが作業ディレクトリだとわかる。

vim /etc/named.conf

 10 
 11 options
 12 {
 13         // Put files that named is allowed to write in the data/ directory:
 14         directory               "/var/named";           // "Working" directory
 15         dump-file               "data/cache_dump.db";
 21

/var/namedに移動し、dnssec-keygenコマンドで鍵を作る（HMAC-SHA512アルゴリズム）。
鍵の名前は任意で設定できるのでtsig-key.
鍵生成の結果、２つのファイルが生成されるので、catで中身確認します。

[root@ns named]# cd /var/named
[root@ns named]# pwd
/var/named

[root@ns named]# dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST tsig-key
Ktsig-key.+165+26131

[root@ns named]# ls -l Ktsig-key*
-rw-------. 1 root root 117 11月 20 02:46 Ktsig-key.+165+26131.key
-rw-------. 1 root root 232 11月 20 02:46 Ktsig-key.+165+26131.private

[root@ns named]# cat Ktsig-key.+165+26131.key 
tsig-key. IN KEY 512 3 165
9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==

[root@ns named]# cat Ktsig-key.+165+26131.private 
Private-key-format: v1.3
Algorithm: 165 (HMAC_SHA512)
Key: 9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==
Bits: AAA=
Created: 20221119174638
Publish: 20221119174638
Activate: 20221119174638

どちらのファイル.key＆ .privateも共通秘密鍵である。
一見9S5から始めるKeyの部分は同じに見えるが、結論から言うと
.privateファイルに記載されている共有秘密鍵を使う。
.privateファイルのkeyフィールドの値（==まで）をメモ帳にコピペしておく

共通秘密鍵

9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==

rndcの設定

rndcは、namedデーモンに関する制御・状況確認を行う。
鍵の設定ファイルを作成するために以下のコマンドを実行する

[root@ns named]# which rndc-confgen 
/usr/sbin/rndc-confgen
[root@ns named]# /usr/sbin/rndc-confgen > /etc/rndc.conf

生成された鍵の設定ファイル/etc/rndc.confを編集

/etc/rndc.conf

  1 # Start of rndc.conf
  2 key "tsig-key" {     ←自分でdnssec-keygenコマンドで命名した鍵の名前に変更
  3         algorithm hmac-sha512;  ←dnssec-keygenコマンドで指定したアルゴリズムに変更
  4         secret "9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==";  ← .privateファイルの鍵を埋め込む
  5 };
  6 
  7 options {
  8         default-key "tsig-key"; ←自分でdnssec-keygenコマンドで命名した鍵の名前に変更
  9         default-server 127.0.0.1;
 10         default-port 953;
 11 };  
 25

上記の様に、デフォルトの状態から自分でdnssec-keygen作成した鍵の名前・アルゴリズム名
・.privateファイルに生成された鍵を/etc/rndc.confに埋め込んでいく。

/etc/named.confの編集

MasterサーバからSlaveサーバに鍵を送るために以下の内容を設定ファイルに記述する

まず設定ファイル内のoptionsステートメント内で次の変更を行う

・鍵の名前
・SlaveサーバのIPアドレス
・Slaveサーバに更新の通知

/etc/named.conf

11 options
12 {
51         allow-transfer          { key tsig; 172.16.1.101; };  ←追記 鍵の名前とslaveサーバのIP
    52         notify                  yes; ←追記 Slaveサーバに更新の通知
91 };

次に、keyステートメント内で以下の変更

・鍵の名前
・アルゴリズム
・生成した鍵を埋め込む（Ktsig-key.+165+26131.privateファイル内に生成された鍵）

デフォルトではコメントアウトになっているので#を外し、上記3点を変更する

/etcnamed.conf

204 key tsig-key  ←変更
205 ###{
206 ###     algorithm hmac-sha512; ←変更
207 ###     secret "9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw=="; ←変更
208 ###};

さらに直下にcontrolsステートメントを作成し、以下4行を追加
controlsステートメントは、
namedサービス管理用のrndcコマンドを使用するのに必要な各種のセキュリティ要求を設定する。

209 controls
210 {
211         inet 127.0.0.1 port 953
212         allow { 127.0.0.1; } keys { tsig-key;}
213 
214 };

※953番ポートは、BIND が rndc コマンドによって起動やデータベースのリロードなどを制御するために使用される。

設定ファイルの編集終わり。
構文チェックします。

[root@ns named]# named-checkconf /etc/named.conf
[root@ns named]#

ここでmamedデーモン再起動したい気持ちがわかるが
まだしないので注意！！
Slaveサーバ側に対するゾーン転送の設定を先にする

Slaveサーバの設定

Bindのインストール

このSVがDNSサーバとして構築済みか確認

[root@cl1 ~]# rpm -qa | grep "^bind"
bind-libs-lite-9.11.36-3.el8_6.1.x86_64
bind-utils-9.11.36-3.el8_6.1.x86_64
bind-license-9.11.36-3.el8_6.1.noarch
bind-libs-9.11.36-3.el8_6.1.x86_64

bindインストールされてないので、ダウンロードしインストール

[root@cl1 ~]# dnf install bind -y  
完了しました!

[root@cl1 ~]# rpm -qa | grep "^bind"
bind-utils-9.11.36-5.el8_7.2.x86_64
bind-libs-lite-9.11.36-5.el8_7.2.x86_64
bind-license-9.11.36-5.el8_7.2.noarch
bind-9.11.36-5.el8_7.2.x86_64
bind-libs-9.11.36-5.el8_7.2.x86_64

ひな形ファイルのコピー

ここから先、DNSサーバー構築作業になる。
テンプレートの花形ファイルをコピーし、/etc/named* /var/namedディレクトリーに収める。
以前の投稿【Linux】セキュアなサーバ構築シリーズ② DNS サーバーを構築する
の設定ファイル編集/etc/named.confの欄を参考に作業する

ネットワークの設定

今扱ってるサーバをDNSサーバ(Slave)にするために、nutuiコマンドでNICのDNSサーバ欄に
自分自身のIPを記述する(IPv4&6両方)

設定変更したらNetworkManagerデーモンの再起動忘れずに。

[root@cl1 ~]# systemctl restart NetworkManager

設定ファイル内のnameserver情報は自身のIPに代わっているはずなので以下の様に確認

/etc/sysconfig/network-scripts/ifcfg-enp0s3

[root@cl1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-enp0s3 
IPADDR=172.16.1.101
DNS1=127.0.0.1

IPV6ADDR=2001::65/64
DNS2=::1

/etc/resolv.conf

[root@cl1 ~]# cat /etc/resolv.conf 
nameserver 127.0.0.1
nameserver ::1

named.confのコピー ※Masterサーバーで作業

DNS slaveサーバーができ、今から何をするのか一旦整理する。
Masterサーバで生成された共通鍵と設定ファイルをSlaveサーバにコピー（転送）する。

転送する前に設定変更が必要。

まず設定ファイルのパーミッション・所有者・グループを確認

[root@ns named]# ls -l /etc/named.conf
-rw-r-----. 1 root named 8599 10月  5 01:10 /etc/named.conf

所有者がrootのものを他のSVに送ってはいけないので、所有者・グループをyuzoに変更する。

[root@ns named]# chown yuzo:yuzo /etc/named.conf
[root@ns named]# ls -l /etc/named.conf
-rw-r-----. 1 yuzo yuzo 8599 10月  5 01:10 /etc/named.conf

rootユーザーからログアウトして設定ファイルの所有者のyuzoログインし、
一般ユーザとしてscpコマンドで安全にDNS Slaveサーバに転送する。

ホームディレクトリに移動する。

[root@ns named]# exit
ログアウト
[yuzo@ns ~]$ whoami
yuzo
[yuzo@ns ~]$ pwd
/home/yuzo

所有者がyuzoのnamed.confをslaveサーバーにコピー（転送）する。

[yuzo@ns ~]$ scp /etc/named.conf 172.16.1.101:/home/yuzo
The authenticity of host '172.16.1.101 (172.16.1.101)' can't be established.
ECDSA key fingerprint is SHA256:9rHonTI+TIToj0G9KTfRdbLSSnAn3Xh8sAt/JTMEa44.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.16.1.101' (ECDSA) to the list of known hosts.
yuzo@172.16.1.101's password: 
named.conf                                       100% 8599     6.7MB/s   00:00

転送できたので、すぐにrootに戻り、/var/namedに移動する

[yuzo@ns ~]$ su -
パスワード:
[root@ns ~]# cd /var/named

設定ファイルを転送前の以下の状態に戻す。
パーミッション：640
所有者:root
グループ:named

[root@ns named]# ls -l /etc/named.conf
-rw-r-----. 1 yuzo yuzo 8599 10月  5 01:10 /etc/named.conf
[root@ns named]# chown root:named /etc/named.conf
[root@ns named]# ls -l /etc/named.conf
-rw-r-----. 1 root named 8599 10月  5 01:10 /etc/named.conf

Slaveサーバ側で転送されてきたか確認

転送されてきたことを確認

[root@cl1 ~]# ls -l /home/yuzo/
合計 12
-rw-r-----. 1 yuzo yuzo 8599 11月 21 01:09 named.conf

送られてきた設定ファイルを自身の設定ファイルに上書きする。

[root@cl1 ~]# cp /home/yuzo/named.conf /etc/named.conf
[root@cl1 ~]# ls -l /etc/named.conf
-rw-r-----. 1 root named 8599 11月 21 01:20 /etc/named.conf

送られててきた設定ファイルはDNS Masterサーバで設定されたものなので
それを使えばゼロから設定する必要がなくなる。

Masterで生成した鍵をSlave側に埋め込む作業をする

rndcの設定ファイルの作成

slaveサーバ

[root@cl1 ~]# /usr/sbin/rndc-confgen > /etc/rndc.conf
[root@cl1 ~]# ls -l /etc/rndc.conf 
-rw-r--r--. 1 root root 479 11月 21 01:28 /etc/rndc.conf

先ほどMasterサーバ側で生成した鍵の名前・アルゴリズム・鍵をslave側でも共有して使うため、
/etc/rndc.confと/etc/named.confで同じ設定になるようにする。
メモしてない場合は、Masterサーバの/etc/rndc.confからそれらの情報を取得する（コマンド割愛）

rndc.confの編集 ※Slave側

/etc/rndc.conf

  1 # Start of rndc.conf
  2 key "tsig-key" {  ←鍵名変更
  3         algorithm hmac-sha512; ←アルゴリズム名変更
  4         secret "9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==";
  5 }; ← 鍵変更
  6 
  7 options {
  8         default-key "tsig-key";  ←鍵名変更
  9         default-server 127.0.0.1;
 10         default-port 953;
 11 };
 24 # End of named.conf

### named.confの編集 ※Slave側

view "localhost_resolver"ステートメント内
```:/etc/named.conf
129         include "/etc/named.rfc1912.zones";
130 ####    include "/etc/named.common.zones";  ←コメントアウト
131         include "/etc/named.tsig.zones";    ←追記

view "internal"ステートメント内

/etc/named.conf

147         include "/etc/named.rfc1912.zones";
148 ####    include "/etc/named.common.zones";  ←コメントアウト
149         include "/etc/named.tsig.zones";    ←追記

"key"ステートメント内

203 key tsig-key
204 {
205         algorithm hmac-sha512;
206         secret "9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==";
207 };
208 
209 controls
210 {
211         inet 127.0.0.1 port 953
212         allow { 127.0.0.1; } keys { tsig-key; };
213 };

この直下に次の4行追加
Masterサーバのアドレスと鍵の名前を記述

214 server 172.16.1.202
215 {
216         keys { tsig-key; };
217 };
218

上のoptionsステートメントに戻り、以下の2行コメントアウト

 51 ###     allow-transfer          { key tsig-key; 172.16.1.101; };
 52 ###     notify                  yes;

named.tsig.zonesの作成 ※Masterの指定

typeがslaveになることに注意。
自身でzoneファイルを保持するのではなく、Masterサーバーに転送依頼頼むため
Masterの情報記述。

※逆引きは手間だったので考慮しない

  1 zone "d000.mgt.local" IN {
  2 type slave;
  3 masters { 172.16.1.202; };
  4 };

構文チェック

[root@cl1 named]# named-checkconf /etc/named.conf

【注意】
この時点でまだデーモンのスタートかけない！！
（⇒理由：Master側の設定を先に読み込ませないと、serialナンバーの順序が
めちゃくちゃになりslaveが同期してくれないと推測）

動作確認をするので、別ターミナルでログの確認準備しておく。

[root@cl1 ~]# 
[root@cl1 ~]# tail -f /var/log/messages

Slaveからzoneファイルを見に行く周期の設定

Masterサーバー側でzoneファイルのリフレッシュ機関を3時間から2分に短くする

d000.mgt.local.db


$TTL 86400
$ORIGIN d000.mgt.local.
d000.mgt.local. IN SOA ns.d000.mgt.local. root.d000.mgt.local. (
                2022112207      ; serial
                        2M      ; refresh   ※← 3Hから2Mに変更
                        15M     ; retry
                        1W      ; expiry
                        1D      ; minimum
)
d000.mgt.local.         IN      NS       ns.d000.mgt.local.
d000.mgt.local.         IN      MX 10    sv.d000.mgt.local.
d000.mgt.local.         IN      MX 20    sv2.d000.mgt.local.
ns.d000.mgt.local.      IN      A        172.16.1.202
ns.d000.mgt.local.      IN      AAAA     2001::ca
sv.d000.mgt.local.      IN      A        172.16.1.201
sv.d000.mgt.local.      IN      AAAA     2001::c9
sv2.d000.mgt.local.     IN      A       172.16.1.201
cl1.d000.mgt.local.     IN      A       172.16.1.101
cl1.d000.mgt.local.     IN      AAAA     2001::65
cl2.d000.mgt.local.     IN      A        172.16.1.102
cl2.d000.mgt.local.     IN      AAAA     2001::66
www.d000.mgt.local.     IN      A        172.16.1.201
d000.mgt.local.         IN      A        172.16.1.201
ns2.d000.mgt.local.     IN      CNAME   ns.d000.mgt.local.
client1.d000.mgt.local  IN      CNAME   cl.d000.mgt.local

デーモン再起動

systemctl restart named

wiresharkで動作確認の準備
フィルター：ip.addr==172.16.1.202 and dns

以上で、Master-salveの設定完了

zoneファイル転送の確認

※Slave側

元のターミナルでnamedデーモン再起動

[root@cl1 ~]# systemctl start named
[root@cl1 ~]# systemctl status named

slave側のデーモン起動すると、このタイミングで
Masterが大切に保有しているzoneファイルがslaveサーバーに転送されてくる。

ログでもTSIG 'tsig-key'という文字列が目視で確認できる(※slave側)

tail -f /var/log/messages

Nov 23 16:44:03 cl1 systemd[1]: Started Berkeley Internet Name Domain (DNS).
Nov 23 16:44:03 cl1 named[3374]: zone d000.mgt.local/IN/localhost_resolver: Transfer started.
Nov 23 16:44:03 cl1 named[3374]: transfer of 'd000.mgt.local/IN/localhost_resolver' from 172.16.1.202#53: connected using 172.16.1.101#53055 TSIG tsig-key
Nov 23 16:44:03 cl1 named[3374]: zone d000.mgt.local/IN/localhost_resolver: transferred serial 2022112207: TSIG 'tsig-key'
Nov 23 16:44:03 cl1 named[3374]: transfer of 'd000.mgt.local/IN/localhost_resolver' from 172.16.1.202#53: Transfer status: success
Nov 23 16:44:03 cl1 named[3374]: transfer of 'd000.mgt.local/IN/localhost_resolver' from 172.16.1.202#53: Transfer completed: 1 messages, 18 records, 572 bytes, 0.001 secs (572000 bytes/sec)
Nov 23 16:44:04 cl1 named[3374]: zone d000.mgt.local/IN/internal: Transfer started.
Nov 23 16:44:04 cl1 named[3374]: transfer of 'd000.mgt.local/IN/internal' from 172.16.1.202#53: connected using 172.16.1.101#35729 TSIG tsig-key
Nov 23 16:44:04 cl1 named[3374]: zone d000.mgt.local/IN/internal: transferred serial 2022112207: TSIG 'tsig-key'
Nov 23 16:44:04 cl1 named[3374]: transfer of 'd000.mgt.local/IN/internal' from 172.16.1.202#53: Transfer status: success

Masterサーバの方ではwireshark起動中なのでそちらで確認

上図
1行目：slaveからmasterへTSIGを使いzoneファイル（SOA）のリクエスト
2行目：masterがslaveにresponseとしてzoneファイルを送っている

２行目の返信でL2.L3.L4.と詳細確認できるので、Domain Name Syststemを展開。
TSIGに関する情報はadditional recordsの中に登録されている

更新Zoneファイル転送の同期の確認

Masterでzoneファイルを編集し、slaveが受け取る。
最終行にslaveサーバーの別名を付ける。

/var/named/d000.mgt.local.db

  1 $TTL 86400
  2 $ORIGIN d000.mgt.local.
  3 d000.mgt.local. IN SOA ns.d000.mgt.local. root.d000.mgt.local. (
  4                 2022112208      ; serial     ←※serial numberｗを一つ増やす
  5                         2M      ; refresh
  6                         15M     ; retry
  7                         1W      ; expiry
  8                         1D      ; minimum
  9 )
 10 d000.mgt.local.         IN      NS       ns.d000.mgt.local.
 11 d000.mgt.local.         IN      MX 10    sv.d000.mgt.local.
 12 d000.mgt.local.         IN      MX 20    sv2.d000.mgt.local.
 13 ns.d000.mgt.local.      IN      A        172.16.1.202
 14 ns.d000.mgt.local.      IN      AAAA     2001::ca
 15 sv.d000.mgt.local.      IN      A        172.16.1.201
 16 sv.d000.mgt.local.      IN      AAAA     2001::c9
 17 sv2.d000.mgt.local.     IN      A       172.16.1.201
 18 cl1.d000.mgt.local.     IN      A       172.16.1.101
 19 cl1.d000.mgt.local.     IN      AAAA     2001::65
 20 cl2.d000.mgt.local.     IN      A        172.16.1.102
 21 cl2.d000.mgt.local.     IN      AAAA     2001::66
 22 www.d000.mgt.local.     IN      A        172.16.1.201
 23 d000.mgt.local.         IN      A        172.16.1.201
 24 ns2.d000.mgt.local.     IN      CNAME   ns.d000.mgt.local.
 25 clientnumber1.d000.mgt.local  IN      CNAME   cl.d000.mgt.local   ←※changeName 別名を追加

Master側のzoneファイルを変更すると、slave側でzone情報を同期する。
しかし、25行目を追加しただけではSlaveは同期してくれない。
slaveが同期するには、4行目のserianナンバーが一個でも大きいことが条件になる。
よってzoneファイルを変更したら必ずserialナンバーを一つ大きくすることを忘れないようにする。

5行目のrefreshは,masterが保持するzone情報をslaveがチェックする頻度。
現行だと2分に設定。

zoneファイル編集したのでデーモン再起動

[root@ns named]# systemctl restart named

zoneファイル内で定義した通り（2M; refresh）、2分間隔でSlaveはMasterにzone情報を
チェックしに来る。

2分経てばslave側に勝手に同期されるが、無理やりnamedデーモン再起動しMaster側のserialナンバーがslave側で反映されるか確認。

[root@cl1 ~]# systemctl restart named
[root@cl1 ~]# grep "2022112208" /var/log/messages
Nov 23 19:02:48 cl1 named[3374]: zone d000.mgt.local/IN/internal: transferred serial 2022112208: TSIG 'tsig-key'
Nov 23 19:06:01 cl1 named[3374]: zone d000.mgt.local/IN/localhost_resolver: transferred serial 2022112208: TSIG 'tsig-key'
Nov 23 19:08:06 cl1 named[4764]: zone d000.mgt.local/IN/localhost_resolver: transferred serial 2022112208: TSIG 'tsig-key'
Nov 23 19:08:07 cl1 named[4764]: zone d000.mgt.local/IN/internal: transferred serial 2022112208: TSIG 'tsig-key'

digで無理やりSlaveからMasterへzone転送要求を行える ※Masterで作成されたzoneファイルが転送されてくる

動作確認にはこちらのほうがわかりやすい。

digコマンドに鍵が必要になるのでコピーしておく。

key:9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==

[root@cl1 ~]# dig @172.16.1.202 axfr d000.mgt.local -y \
> hmac-sha512:tsig-key:9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> @172.16.1.202 axfr d000.mgt.local -y hmac-sha512:tsig-key:9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==
; (1 server found)
;; global options: +cmd
d000.mgt.local.		86400	IN	SOA	ns.d000.mgt.local. root.d000.mgt.local. 2022112208 120 900 604800 86400
d000.mgt.local.		86400	IN	A	172.16.1.201
d000.mgt.local.		86400	IN	NS	ns.d000.mgt.local.
d000.mgt.local.		86400	IN	MX	10 sv.d000.mgt.local.
d000.mgt.local.		86400	IN	MX	20 sv2.d000.mgt.local.
cl1.d000.mgt.local.	86400	IN	A	172.16.1.101
cl1.d000.mgt.local.	86400	IN	AAAA	2001::65
cl2.d000.mgt.local.	86400	IN	A	172.16.1.102
cl2.d000.mgt.local.	86400	IN	AAAA	2001::66
clientnumber1.d000.mgt.local.d000.mgt.local. 86400 IN CNAME cl.d000.mgt.local.d000.mgt.local.
ns.d000.mgt.local.	86400	IN	A	172.16.1.202
ns.d000.mgt.local.	86400	IN	AAAA	2001::ca
ns2.d000.mgt.local.	86400	IN	CNAME	ns.d000.mgt.local.
sv.d000.mgt.local.	86400	IN	A	172.16.1.201
sv.d000.mgt.local.	86400	IN	AAAA	2001::c9
sv2.d000.mgt.local.	86400	IN	A	172.16.1.201
www.d000.mgt.local.	86400	IN	A	172.16.1.201
d000.mgt.local.		86400	IN	SOA	ns.d000.mgt.local. root.d000.mgt.local. 2022112208 120 900 604800 86400
tsig-key.		0	ANY	TSIG	hmac-sha512. 1669198867 300 64 5FBdO4bhsBlqWAWQB5gBf10Ib/TE5vMAK/IkUeF36UAaophn4u3ycDgE AcrVbnSvl5y8hjAZWuGjUg1SoggBbQ== 7156 NOERROR 0 
;; Query time: 0 msec
;; SERVER: 172.16.1.202#53(172.16.1.202)
;; WHEN: 水 11月 23 19:21:07 JST 2022
;; XFR size: 18 records (messages 1, bytes 617)

zoneファイルが送られてきたことを確認。

zoneファイルのバックアップのスケジューリング

上述した通り、digを利用してSlaveからMasterに対してzone転送要求を行えるのを確認した。
Masterから転送されてきたZone DBで保存できるようにslave側でcronスケジューリングする。

転送されてきたzoneファイルを、/root/tsig.logに保存されるようスケジューリングする。

[root@cl1 ~]# crontab -e
[root@cl1 ~]# crontab -l
10 20 23 11 3 dig @172.16.1.202 axfr d000.mgt.local -y  hmac-sha512:tsig-key:9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw== >> /root/tsig.log

crontabファイルで指定した20時10分になったので、/root/tsig.log確認

/root/tsig.log


[root@cl1 ~]# ls -l /root/tsig.log 
-rw-r--r--. 1 root root 1528 11月 23 20:10 /root/tsig.log
[root@cl1 ~]# cat /root/tsig.log 

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> @172.16.1.202 axfr d000.mgt.local -y hmac-sha512:tsig-key:9S5tW221eaSp1UzDpC+8GvtOnsscXYIkrpE8ogdC95RPzVVoF29E68iVZIQd2VoXNlCM1lToiuOaPpZksdHHAw==
; (1 server found)
;; global options: +cmd
d000.mgt.local.		86400	IN	SOA	ns.d000.mgt.local. root.d000.mgt.local. 2022112208 120 900 604800 86400
d000.mgt.local.		86400	IN	A	172.16.1.201
d000.mgt.local.		86400	IN	NS	ns.d000.mgt.local.
d000.mgt.local.		86400	IN	MX	10 sv.d000.mgt.local.
d000.mgt.local.		86400	IN	MX	20 sv2.d000.mgt.local.
cl1.d000.mgt.local.	86400	IN	A	172.16.1.101
cl1.d000.mgt.local.	86400	IN	AAAA	2001::65
cl2.d000.mgt.local.	86400	IN	A	172.16.1.102
cl2.d000.mgt.local.	86400	IN	AAAA	2001::66
clientnumber1.d000.mgt.local.d000.mgt.local. 86400 IN CNAME cl.d000.mgt.local.d000.mgt.local.
ns.d000.mgt.local.	86400	IN	A	172.16.1.202
ns.d000.mgt.local.	86400	IN	AAAA	2001::ca
ns2.d000.mgt.local.	86400	IN	CNAME	ns.d000.mgt.local.
sv.d000.mgt.local.	86400	IN	A	172.16.1.201
sv.d000.mgt.local.	86400	IN	AAAA	2001::c9
sv2.d000.mgt.local.	86400	IN	A	172.16.1.201
www.d000.mgt.local.	86400	IN	A	172.16.1.201
d000.mgt.local.		86400	IN	SOA	ns.d000.mgt.local. root.d000.mgt.local. 2022112208 120 900 604800 86400
tsig-key.		0	ANY	TSIG	hmac-sha512. 1669201801 300 64 okZKROCeOItS/99wm8K9Q5j1QgDuzNYOr0FH9/qjnvvy7yoJZGoXWMbR xT3YQlzd9hbRtrgJ0mr8XcQtT6n3ag== 63668 NOERROR 0 
;; Query time: 1 msec
;; SERVER: 172.16.1.202#53(172.16.1.202)
;; WHEN: 水 11月 23 20:10:01 JST 2022
;; XFR size: 18 records (messages 1, bytes 617)

named.serviceに自動起動

Masterの方はすでにシステム起動と同時にnamedを起動設定済み。
Slaveの方でも同じ設定をする。

[root@cl1 ~]# systemctl is-enabled named
disabled
[root@cl1 ~]# systemctl enable named
Created symlink /etc/systemd/system/multi-user.target.wants/named.service → /usr/lib/systemd/system/named.service.
[root@cl1 ~]# systemctl is-enabled named
enabled

以上、TSIGの設定終わり。

誤字なのでエラー続きでとても長く感じたが、やったこと自体は非常にシンプル
①Master側で共通鍵生成
②鍵をslave側に埋め込む