単純な問題になってしまうと感じているのですが、明らかな問題は見られません。
これは、物事がどのように順番に発生するかをよりよく理解するための最初のフローの例です。これはすでに配置されているインフラストラクチャであり、操作の順序はそのままにしておく必要があることに注意してください。
今..ステップ1と2の間に、これが表示され始めます(明らかに、ドメインがまだシステムにないためです:
Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied
次に、ゾーンファイルを作成します/ var/lib/bind/example.com.hosts:
$ttl 38400
example.com. IN SOA ns1.ourdnsserver.com. some.email.com. (
1494611262
10800
3600
604800
38400 )
example.com. IN NS ns1.ourdnsserver.com.
example.com. IN A 40.xx.xx.xx
www.example.com. IN A 40.xx.xx.xx
mail.example.com. IN A 173.xx.xx.xx
webmail.example.com. IN A 173.xx.xx.xx
example.com. IN MX 10 mx1.server.com.
example.com. IN MX 20 mx2.server.com.
この後、ゾーンを構成に挿入します/ etc/bind/named.conf.local:
zone "example.com" {
type master;
file "/var/lib/bind/example.com.hosts";
};
次に、再起動を発行しますSudo service bind9 restart
この後、私はまだ
Jun 12 15:32:40 DNSSERVER named[25262]: client 230..xxx.xxx.xx#61333 (example.com): query (cache) 'example.com/SOA/IN' denied
これを解決するために私がしなければならないことは編集私のファイル/var/lib/bind/example.com.hosts
-新しいunixタイムスタンプでシリアルを更新します-バインドを再保存して再起動します。そしてビオラ、ゾーンが更新されたという通知が送信されます。
[〜#〜]編集[〜#〜]
次に、ログに次のように表示されます
8377:Jun 12 14:12:57 OURSND named[25262]: zone example.com/IN: sending notifies (serial 1494611231)
編集終了
ここに質問があります。ゾーンを作成してBindを再起動すると、通知機能が送信されないのはなぜですか。ゾーンが「更新済み」と表示されるようにするには、バインドに戻って編集、再保存、再起動する必要があるのはなぜですか?私はこれが初めて、毎回起こることを望んでいます。何が見えないのですか?
シリアルはバージョン番号と考えてください。バインドを(再)開始すると、データキャッシュのバージョン番号とconfig(シリアル)のバージョン番号がチェックされます。バージョンが同じである場合、なぜわざわざすべてを再処理するのか、そしてなぜ転送するゾーンがあることをセカンダリサーバーに伝えるためにネットワーク帯域幅を浪費するのか...
常にシリアルを更新してください。唯一のルールはそれが上がる必要があるということです。 UNIXタイムスタンプを使用するか、YYYYMMDDNNのような形式を使用することをお勧めします。NNはその日のリビジョン番号です(1日に99回以上変更する必要がありますか?)。
あなたが発見したように、問題はあなたがファイルを編集するときにシリアルを更新することを忘れないことです。いくつかのテンプレートファイル、データファイル、およびシェルスクリプトを使用して、データを編集する「ビルド」プロセスを作成し、ゾーンファイルを再生成するように指示します。その一部には、新しいシリアルの出力が含まれます。または、ISPConfigのような「サービスプロバイダー」コントロールパネルを備えた(やり過ぎの)Webベースのフロントエンドに移動します。ここでは、データがすべてsqlデータベースにあり、ispconfigソフトウェアがゾーンファイルを自動的に作成します。