第2回 DNSベストプラクティスとは「隠す」そして「重ねる」


澁谷 寿夫
Infoblox株式会社
Systems Engineer
2007/12/14


 塵も積もれば山となる――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について見直していきたいと思います。

3/3
 

Index
DNSベストプラクティスとは「隠す」そして「重ねる」
  Page1
いまだに設定ミスの多いDNS
DNSベストプラクティス構成のポイント
なぜプライマリを隠すのか
  Page2
「プライマリを隠す」――いったい何から?
具体的な設定を行ってみよう
フォワーダーを冗長化する意味
Page3
塵も積もれば山となる――DNS冗長化のススメ
DNS設定フローチャートで確認ポイントをチェック


Profile
澁谷 寿夫(しぶや ひさお)

Infoblox株式会社
Systems Engineer

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

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

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

もう一度見直したいDNS/DHCP 連載インデックス


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間