DigiLoog

自鯖のメール用サブドメインにgdnsdを使ってGSLB動作をさせているのだが、
gdnsdではDNSクエリを取れない為、
ロギング用として前段にnginxのUDPリバースプロキシを噛ます構成を取っている。

ちょっと前に「dnsdistならUDPリバプロ動作をさせつつDNSクエリを取れる」と聞いた為、
休みを使って少しだけテストしてみた。

………

まだ、機能評価レベルの事しか出来ていないのだが、
バックエンドに権威DNSを置いた状態で前段にdnsdistを噛ましてみた所、
dnsdist単体でDNSクエリログを取得ができた。
ただし、取得出来たのは問い合わせしたFQDNとレコードタイプのみだった。

Aレコードなどは取得出来ない為、使える所は限られるのだが、
管理外のDNSを聞きに来ているDNSクライアントの監査などには使う事が出来ると思う。
ちなみに、dnsdist単体でのログ取得は下記の様な設定で取得出来た。

※ うろ覚えなのと、セキュリティ度外視なのであしからず

この場合、次の様な簡単なログ取得となる。
このレベルのロギングで要件を満たせるなら、dnsdist単体でログ取得まで行うと構成がシンプルになる。

未検証の機能としては、dnstapによるログ出力にも対応しているので、
fstrmを使ってより詳細なログを取得出来る筈だが、まだ未検証なのでそのうちテストしたい所。
あと、dnsdist本来の使い方となるロードバランシングも細かい挙動を把握出来ていない (´・ω・｀)

まだまだUDPリバプロには頑張って貰う必要があるが、今年中にはdnsdistへの入れ替えしたいと思う。

“ns-lab BB”の一部サブドメインではGSLB目的でgdnsdを導入している。
暫くの間ver2.4.0を使っていたのだが、先日ver3.0.0がリリースされた。
しかし、一部の設定項目が変わったりして移行出来ずにいた。

だが、アップグレードしないで放置する事も出来ないので時間を確保した上で、
変更リファレンスとソースコードを読んでアップグレードを実施してみた。

• DigiWiki ＞ Linux/Source/gdnsd

………

細かい変更点が色々とあるが、一番重要なヘルスチェックモジュールの設定は流用出来た。
GSLBの機能に直接関わりは無いが大きかったのは下記の通り。

• ヘルスチェックのWeb確認が廃止
• オートスキャニングの廃止
• gdnsd操作コマンドのサポート
• ACMEv1-DNSのサポート

筆者は使っていないが、ACMEv1に対応したのは大きいと思う。
また、コマンドラインをベースにした動的制御が出来るようになった為、
別の監視システムと組み合わせてgdnsdを利用する場合も柔軟に制御が出来るようになった。

ただし、従来から欲しかったDNSクエリのロギングはver3.0.0でも実装されていなかった。
DNSクエリログを取得している環境自体が稀なのかもしれないが、
アクセス解析を行う上で重要な情報源になるので是非とも欲しい所。

自前で権威DNS・GSLBを運用する事自体が無くなってきているが、
オンプレで安くGSLBを実現するには立てざるを得ない事があるので需要はまだあると思う。
そんな場合、手軽に機能を実装出来るgdnsdは良いと思う。

先日、明確な原因は調査しきれていないのだが、ブログ(DigiLoog)が参照しているMySQLで、
Master/Slaveのレプリケーションが外れ、丸一日程ブログを見れなくなる事態が発生した。

復旧はwikiにメモしてある通り、マスター側のDBダンプをスレーブでインポートし、
再レプリケーションをする事で復旧した。
直帰でDBを弄った事と言えば、エラーログ・スローログ出力を有効化したのだが、
コレが原因なのかは左記の通り追い切れていない。

今回の障害で判ったのは、復旧手段を確立出来ている事の安心感と、
apacheが一度MySQLへの接続を握ったら、Slave側に向け直す為に再読込が必要になる事。
アプリケーションによっては、シームレスに切り替えが出来るかもしれないが、
単純な三階層構造を取っているDigiLoogでは自動切り替えが上手く動かなかった。

本気でやるなら、シングルマスタークラスタリングを組むか、
Active/StandbyでMySQL Routerを挟み込む必要がありそう。
直近で大きな構成変更をする余裕は無いが、今後の課題としてメモに残そうと思う。