web-dev-qa-db-ja.com

BINDスレーブネームサーバーが実際にマスターと正しく同期していることを確認する（そして後で修正する）方法は？

this linkに従って、マスターとスレーブの2つのネームサーバーをセットアップしました。セットアップは、マスターサーバーに搭載されているサイトが期待どおりに提供されるという事実によって証明されて機能しています。

しかし最近、私はスレーブサーバーがマスターと正しく同期していないのではないかと疑い始めました。エラー検査中に、ランダムゾーンファイルをリロードしようとしました。

rndc reload domain.tld

（「domain.tld」はプレースホルダーです）

これによってのみ迎えられる：

zone refresh queued

上記は、テストされたドメインに関係なく返されるメッセージです。

スレーブサーバー全体でanyゾーンファイル（find/-name * .zone）を検索しようとしましたが、結果がありません（ただし、 BINDセットアップがどのように機能するかを完全には認識していないため、スレーブサーバーにマスターのようなゾーンファイルが含まれていると想定されているため、検索が冗長になる可能性があります。

次に、named.runログを確認しました。このログには、次のようなエントリが入力されています。

dumping master file: tmp-CWKpRfrNi0: open: permission denied

私には許可の問題のように見えますが、正直なところ完全にはわかりません。ところで、私はゾーンファイルを後に（-===-）シリアルをインクリメントしてリロードしようとしましたが、運がありませんでした。

  1. スレーブサーバーが意図したとおりに機能していることを確認する方法はありますか？
  2. 上記の情報で、エラーが実際に原因であり、サーバーに障害があると結論付けるのに十分であると仮定すると、どうすれば修正できますか？
linuxdomain-name-systembindnameserver
1
user2026991

CentOS 6のbind-9.8.2-0.37は、スレーブが再起動された後（ゾーンがすでにキャッシュされている場合でも、ゾーンごとに）を示しています。

08-Apr-2016 12:15:07.571 zone example.com/IN: loaded serial 2016040103

Named.confには、とりわけ::が含まれています。

logging {
  channel general_file      { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; };
  category general      { general_file; };
};

ゾーンファイルを検索する必要はありません。named.confで手動で定義して、場所を簡単に特定できるようにする必要があります。 chrootの設定が間違っている可能性があります。つまり、ファイルシステムのルートが/ var/namesed/chrootのような場所にあり、適切な権限が設定されていないと考えて、namedrunが実行されます。

1
kubanczyk