DNSベストプラクティスとは「隠す」そして「重ねる」：もう一度見直したいDNS／DHCP（2）（3/3 ページ）

[澁谷寿夫，Infoblox株式会社]

塵も積もれば山となる――DNS冗長化のススメ

　では、実際に何が問題なのでしょうか。

　「利用されるDNSサーバとその順序」を見ると分かるように、DNSへのクエリーは必ず優先DNSサーバに送られ、応答がない場合に代替DNSサーバに送られます。つまり、クエリーごとに3秒のタイムアウトが発生します。1回のクエリーであれば、大した時間ではないので皆さんも気にしたことがないのではないでしょうか。

　ですが、1000人の社員が1日平均20回のユニークな名前解決が必要な使い方をしている場合を考えてみましょう。優先DNSサーバが1日ダウンしていた場合の総タイムアウト時間は、

1000×20×3＝60000（秒）＝約16時間

となります。こういう計算をすることに意味があるかどうかという話もあるかと思いますが、経営者にとっては決して小さくない時間ではないでしょうか。

　リゾルバのDNSサーバへの到達性（reachability）に関しては、あまり考えられてないのが現状です。タイムアウトをさせないためには、優先DNSサーバが落ちないようにする必要があります。そのための手段としてフォワーダーを冗長化することで、非常に大きなメリットが発生します。

　ですが、WindowsやLinuxでは、HAクラスタ構成による冗長化をするのは簡単ではないかもしれません。そういった場合は、HAクラスタ構成に対応している製品やロードバランサを利用し、優先DNSサーバが極力落ちないよう、構築するという方法があります。

DNS設定フローチャートで確認ポイントをチェック

　前回から、DNSサーバの設定の際に再帰的名前解決とゾーン転送の設定に気をつけるという話をしてきました。

　DNSのまとめとして、DNSサーバ構築の際に、機能によってどのように設定するかをフローチャートに示します。

図3　DNS設定のフローチャート

　このチャートを基に、DNSサーバの設定の見直しも検討してもらえればと思います。

　次回はDHCPについて見直していきたいと思います。

筆者紹介

澁谷寿夫（しぶやひさお）

Infoblox株式会社　Systems Engineer

学生時代にLinuxと出会い、趣味と仕事で利用するようになる。

ISP勤務時代に出会ったCobaltに一目惚れしてしまい、ついにはCobaltに入社してしまう。それ以後アプライアンスをこよなく愛し、現在はコアネットワークサービスのアプライアンスメーカーであるInfobloxに勤務。

プライベートでは、オープンソースになったCobaltのGUIを開発するProject BlueQuartzの主開発者の1人として活動中。