昨年末にVine6.x(x86)鯖からCentOS7.9(x64)鯖に環境移行構築をした際、主立ったパッケージはCentOS7.9の物に置き換えました。
その際の一つがDNSサーバ「bind」（起動名named）だったのですが、セキュリティ向上の目的で、namedでは無く、named-chrootがお勧め・・・とあり、この手法を使いました。
＜参考サイト＞
https://mseeeen.msen.jp/bind-chroot-important-point/
https://qiita.com/You_name_is_YU/items/81b97179518236e1a5f2
通常Linuxサーバを公開目的で設置する場合は固定IP(V4)を1つ以上設定してDNS登録するのが一般的です。
当家の鯖もこの「固定IP1」で「55.66.77.88」（仮定）といったアドレスをプロバイダから借用し、長年にわたって運用してきたのですが、2021年4月より速度向上目的で、
JPNE(日本ネットワークイネイブラー株式会社)の提供する『「v6プラス」固定IPサービス」』
という仕組みに契約変更をしたところ、固定IPアドレスが変更となりました。
新しいアドレス（仮定）は「11.22.33.44」との連絡があり、その変更の為に
/etc/named.conf
/var/named/・・・
のファイル群を変更して開通日に変更起動したのですが、何故か、/var/named/default.log
に怪しげなエラーが出ていました。
－－－－－/var/named/default.log抜粋ここから
zone 0.0.127.in-addr.arpa/IN/localnets: loaded serial 2021041103
out-named.rev:4: ignoring out-of-zone data (22.33.44.in-addr.arpa)
out-named.rev:5: ignoring out-of-zone data (11.22.33.44.in-addr.arpa)
zone 88.77.66.55.in-addr.arpa/IN/globalnet: has 0 SOA records
zone 88.77.66.55.in-addr.arpa/IN/globalnet: has no NS records
zone 88.77.66.55.in-addr.arpa/IN/globalnet: not loaded due to errors.
zone 255.168.192.in-addr.arpa/IN/localnets: loaded serial 2021041103
－－－－－/var/named/default.log抜粋ここまで
88.77.66.55は旧固定アドレス「55.66.77.88」の逆表記で、設定ファイル群からは全て抹消したはずなのに、何故かゾンビのように蘇っていたのです。
昔からの神師匠に泣きついて、リサーチを進めたところ、コメント類（named.confでは「#」「;」で無く「//」が正解？）や日本語表記（SHIFT-JISは論外、UTF-8もダメ、EUC限定）による誤動作懸念などもアドバイス戴き、削れる物は全て削ったはずなのに、やはりダメ。
何故だか解らず、鯖のファイル群の文字列総ナメリサーチをしても「55.66.77は過去ログなど以外ではひっかからず、途方に暮れていたところ、「named-chroot」を使っているなら、その先「/var/named/chroot/」の確認はしたか？との決定的なアドバイスをいただき、調べてみたら見事にビンゴでした。
いままで鯖缶的には（ステレオタイプに）・・・
/etc/named.conf
/var/named/関連ゾーンファイル等
・・・があれば、named-chrootは勝手に上記のファイルを/var/named/chroot配下にコピーして動いてくれると思っていました。
実際、CentOS7.9に最初にnamed-chrootを仕掛けた時も、Vine6の/var/named/から持ってきた内容ほぼそのままでコピーして動いていたので、良しと考えていたのですが、調べてみたら・・・
「/var/named/chroot/etc/named.conf」ファイルが先祖返り（更新されておらず）
旧セカンダリDNS「hogehoge.2nddns.com」の記述や、
「view “globalnet” {」セクションに、
「zone “88.77.66.55.in-addr.arpa”{ //#→feelkind.comの固定IPの逆記述;」
の記述が見事に残ってました。←これが今回の騒動の原因。
つまりnamed-chroot君は初回起動時は/etc/named.confのコピーを自力で持ってくるけれども、二回目以降はこのプロセスをサボリ、IP変更など必要な場合は
/var/named/chroot/etc/named.conf
にも/etc/named.confの内容を手動でシンクロさせてやらなければならないと学習しました。
本件、忘れぬよう、/var/named/配下に・・・
「注意_named.conf___をいじったら、etc配下のnamed.conf、var_named_chroot_etc_named.confも上書きシンクロさせること」
・・・というコメントファイルを設置しておきました。
これらの修正結果、現在は・・・
#systemctl stop named-chroot
#systemctl start named-chroot
#systemctl status named-chroot
#cat /var/named/default.log
・・・等、全て正常な挙動になりました。
少し何かを変えると大きなハマり穴が待っている・・・Linux系の宿命でしょうか（Ｔ＿Ｔ）