 |
環境構成
- 権威マスター: BIND 9.10.4-P2とPowerDNS 4.0.0-1p
- 権威スレーブ: YADIFA 2.2.1
- 再帰検索DNS: Knot Resolver 1.1.0
YADIFAの設定
<main>mastersの指定部分でカンマ区切りで複数のIPアドレスを列挙することでマルチマスター設定になります。
queries-log-type 3
</main>
<zone>
domain yadtest.w4yh.jp
file slaves/yadtest.w4yh.jp.zone
type slave
masters 133.18.nn.nn,153.127.nn.nn
multimaster-retries 2
true-multimaster false
</zone>
書いた順番に優先となり、最初に書いたIPアドレスのサーバーが通常のマスターとして参照します。
動作検証
1つめのmaster(133.18.nn.nn, PowerDNS)を落としてみます。(以下、引用部分はyadifaのログを示します)
| server | E | slave: query error for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53: Connection refused今回はmultimaster-retries 2で設定しているので、最初の1回 + リトライ2回 = 3回エラーが続くと切り替わります。
| server | W | slave: 133.18.yadtest#53 master failed to answer for domain yadtest.w4yh.jp.: next master is 153.127.nn.nn#53
通常あまりないと思いますが、マスターを切り替えた結果ゾーンが更新されていた場合には、切り替えた２つ目のマスターサーバーからのゾーン転送が行われます。
| I | slave: loaded IXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, new serial is 2016081401
true-multimaster
次に、true-multimasterをtrueにします。 これは「マスターの切り替えが発生した場合には、現在のゾーン情報を破棄して切り替わり先の新しいマスターから取得しなおす」という動作を指定する設定です。前の恋人との思い出は全部捨てて新しい恋に生きます、みたいな感じ？
まず優先マスターからゾーン転送を受けておきます。
| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53, serial is 2016081401この後マスターを落とすのは同じくですが、切り替わり先に敢えて古いシリアルのゾーンを入れておきます。 その結果、
| W | slave: 133.18.nn.nn#53 master failed to answer for domain yadtest.w4yh.jp.: next true master is 153.127.nn.nn#53シリアル番号は下がりますが、切り替わり先のマスターからゾーンファイルを上書き受信できました。
| D | slave: deleting '/opt/yadifa/var/zones/slaves/yadtest.w4yh.jp.zone'
| D | slave: deleting '/opt/yadifa/var/zones/xfr//98/3e/yadtest.w4yh.jp..axfr'
| D | database: yadtest.w4yh.jp.: will enqueue operation DATABASE_SERVICE_QUERY_AXFR at 2016-MM-DD hh.mm.dd (10分後)
| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, serial is 2016080101
| I | database: yadtest.w4yh.jp.: zone successfully downloaded (AXFR)
ちょっと意外だったのは、最初のマスターがダウンしたと判定された時点でゾーンファイルの削除が行われ、約10分間ファイルの無い状態が発生したことです。
ロードはされているのでDNSクエリへの応答はあったのですが(ダンプは見ていないので詳細は要確認)、一時的にファイルを失うというのは監視の仕方によっては厄介かもしれません。
どこで使う？
設定のmastersに並べるだけで冗長化できるという便利な設定を確認できました。この使いどころはどういうケースなのでしょうか。
masterが異なるIPアドレスで冗長されている、ということでVirtual IP addressを持った冗長を組んでいるところでは不要です。
internalセグメントにActive DirectoryのDNSが何台かいて、DMZのyadifaがslaveとして受け取る、というような場合は使えそうです。
また、yadifaの開発元であるEURidはドメイン提供～メール＆ウェブ環境の提供の一括管理をしているので、ドメイン情報は業務システムのデータベースに入っていて、そこから負荷や可用性レベルを切り離した複数のマスターサーバーがhidden(ステルス)で稼動しているのかもしれません。
WHD.glocal 2014での発表資料
余談
今回の検証環境は日割りで初期費用無しで安く利用できる国内事業者さんを探して、Kagoya VPSを利用しました。個人で検証用にいい環境が他にもあれば情報いただきたいです。
せっかく一式の環境を作ったので、DNSおよびその監視についてもうちょっと検証を行う予定です。お題などありましたらツイッターコメントやTXTレコードでお知らせいただければ、余裕あればやってみます。
