「BIND 10」では、named.confが無くなる？

ISCの「BIND 10」開発プロジェクトページ

　DNSソフトウェアで80％以上のシェアを占めると言われる「BIND」。現行バージョン「BIND 9」もアップデートが進められ、機能拡張などが行われているが、2000年9月のリリースから今年で早くも10年めを迎える。

　昨今はDNSサーバーを対象としたDDoS攻撃への耐性など、DNSに対する要求事項が増しているほか、DNSSECやIP Anycastといった新技術を円滑に運用できる仕組みが求められている。開発元である米Internet Systems Consortium（ISC）は、こうした背景のもと、次期バージョン「BIND 10」の開発プロジェクト開始を4月に発表した。

　この開発プロジェクトには、.JPドメイン名のDNSの全体運用を行う日本レジストリサービス（JPRS）も賛同を表明。資金を提供するほか、エンジニアも派遣し、開発に積極的に参画するスタンスを示している。今後、ccTLDのレジストリとして蓄積したノウハウを提供するとともに、「BIND 10」に求められる仕様などについても、DNS運用者の視点から提案していく方針だ。

　次期DNSソフト「BIND 10」の目指す方向性と、JPRSがその開発に参画する意義を同社担当者に聞いた。

●「BIND 9」のソフトウェア寿命はあと5年

　「BIND 10」開発プロジェクトは、ISCのプログラムマネージャーのもと、10名あまりのメンバーで構成される。多くはISCからの参画だが、JPRSから技術戦略室の藤原和典氏とシステム運用部の神戸直樹氏の2名がソフトウェアエンジニアとして参画する。ソフトウェアエンジニアとしては、中国ネットワークインフォメーションセンター（CNNIC）からも2名が参画予定だという。藤原氏と神戸氏はすでに6月下旬、ISCで開かれたミーティングに出席。「BIND 10」の設計に関する議論やユーザーニーズについての情報共有を行ってきた。

JPRSシステム運用部の神戸直樹氏

　「BIND 10」開発を決めた背景には、「BIND 9」が拡張に次ぐ拡張で現在に至っているため、フルスクラッチに近いかたちで、もう一度最初からソフトウェアをきれいに作り直す目的があったという。

　「BIND 9が設計されたのは1999年と古く、ソースコード中のコメントやドキュメントが少ないために、ソースコードの再利用が困難になっています。ISC内の開発スタッフしかメンテナンスや機能拡張を行えないということで、大きな問題になっています。」（神戸氏）

　「ISCでは、ソフトウェアの“寿命”というものを10年から15年と考えています。BIND 9が設計された1999年から、もう10年経ってしまったということで、そろそろ新しいバージョンを開発しようとしているのです。」（藤原氏）

　具体的なスケジュールとしては、最初の1年間は権威DNSサーバー機能の開発に集中し、2010年に最初のα版をリリースする予定。その時点で、「BIND 9」の4分の1程度の性能を出すことを目標としている。当初はあまり性能を追及せずに、まずはソースコードをきれいに書き換え、その後、性能を追及。将来的には「BIND 9」の1.5～2.0倍程度の性能を出していく計画だ。

　まだ具体的なマイルストーンは示されていないが、このα版をリリースした後、1年ごとに何らかのアップデートを行っていくのが目標だ。JPRS技術戦略室室長代理の佐藤新太氏によると、「BIND 10が実際に完成するのには5年ぐらいかかる」という。その後、「BIND 9」から置き換わっていくのにさらに5年ぐらいかかるとみている。

　なお、開発を進めるにあたっては、ISCがWikiベースのWebサイトを用意し、開発者向けの情報を公開。また、メーリングリストや、チャットが行えるJabberのサーバーも用意している。JPRSでは、こうしたツールを用いてISCとコミュニケーションをとりながら議論を進めていくとともに、定期的にISCに出向いてミーティングすることも考えている。

●機能をモジュール化、データベースとの連携容易に

　さて、ISCが「BIND 10」の開発を表明した4月22日付の発表文では、その方向性として、「Flexible（柔軟性）」「Scalability（拡張性）」「Integration and Maintenance（統合とメンテナンス性）」「Secure（安全性）」「Resilient（回復性・耐久性）」といったキーワードを掲げている。

JPRS技術戦略室の藤原和典氏

　まず「Flexible（柔軟性）」では、各機能をモジュール化して提供することで、DNS運用者が必要に応じて機能をプラグインで利用できるようにすることを目指す。

　「DNSサーバーだけでなく、DHCPサーバーも同じ基盤の上に載せてモジュール化することを考えています。DHCPだけということではなく、他の機能にも広がっていくと思いますが、まずはDHCP機能をモジュール化してBIND 10の枠組みの中で提供します。また、権威DNSサーバーとキャッシュDNSサーバーを完全に分離し、機能のオン・オフを簡単に切り替えられるようにする構想もあります。」（神戸氏）

　「実は現行のBIND 9でも、DHCPサーバーを結合させ、Dynamic Update機能を使用することで、新しいマシンを接続した際にホスト名とIPアドレスがDNSに登録される設定も可能です。BIND 10では、それぞれのモジュールは疎結合でありながら、もっとうまく結合しやすくすることを考えています。」（藤原氏）

　ISCの発表文ではまた、SQLによる対話可能なデータベースとの統合についても言及している点に注目される。ゾーン設定などについて、こうしたデータベースとのインターフェイスを導入することが考えられているという。

　実はこの点についても、「BIND 9.6」においてすでに機能としては入っており、「本当に使いたい人は、理解すれば使える」（藤原氏）。しかし、それが一般のDNS運用者にとって使えるかどうかは別であり、導入の障壁になっている可能性もある。

　大規模事業者であれば、現在でも、データベースから定期的にデータを引き出し、ゾーンファイルなどを自動生成して対応しているという。しかし「BIND 10」では、そうした大規模事業者でなくとも、データベースと連動してDNSを管理することを容易に行えるようにしようというわけだ。

●ケーブルモデムからccTLDまでカバーする拡張性

　「Flexible（柔軟性）」と関連して言及されている「Scalability（拡張性）」については、ISCの発表文によると、例えば家庭用のケーブルモデムのような小規模なシステムから、ccTLDのような大規模システムまで対応することを想定している。

　具体的には、前述のようなSQLによって連携することにより、バックエンドのデータベースを広く使えるようにするといったことのほか、巨大なゾーンを扱う際のチューニングが施され、ゾーンの読み込みや転送がより高速にできるようになり、将来的に「BIND 9」よりも高速性を確保する計画だ。

　「ゾーン設定の読み込みに時間がかかると、その間の応答性能が下がってしまうとの指摘はJPRS社内でも挙がりました。ホスティングサービスのように小さいゾーンが多くある場合、読み込みに時間がかかり、応答性能が下がってしまいます。これは更新頻度が上がれば上がるほどシビアな問題です。JPRSでは、BINDにそういう問題があるのをあらかじめ把握した上でシステムを組んでいるため、回避できていますが、6月のISCとのミーティングではそこを改善してほしいと要望してきました。」（神戸氏）

●設定ファイルの更新手法が激変か

　「Integration and Maintenance（統合とメンテナンス性）」は、前述のSQLによるデータベース連携とあわせて、設定ファイルの管理手法を大きく改善するものだ。

JPRS技術戦略室室長代理の佐藤新太氏

JPRS技術戦略室室長の三田村健史氏

　「BIND 9では、named.confというテキストファイルで設定を行っており、あるシステムをバックエンドにつないで使う場合、必ずテキストファイルを出力しなければなりませんでした。もっと機械的なフォーマットがある言語の方がデータのコンフィギュレーションをしやすいため、BIND 10ではそういう仕組みを提供するということです。」（藤原氏）

　そこで検討しているのが、NETCONFというプロトコルだ。ISCでは、このプロトコルを用いて、XMLでコンフィギュレーションを記述し、それをネットワーク越しに書き込むような手法を意識しているという。

　「コンフィギュレーションに関して言えば、BIND 9が開発されたころの運用システムと現在の運用システムが大きく違ってきているという背景があります。かつては1台のサーバーでさまざまな機能を運用していたものが、現在では何十台ものサーバーを運用する時代になり、オペレータとしてそれだけのサーバーをどう管理するのか、あるいは稼働させながらどうやって設定を更新していくのかが課題になります。BIND 10開発プロジェクトのサイトには『クラスタリゼーション』というキーワードで表現していますが、運用スタイルが大きく変わっていることを前提に、NETCONFのような仕組みで設定を更新していくという考えです。」（佐藤氏）

　これは、IP Anycastなどで複数台のサーバーを運用している場合などでも、1つ1つログインして設定を更新するのに代わるインターフェイスが提供できるようになることを意味している。バックエンドのデータベース側で新しいゾーンを追加した際の設定変更が、システムとして反映しやすくなるという。

「設定ファイルを直接編集しないで、制御プロトコルで動的に設定を更新できる機能はぜひ実現してほしいものです。現在は、ゾーンのバージョンをチェックするには、SOAレコードのシリアル番号を見ればよいですが、本当に正しくゾーンファイルが更新されているかどうかは中身まで見ないとわかりません。プライマリとセカンダリで中身が一致しているかどうか簡単に確認できる仕組みも必要でしょう。」（神戸氏）

　「ゾーンが増えた際に、named.confを書き換えるという手法では、もはや運用が難しい状況です。現状では複数のファイルをエディットする必要がありますが、それを1行間違えただけでDNSが停止してしまう可能性もあるのです。それを動的に変更できるオペレーションの仕組みが動くようになれば、安定運用の面でも効果があります。」（藤原氏)

　「DNSに明るくない人でも、データベースの運用ができれば、データベース側のインターフェイスを通じてDNSの設定・管理ができるようになります。それだけエンジニアのすそ野も広がるのです。」（JPRS技術戦略室室長の三田村健史氏）

　以上、前編ではISCが「BIND 10」開発の方向性として示したキーワードのうち、「Flexible（柔軟性）」「Scalability（拡張性）」「Integration and Maintenance（統合とメンテナンス性）」について見てきた。次回の後編では引き続き、「Secure（安全性）」「Resilient（回復性・耐久性）」というキーワードを見ていくとともに、JPRSが「BIND 10」開発プロジェクトに参画する意義などを聞いていく。