私の組織には、前任者によってセットアップされたDNSサーバーがいくつかあります。彼は、シリアル番号に標準形式を使用せず、代わりに2033年以降の奇妙な形式を使用しました。 YYYYMMDDXXは小さい番号になるためです。
これらは私たちのパブリックDNSサーバーであり、これを実行しても問題がないことを確認したいだけです。このような移行の経験はありますか?
私の組織には、前任者によってセットアップされたDNSサーバーがいくつかあります。彼は、シリアル番号に標準形式を使用せず、代わりに2033年以降の奇妙な形式を使用しました。 YYYYMMDDXXは小さい番号になるためです。
これらは私たちのパブリックDNSサーバーであり、これを実行しても問題がないことを確認したいだけです。このような移行の経験はありますか?
回答:
2033で始まる彼の数がYYYYMMDDXX標準よりも大きい場合は、値をリセットできます。
手順を説明する記事を次に示します。基本的に、シリアル番号は32ビット整数であり、より大きな値を使用するとラップするという事実を利用する必要があります。
私はこれを自分で行う必要はありませんでしたが、自分でこの間違いを犯した場合に備えて、Pro DNSとBINDの著者からのソリューション(HOWTO Fix SOA RRシリアル番号)をブックマークしました。
シリアル番号は好きなように設定できます。デフォルトでは、セカンダリサーバーは、数字が大きい場合を除き、ゾーン転送をプルしませんが、直接アクセスできる限り、転送とリロードを強制するようにコマンドを実行できます。シリアル番号を好きなものに設定してから、セカンダリサーバーに再転送コマンドを発行すると、シリアル番号が低くても新しい情報が取得されます。
前述のように、SOAリソースレコードのSERIALフィールドには、 いわゆる「標準形式」はありません。すべてのDNSサーバーソフトウェアでも使用されているわけではありません。(最近では、かなりの量の人がゾーン転送データベースの複製さえも使用していません。)ISCのBINDでは、ゾーン転送データベース複製中にレプリカが不足しているかどうかを確認するために使用される特定の値に固有の意味を持たない単なる数字ですまた、前述のとおり、「新しい」とは「32ビットを法とするより大きな数」を意味するという条件で、設定に適したスキームを選択できます。
あなたはすでにここで落とし穴に遭遇しました。どんなスキームを選んだとしても、あなたが理解しておらず、あなたの前に来た人のスキームを変更したいのと同じように、誰かがやって来て(情報を欠いて)それを理解しないか、変更したいです。これは、システム管理の選択肢を文書化しないことの落とし穴です。そのため、選択を文書化します。