BINDスレーブは、再起動するまでマスターと同期しません
BIND9を実行する2つのDNSサーバーがあり、1つはマスター、もう1つはスレーブです。マスターでゾーンファイルが更新されたときに、スレーブサーバーが変更されたレコードのサービスをすぐに開始するようにしたいのですが、BINDによって多少の問題が生じます。
DNSゾーン転送は、マスターとスレーブ間で既に正しく機能しています。スレーブサーバーにログインしてDig @dnsmaster myzone. AXFRを実行すると、ゾーンのコンテンツ全体が出力されます。これを機能させるために、DNSマスターはnotify yesおよびalso-notify { dnsslave }で構成されています。同様に、スレーブはallow-transfer { dnsmaster }で構成されています。
Dnsmasterが更新されたら、rndc reloadを実行すると、通知が送信されていることがわかります。これは、/var/named/slavedata/のゾーンファイルを検査することにより、スレーブで確認されます。それらには、マスターが知っているものと一致する最新のデータが含まれています。
今、奇妙な部分が来ます。
スレーブサーバーは、古い古いDNSレコードを引き続き提供し、マスターから通知された後、新しいデータがディスク上で利用可能であるという事実を完全に無視します。次のコマンドで結果を確認するためにDigを使用しています：Dig @slaveserver record.zone.tld。
BINDが権限のあるゾーンのメモリ内キャッシュを保持しているのではないかと思ったので、max-cache-sizeとmax-cache-ttlを0に設定しましたが、効果がありませんでした。
スレーブサーバーでrndc flushやrndc reloadなどのコマンドを実行して、この疑わしいキャッシュをフラッシュする別の方法を試しましたが、それでも古い古いレコードが返されます。
最後に、ゾーンのMINTTLが86400（24時間）に設定されていることに気付いたので、MINTTLを一時的に15秒に変更し、スレーブサーバーを再起動しました。影響なし-スレーブは、サービスが再起動された後にのみ、更新されたDNS結果を提供します。
何が起きてる？ゾーンが更新されたという通知を受け取ったときのBIND9の予想される動作は何ですか？常にTTLとMINTTLを尊重していますか？私は常に利用可能な最新のデータを使用すると思います。
私の機知の終わりに、古くなったデータの提供を避けるために、BINDスレーブを1時間ごとに再起動するようにcrontabを設定することを検討しています。もっと良いものはありますか？
あなたの説明から、私はあなたに正確には何を伝えることができませんis問題ですが、いくつかのことを除外するのを助けることができます。
キャッシュサイズの設定とキャッシュttlの設定は、キャッシュされた再帰クエリデータ用であり、（既にお気付きのように）信頼できるデータには適用されません。同様に、rndcフラッシュはここでは適用できません。
推奨されるトラブルシューティング方法：
- 通知メッセージが期待どおりにマスターによって送信されていることを確認します。ログを確認するか、マスターとスレーブ間のトラフィックを確認します。
- ログから、通知メッセージがスレーブによって受信されていることを確認します。
- スレーブが通知を受信しているのが見えない場合は、通知の問題としてトラブルシューティングします。つまり、マスターのnamed.confで通知オプションを再確認し、それらが期待どおりに定義され、後でオーバーライドされず、適切にスコープ設定されていることを確認します。 「明示的に通知」を使用することをお勧めします。 「また、{slave-server;}に通知します;」
- スレーブisが通知を表示する場合、問題は、ゾーンファイルが期待どおりに更新されていない理由を理解していることです。何がすべきが発生するかは、通知が受信された後、スレーブはSOAクエリを実行し、現在のSOAと比較して、AXFR（または、有効にしてください）更新されたゾーンコピーを取得します（SOAがマスターの方が高いと仮定します）。スニファーでこれが起こっていることをすべて観察できるはずです。また、両方のサーバーのログにあります。
- 期待どおりに操作が行われない場合は、2つのサーバー（Dig @server $ zonename SOA）のSOAシリアル番号を手動で比較して、スレーブに誤ってスレーブを割り当てていないことを確認します。過去のある時点で予想よりも高いシリアル番号で、現在はマスターのシリアル番号よりも大きい。
それでも問題が解決しない場合は、マスターとスレーブの両方からのnamed.confセクションと、両方のサーバーからのログを含め、新たに編集されたゾーンをマスターにロードした後に何が発生しているかの詳細を投稿することを検討してください。
私も同じ状況に直面しました。研究の結果、次のことがわかりました。ビューを使用している場合、Dig @ localマシンはlocalhost-viewにあるもののみを提供します。 localhost-viewは、namedの再起動時にのみ更新されます。ただし、最新のゾーンファイル（マスターから転送されたもの）は引き続きスレーブで使用でき、外部ソースまたは外部ビューからのすべてのクエリに提供されます。そのため、localhost-viewが更新されるように調整する必要があります。
名前をリロードする前にマスターサーバーで変更を行う場合は、ゾーンファイルからシリアルIDをインクリメントすることを忘れないでください。そうしないと、ゾーンファイルがスレーブサーバーに複製されません。