はじめに
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が作業ディレクトリだとわかる。
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を編集
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サーバに更新の通知
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点を変更する
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に代わっているはずなので以下の様に確認
[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
[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の設定ファイルの作成
[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側
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"ステートメント内
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分に短くする
$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側)
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サーバーの別名を付ける。
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@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側に埋め込む