何年も前の記事で、BINDとMyDNSの連携についてまとめたことがあった。その記事が未だに参照される事が多いので、今回は現在のDNS周りの考え方を整理しておく。結論から言うと、以前と考え方は大分変わり、BIND+MyDNSの構成は既にやめて、BIND単体での運用に切り替えている。MyDNSをコンポーネントから外した理由は幾つかあるのだが、最も大きな理由がオープンリゾルバの問題だ。数年前にオープンリゾルバの脆弱性を利用して悪質な攻撃の踏み台にされてしまう問題が起きた。それ以降リゾルバの利用に対し制限をかけて最低限の範囲でのみ使える設定に変更した。

BINDでオープンリゾルバの問題を回避するには、自ゾーンのみはどこからでも無制限に引けて、それ以外のゾーンは任意の接続元のみ引けるような設定にしたい。しかし、前段BINDで自ゾーンのみ後段MyDNSにforwardする構成の場合はそういう設定が出来ず、全てのゾーンに対するリゾルバを無制限に解放するしか手がない。これは当然オープンリゾルバとなってしまうので、この構成を取る事が出来ない。

では、逆に前段MyDNSで自ゾーン以外を後段BINDにrecursiveする構成はどうか考える。MyDNS側で細かい事はできないので、前段では全て解放した状態。後段のBINDで応答を返すかどうかを判定したいが、MyDNSを挟んでいるために接続元が全て同じところ(MyDNSサーバ)から来ているように見える。これでは結局全ての接続元に応答するしかないので、やはりオープンリゾルバの状態になってしまう。

そもそもMyDNSを使うメリットを思い返してみると、バックエンドにMySQLを使う事でデータの更新やバックアップをRDB的にできる事。あるいは、某パッチによってDNS Weighted Round Robinを利用できる事など。前者は所詮大したデータ量ではないし、後者はWRRを利用するなら必ずMyDNSに問い合わすことを強制されてしまう(WRRを考慮したDNSなど存在しないので)。

整理してみると思ったよりMyDNSにこだわる必要もないかなと判断してDNSはBINDに一本化しました。chefで管理する上でも、その方がシンプルで楽だったし。resolverとcacheを分けるなど、他の棲み分けも考えられるんだけど、それはまた別の機会にでも。