クラウド系DNSサービス「Google Cloud DNS」の損得勘定：管理者のためのクラウドサービス入門（1/2 ページ）

連載目次

　インターネットに公開しているWebサーバーやメールサーバーに割り当てられているホスト名（FQDN）は、インターネット向けの「コンテンツDNSサーバー（権威DNSサーバー）」によって名前解決が行われる。つまりインターネット上に何らかのサービスを提供しているなら、コンテンツDNSサーバーの管理も付いて回ってくる。その管理・運用担当者を対象に、クラウドベースのDNSサービスの一つ「Google Cloud DNS」＊1を例に挙げて、従来と比べたメリット／デメリットを明らかにしたい。

従来のDNSサーバー／サービスの問題点

　コンテンツDNSサーバーでは通常、複数のDNSサーバーを別々の拠点に配置する。その理由の一つは耐障害性を確保するためで、ある拠点のDNSサーバーが止まっても、別の拠点のDNSサーバーが引き続き名前解決サービスを提供できるからだ。またDNSサーバーの台数を増やすのは、DNSキャッシュポイズニング対策という狙いもある。

　そのために、（データセンターを含む）自社管理下の設備に構築したDNSサーバー（以下「自社管理のDNSサーバー」）や、レンタルサーバー事業者あるいはISPが提供しているDNSサービス（以下「非クラウド系DNSサービス」）など、複数の種類のDNSサーバー／サービスを併用することが多い。

　筆者も社外に公開しているWebサイトやメールサーバーのために、自社管理のISC BINDベースのDNSサーバーと非クラウド系DNSサービスを約7年間併用していた。そこで感じた問題点を簡単に記す。

●サーバー／サービスによって管理方法がバラバラ

　非クラウド系DNSサービスは、事業者あるいはサービスが異なると管理UIも異なる。また自社管理のDNSサーバーも、ISC BINDやNSDといったソフトウエアによって設定方法は異なる。そのため、それぞれに設定ファイルあるいは設定手順書などを用意せねばならず、手間がかかり、効率的とは言えない。

●自社管理のDNSサーバーは維持に手間がかかる

　自社管理のDNSサーバーの場合、DNSサーバーソフトウエアからOS、物理マシンあるいは仮想化基盤など、自社の都合に合わせて選択する自由がある。そのため、要件に合わせてきめ細かく対応しやすいというメリットがある。

　その半面、DNSサーバーソフトウエアの更新から、OSのパッチ適用、マシンのハードウエアのメンテナンスなどなど、多くの保守作業を管理者自身が請け負わなければならない。

●自社管理のDNSサーバーは稼働率が低くなりがち

　自社設備内にDNSサーバーを設置した場合、例えばその建物の電気設備の定期点検によって数十分〜数時間の停電が生じる。自家発電でも用意していない限り、いずれのサーバーも停止せねばならず、稼働率は下がってしまう。

●非クラウド系DNSサービスには制限が付きまとう

　非クラウド系DNSサービスの場合、保守は事業者が請け負うので管理者の手を煩わせることはない。稼働率も自社内設備よりは高いことが期待できる。

　その一方で、レンタルサーバー事業者／ISPが提供するDNSサービスは自由度が低く、制限が付きまといがちだ。筆者が経験した制限を以下に記す。

• DNSの逆引きゾーンを配置できない
• SRVレコードなど、一般的でないレコードタイプを設定できない
• （ゾーン転送における）マスター／スレーブのどちらか一方のサーバーしか利用できない
• 名前解決できるのが、同じ事業者が提供するサーバー／サービスに限定される
• 利用できるゾーン数に上限がある（それも10ゾーン程度と少ない）
• ゾーン転送の頻度に上限があり、また手動での強制ゾーン転送もできない（レコード変更を全サーバーに素早く反映しにくい）
• DNSサーバーを増減または移設する際、書類による申請が必要

　筆者の場合、こうした制限から用途に応じて複数のDNSサーバーを使い分けざるを得ず、それがまた管理上の手間を増やす悪循環に陥っていた。

クラウドベースのDNSサービスに移行してみた

　こうした状況を打開すべく、筆者は管理下の全DNSサーバー／サービスをクラウドベースのDNSサービスに移行した。ここでいう「クラウドベース」とは、クラウドプラットフォーム上にあらかじめ構築されたSaaS（もちろんマネージドサービス）という意味だ。具体例としては、次のサービスが挙げられる。

• アマゾン ウェブ サービス（AWS）の「Route 53」
• グーグル（Google Cloud Platform）の「Google Cloud DNS」
• マイクロソフト（Microsoft Azure）の「Azure DNS」

　これらは総合的なクラウドサービスにおける多種多様なメニューの一つである。ただし、その汎用性は高く、ラインアップされた他のメニューを併用することなく単体で利用できるし、他社のリソースに対しても名前解決を提供できる。

　筆者が主に使っているのはGoogle Cloud DNSで、一部でAWS Route 53も利用している。そこで本稿ではGoogle Cloud DNSを例として、クラウドベースだとオンプレミスのDNSサーバーやレンタルサーバー事業者／ISPのDNSサービスと何が違うのか、またメリット／デメリットは何か、といったことを紹介したい。

Google Cloud DNSのセットアップ

　Google Cloud DNSを使い始めるには、次のような作業を実施する必要がある。

• GoogleアカウントでGoogle Developers Consoleにログインする
• Google Developers Consoleの上部メニューの［プロジェクトを選択してください］をクリックして、プロジェクト（Google Cloud Platformでの管理単位の一つ）を新規作成する
• Google Developers Consoleの左側メニューから［ネットワーキング］−［Cloud DNS］をクリックする（この操作によりGoogle Cloud DNSに必要なAPIが自動的に有効化される）
• ゾーンを新規作成する（この過程で請求先アカウントの作成と、決済のためのクレジットカード登録が必要になる。無料試用も可能）

　これらはいずれもWebブラウザーで管理画面を操作するだけでよい。またUIは日本語化されていて操作は難しくない。そのため、DNS管理者であれば1時間もかからずに準備は完了できるだろう。

DNSの設定がGUIでもAPIでも可能

　Google Cloud DNSでは、Webベースの管理画面でゾーンの作成やレコードの追加といった作業が簡単にできる。WindowsのGUI操作に慣れたDNS管理者であれば、何ら難しいことはないだろう。

Google Cloud DNSのWeb管理画面からゾーンを作成する
GUIで簡単にゾーンの追加や削除ができる。またゾーンを追加すると自動的にSOAレコードとNSレコードが生成されるのも便利だ。
　 （1）Google Cloud DNSはネットワーキングサービスに分類されている。
　 （2）新しいDNSゾーンを作成するための設定項目。

Google Cloud DNSのWeb管理画面からレコードを追加する
　 （3）同じくGUIでAレコードを追加しているところ。少数のレコードを操作するなら、GUIの方が手軽で便利だ。

　その一方で、RESTful APIやコマンドラインコマンドでゾーンやレコードを操作することも可能だ。これにより、大量のレコード操作を短時間で手間なく実行したり、一連の定型作業を自動化したりできる。

• Google Cloud DNSのAPIリファレンス［英語］（Google Cloud Platform）
• Google Cloud DNSのコマンドラインコマンド「gcloud dns」のリファレンス［英語］（Google Cloud Platform）

　特にAPI／コマンドラインは非クラウド系DNSサービスでは利用できないことが多いので、Google Cloud Platformの大きなメリットといえる。