BIND構成の最適化 - 1
BIND-ひいてはDNSが持つ機能に着目してみると、その機能は3つに分類することができます。
- 自分以外のドメイン(ゾーン)情報を解決するフォワーダ/キャッシュサーバ機能。自分が管理しているドメイン以外のドメインやホスト名を解決するための機能です。
- 自分自身のドメイン(ゾーン)を管理するコンテンツサーバ機能。自分が管理しているドメインのホスト情報のマスターファイルを管理する機能。
- 自分自身のドメイン(ゾーン)情報を提供するアクセスサーバ機能。ネットワーク内にDNSサーバとして公開し、コンテンツサーバから得た自分が管理するドメイン内のホスト情報を提供する機能
ちなみにキャッシュサーバとはいっても、WebのProxyサーバとは違いますので混同なきよう。キャッシュするのはあくまでDNSレベルでの情報です。
さて、多くの場合、この3つの機能を一台のサーバで行っていることが非常に多いのですね。
インターネットへのアクセスが少ない環境や、家庭内で建てている自宅サーバであればいざ知らず、ある程度の人間が集まる企業や学校といった法人環境でこのような構成になっている場合、何が起こるか。
- キャッシュ過多よるリソース不足
- アクセス過多による名前解決時間の増加＝アクセスレスポンスの低下
- キャッシュ汚染によるフィッシング/ポイズニング被害の拡大
…いろいろ考えられるので、部分ごとに考えてみることにしましょう。
今回はキャッシュサーバについて考えてみます。
例えばexample-corp.co.jpドメイン配下の人がwww.google.comにアクセスしたいよ、という場合、キャッシュサーバはRoot DNSからcomを調べてgoogleを調べて、そしてwww.google.comを調べます。
これが一つや二つのホスト名/ドメイン名であれば問題ないのですが、たくさんの人が集まれば集まるほど、このキャッシュは膨れていきます。最終的にどのくらいキャッシュされるかは、キャッシュサーバのハードウェアスペック、メモリ搭載量に依存します。
このキャッシュサーバが厄介なのは、"どのくらい使われるか"を予測しにくい点にあります。
100人の社員を抱える会社があって、100人が100人、みんな同じホスト、www.google.comだけ利用するのであれば問題はありません。
が、問題は100人が100人、違うドメイン/ホストを全くばらばらの頻度で参照することにあります。
今はWebアクセスの話だけしかしませんが、メールの扱いも考えると、その数は膨大になりますね。
そのような、いつどれだけのリソースを消費されるかわからないキャッシュサーバ機能を他のサーバ機能と一緒に同居するのは、ちょっと危険ですね。
おまけに、キャッシュ汚染が発生した場合の解決方法は、DNSサービス(BIND)の再起動しかありません。
他のサーバ機能が一緒になっている場合、巻き添えを食らって再起動しなければなりません。EコマースサービスをDNS提供しているサーバの場合、数秒から数十秒の機会損失が発生してしまいます。
全てのDNS機能が同居している場合、「View」を切っているから大丈夫じゃね？という人もいます。
確かに、Open Recursion(Open Recursion:キャッシュサービスを世界中のホスト/Internetに公開した状態)を防ぐことはViewで可能でしょう。それも確かに問題なのですが、本質的な問題を無視しているんじゃねーの？というのが正直なところです。
問題の本質は前述通り、
- リソース消費を予測できない
- 再起動しなければキャッシュ異常状態を回復できない
点にあります。
業務妨害を企んだりキャッシュ汚染を試みるのは、別に外部の人間だけじゃないので。むしろアクセスを許している分、内部の人間による犯行による被害をいかに最小限に抑えるか、がセキュリティの要だと思うのですね。
キャッシュしないで自ドメイン以外への問い合わせを別サーバに転送する方法もありますが、これもTCP/UDPセッション数を見積もりにくい弱点があります。
何より自ドメイン以外の参照量は増えことすれど、減ることはあり得ないと考えています。インターネット接続をやめるところはななく、情報を効率的に集めようと思ったらインターネットほど手軽なメディアもないでしょう。そしてDNS参照量は今後IPv6が普及すればするほど、爆発的に増えてきます。
そうなった時、現状の構成で大丈夫かどうかは、会社のIT化とその利用頻度に大きく依存してきます。
小さいところはどうすりゃいいかって？自分で管理するのをやめてはどうですか？効率的なキャッシュサーバはお使いのISPで提供されているでしょうから。
そうじゃないところは、コンテンツサーバ/アクセスサーバ/キャッシュサーバの機能を分離しましょう。必要な資源を必要な機能に確実に分け与えるには、サーバの物理的分離(あるいは仮想化による論理的な、でも他のサーバ機能を巻き込んでダウンしない設計)が必須です。
さて、ここまでのまとめです。
- DNSサーバの機能をおさえる
- キャッシュサーバとコンテンツ/アクセスサーバ分類する
- キャッシュサーバを用意できない場合、またはお金がない場合は使っているISPのサービスで機能分離できないか確認してみる
続いて、キャッシュサーバの物理的構成について考えてみます。
キャッシュサーバのハードウェアにしろ、ソフトウェアにしろ、こいつがダウンした場合はインターネットへの接続に致命的なダメージを与えます。Web閲覧だけでなく、メールの送受信にも支障が出ます。メール送信するとき、どのメールサーバに送信すべきか、メールサーバが判断できなくなっちゃいますので。
なので、キャッシュサーバを自前で持つ場合、この二重化対策を行う必要があります。
が、キャッシュサーバ機能を有効にしたLinuxなりWindowsなサーバを2台用意しただけでは片手落ちです(放送禁止用語だっけ？どうでもいいや。馬鹿が騒いでるだけだし)。
これはスタブリゾルバ、DNSクライアントの動作に問題があるため、単純な並列配置では冗長化対策にならないだけでなく、クライアントに対する大きな負荷になってしまいます。
キャッシュサーバ機能を有効化したdns1/dns2というサーバがあるとしましょう。通常時クライアントはdns1にDNSクエリを行い、名前解決を行います。そしてdns1がダウンしたとき、dns1に投げたクエリのタイムアウトをもってdns2へ改めてDNSクエリを行います。
その時クライアントが「dns1はダウンしている」ということを覚えればいいのですが、覚えません。常に最初のDNSクエリはdns1へ投げます。これ、WindowsもLinuxも一緒です。多分Macもそう。
タイムアウトまで3秒くらいあるとしましょうか。その3秒間、クライアントは常に待ちの状態です。単にWebを閲覧しているクライアントであれば問題ないのかもですが、これがメールサーバとかになったら…？1通のメールを処理する時間は3秒以上になります。扱うメールのサイズにもよりますが、今どきなスペックのメールサーバであれば1通のメール処理時間なんて1秒かかりません。それが3秒はかかるようになります。これってすごい時間差だと思いませんか？というか、やっぱり致命的です。メールの流量が多いネットワークであれば、メールサーバのキューが溢れて豪い目に遭うことは想像に難くありませんね。
では、どうすりゃいいのか。
最終的にたどり着いた答えは
のどちらかです。
幸か不幸か、Solarisな環境であればSun Clusterが公開されていますので、NICの二重化も含めて(ソフトウェアは)無料で対策することは可能ですね。
面倒くさいので私は後者を選びますが…。
そんな製品ないかなぁ、と思っていたらありました。以前にもリンク張ったような気がしますが。
結構いい値段しますが…決して高くはないよなぁ、と。
VRRPで冗長化しているっぽいので、多分切り替え時の反応速度はいいような気がします。
GUIもぱっと見る限りいい線いってるんじゃないかなぁ。後輩育成しなきゃいけないときにviの使い方から教えなきゃいけないのはナンセンスだと思うし(そんな後輩しかいない会社だったら、多分すぐに辞表出すぉ)、ゾーン情報の見通しが悪くなるのは自宅のDNSサーバを見ててもわかりきってることだし。こういうGUIならすぐ扱えるんじゃないかな、と。
MSのDNS?そもそもMS嫌いだし。
という訳で、今回のまとめのまとめ。
- DNSサーバの機能をおさえる
- キャッシュサーバとコンテンツ/アクセスサーバ分類する
- キャッシュサーバの冗長化は必須。冗長化はクラスタ化も含めて常に同一IPアドレスで継続したサービスを提供できるようにする。並列冗長化は意味がない。
長かったー＞＜
