構築手順は何時も通りのwikiに纏めたのでそちらを参照。
ちなみに、今回は権威DNSサーバ(PowerDNS Authoritative Server)のみ構築してみた。
構成としてはこんな感じにしてみた。
ポイントとしては、ゾーン管理をPowerDNS+PDNS Managerに任せておき、
実際のユーザクエリに応答するフロントエンドは従来のBINDを利用してみた。
本来なら一番危険なのがフロントエンドなので、この箇所をNSD・Knot DNS辺りにしておくのがベスト。
ただし、今回はPowerDNSとGUIツールの使用感をテストしたかったので、
フロントエンドは手抜きして使い慣れたBINDにしてみた。
構成図はシンプル。ゾーン転送でBIND(slave)にデータを送る。
アプリケーションは違うだろうが、同様の構成は『Hidden Primary』として商用でもやる事が多い。
………
PowerDNSのGUIツールは色々な物をテストしてみたが、最終的にPDNS Managerに落ち着いた。
PDNS Managerは実装がシンプルなのと、PHP+JSで作られているので既存のWEBサーバと親和性が高く、
1台のサーバに色々詰め込んでいる自鯖用途に合致した。
当初、PowerDNS-Adminを使おうと思っていたのだが、
PIPの構築やらPython依存関係の解消など色々と面倒な中、
TCP:443でアクセスさせるには、リバースプロキシを噛ませる必要も出てきたので諦めた。
ただ、PowerDNS-Adminは機能が豊富で、ユーザ認証をAD連携(LDAP)する事も出来るらしいので、
エンタープライズで利用するなら、このツールが筆頭候補になると思う。
PDNS Managerの良い所は、余分な機能が無いので直感的にゾーン情報を弄れる。
その割に、ユーザ認証はローカルDBでちゃんと出来たり、
レコードタイプにALIAS等のニッチな物が揃っているので、十分な機能を持っている。
レコードで使うとしても、大多数は『A / AAAA / NS / MX / CNAME / TXT』辺りだと思うのと、
そこまで細かい制御やるなら、GUIよりもゾーン情報を直書きした方が意図した設定になると思う。
………
使ってみた感じだと、PDNS Managerは動作が軽く、ゾーン転送にも影響は無かった。
簡単にPowerDNSを使ってみたい場合には、良い選択肢になりそうだった。
そんな中でも気になったのは、レコードを編集する度にゾーン情報のシリアルが上がる為、
利用者が多い環境ではシリアルの『YYYYMMDD』と実際の日付が合わなくなりそうだった。
ただ、シリアル自体は数が相当数確保されているので、シリアルを気にしないなら問題無さそう。
そもそも、GUIを使う様な環境ではシリアル管理もGUI任せの方が良いので、希有な心配かもしれない。
…まぁ、シリアルを戻す事はDBを直接弄れば出来そうだったが (｀・ω・´)
“ns-lab BB”のインターネット向けDNSサーバは従来通りの構成を取っているが、
色々とテストして、本番利用が出来そうならばこちらの権威DNSも載せ替えようと思う。
« 続きを隠す
