CentOS 7 のサーバーを構築しているのだけど、djbdns に「落とし穴」があったので記して置く。
djbdns は DNS サーバー。
DNS サーバーのプログラムとしては BIND が有名なのだけど、前世紀からセキュリティホールが多すぎることが問題となっていた。
djb こと「ダニエル・ジュリアス・バーンスタイン」がそれに腹を立て（？）、セキュリティ問題が出ない DNS として作ったのが djbdns だ。
BIND はその後、一度全面的に作り直されて「BIND 9」となった。
セキュリティ問題は多少は改善したらしいのだけど、根本的にはやはり変わっておらず、セキュリティアップデートを繰り返している。
つい先日も、非常に重大な脆弱性が見つかっている。
djbdns は、2001 年に公開されてから、セキュリティパッチが当たったのは 2009 年の1度だけ。
実のところ、BIND に限らず、DNS サーバーはセキュリティアップデートが多いソフトの一つだろう。
というのも、DNS の仕組みそのものがあまり良い設計ではなかったから。
インターネットに悪人はいない、という思想で設計されてしまった。
実際、悪人がいなければうまく動くし、現在のインターネットは DNS なしには考えられない。
でも時々、ソフトではなく、DNS の規格自体にセキュリティ問題が見つかる。
こうなると、BIND に限らず、DNS サーバープログラムが軒並みアップデートしたりする。
でも、この場合も djbdns だけは大丈夫、ということが多い。
最初から規格を信じていないし、自分が作ったプログラムすら信用しない、という姿勢で作られているため、そもそも問題が出にくいし、問題が出た場合でも影響が非常に少なく、セキュリティホールになりにくい。
…と、ここまで書くといいことづくめのようだ。
でも、そんなにいいものなら皆が使うだろう。
実際には、多くのサーバー管理者が敬遠して使わないような、ひどい部分のあるソフトなのだ。
セキュリティが強固な代償として、プログラムをインストールし、設定するのが非常に厄介だ。
たとえば、どんなサーバープログラムでも、そのサーバーの「設定」を行うファイルを持つものなのだけど、ファイルの読み込みって実はセキュリティホールになりやすい。
そこで、設定ファイルを読み込むプログラムと、実際に動作するプログラムが分離している。
そして、このプログラム自体が、問題の出やすい「設定ファイルの文法解釈」を行わないようになっている。
具体的にいうと、ファイル名がそのまま設定項目で、ファイル内は1行だけ、というのが基本。
設定のためのディレクトリの中に、多数のファイルが入れられた状態となる。
管理する立場になると、設定項目を一覧することもままならない状態。
プログラムをサーバーとして動作させるときは、万が一停止した場合に備えた仕組みが必要になるのだけど、その仕組みも別のプログラムになっている。
DNS の「問い合わせ」に応対するプログラムと、「解決」を行うプログラムも別になっている。
そして、万が一脆弱性により「乗っ取り」が起こった場合でも問題が起きないように、これらのプログラムの権限は分離している。
UNIX では権限はユーザーに付随するものなので、サーバーを動かすためだけに、複数のユーザーを登録する必要がある。
BIND より信頼のおけるものだとしても、この複雑至極なインストール方法と設定方法が嫌われていて、あまり使われないソフトの一つだ。
＃あと、勘違いも多い。
最後のアップデートが 2009年、と聞くと、開発が停止していてセキュリティホールだらけなんじゃないか、と思う人が多いようだ。
上に書いたように、セキュリティチェックは頻繁に行われていて、アップデートがないのは何も問題がないから。
開発はもちろん継続していて、報告があればいつでもアップデートされる。
さて、そんな高性能だけどインストールと設定が厄介な djbdns が、コマンド一発でインストールされ、使えるとしたらどうだろう？
CentOS 7 には、djbdns の改良版である n-djbdns (New djbdns）が提供されている。
yum install ndjbdns でインストールできる。
改良版と書いたけど、改良かどうかはわからない。
動作権限はあまり細かく分かれていないので、万が一問題が生じた際の保証はない。
もっとも、「万が一のために」動作権限が分離されているのだけど、過去にそういう万が一が報告された例はないから、これはこれでいいかもしれない。
設定ファイルも、ごく普通のものになったので設定しやすい。
先に書いたように、ファイルの読み込みはセキュリティホールになりやすいのだけど、どうも n-djbdns では、設定ファイルを読み込むプログラムだけを改良して、その部分を使いやすくしたようだ。
これは設定ファイルの読み込みだけなので、サーバーのセキュリティ問題は出にくそうだ。
とはいえ、「文法解釈」という、複雑で問題が出やすいものを導入してしまったのは事実で、djbdns よりはセキュリティの強度が落ちるかもしれない。
先に書いた、サーバーとして動作させるための仕組みは、djb が専用に作ったものではなく、CentOS7 が使用する systemd に任せる形になった。
systemd 自体が複雑すぎて、セキュリティホールの温床になりそうだ、という批判はあるのだけど、それはまた別問題。
まぁ、複雑怪奇で使われにくい djbdns を、使いやすいようにうまくまとめてある印象。
しかし、最初に書いたように、一つ落とし穴があった。
axfrdns の設定方法がわからない。
DNS サーバーは、普通２台を一組にして設定する。
DNS は非常に重要なものなので、万が一片方が停止しても、もう片方で運用を続けられるようにだ。
このとき、メインにデータを設定すると、もう１台に自動的にデータが転送される。
でも、データを転送したいのであれば、ファイル転送の仕組みを使えばよい。
UNIX には scp という、非常に優れたファイル転送コマンドがあるから、それを使えば解決だ。
…と、djbdns では考えている。
BIND では、このために専用の仕組みを用意していて、「ゾーン転送」と呼ばれる動作が行われる。
djbdns と BIND を混ぜて使うような特殊な状況だと、ゾーン転送にも対応しないといけない。
このための仕組みが、axfrdns だ。なくても良い存在だ。
でも、僕はまさに bind との連携をしないとならない、という事情があった。
その axfrdns が使えない。
よくわからないよ？ と思ってネットで情報を探したのだけど、そもそも djbdns で axfrdns を使っている人も少ない状態。
ましてや、まだそれほど普及していない n-djbdns では設定例が全く見つからない。
そして見つけたのが 2013 年の、n-djbdns 開発の掲示板ログ。
ここで、やはり axfrdns の設定ができない、という質問に対し、n-djbdns の作者（djbdns からの改良者）が、axfrdns を自身が使っていないため、機能を理解していないと認めている。
ただ、認めて終わりではなくて、要望を受けて改良しているんだ。
設定がちゃんとできるようになり、起動も可能となった、ようだ。
でも、この時点では CentOS 6 の時代なのね。
まだ systemd はなくて、別の方法で起動を行う設定ファイルが紹介されている。
さらに、axfrdns の設定で「本当に」必要なことが、この方法では満たせない、という報告がある。
起動できなかったのが起動は出来るようになった。でも、それでは役立たないのだ。
こちらについては「将来のバージョンで対応するかもしれない」という形で終わっている。
CentOS 7 の起動スクリプトは、この掲示板で示された CentOS 6 用のものを systemd に移植するような形になっていた。
ただ、CentOS 7 特有の問題により、何か違う問題が起きているようだ。
というのも、起動を試みても失敗するから。
なにか専用の設定を行えば起動できるのかもしれないけど、起動したとしても、先に書いたように「動くけど役立たたない」可能性が高い。
先に書いたように、axfrdns は、djbdns にとって必須の機能ではない。むしろ使わないほうが良いくらいだ。
セキュリティホールの多い BIND ではなく、djbdns を気軽に使いたい、という人にとっては、CentOS 7 で yum 一発でインストールできるのは良いことだと思う。
axfrdns 相当の機能が必要な場合は、残念だけど BIND を使うか、素の djbdns を自分でインストールすることになるようだ。
僕は以前のサーバーで、素の djbdns を使っていたので、後者を選ぼうと思う。
同じテーマの日記(最近の一覧)
関連ページ
CentOS7 の nginx で https / http2 対応【日記 16/10/22】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |