次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（3/3 ページ）

VIEWによるスプリットDNS

　第9回において、セキュリティ対策の一環としてキャッシュサーバとゾーンサーバの分離運用法を紹介しました。問い合わせ元ごとにDNSサーバに求められる機能が違うため、機能ごとにDNSサーバを分けて運用しようというものでした。こうした手法は「スプリットDNS」として広く運用されています。

　では、機能ごとにサーバを用意しなければならないのでしょうか。その必要はありません。例えば、ネットワークカードを複数装着してDNSサーバをマルチホームやIPエイリアス化し、それぞれのインターフェイスでDNSを立ち上げるなどの手法があります。

　しかし、BIND 9ではもっと簡単に、要求元IPアドレスごとにゾーン情報やBIND 9の振る舞いを変化させることが可能です。

VIEWを使ったスプリットDNSの例

　図5のような例を検証します。

図5　想定環境
注：第9回

　内部（192.168.10.0/24）に対してはプライベートアドレスで正引き／逆引きができ、キャッシュサーバ機能を有効にします。外部（内部以外のネットワーク）に対してはグローバルアドレスで正引き／逆引きができ、キャッシュサーバ機能を無効にします。このような場合、通常は次のように2つのDNSサーバを設定する必要があります。

　VIEWを用いれば、1つのnamed.confに集約することができます。view{};ステートメントは、match-clientsオプションを使用して、IPアドレスまたは特定のネットワークに合致したものにのみ、指定のオプションとゾーン情報を適用します。

　view{};セクションを使う場合、match-clientsで指定するIPアドレスやネットワークは先頭のview{};セクションから順に評価されます。VIEWを用いたnamed.confでは、まず192.168.10.0/24に合致しているかが評価され（2）、それに漏れたものが次のview{};セクション（3）の評価対象になります。（4）では「any」となっているものの、すでに192.168.10.0/24が評価されているため、192.168.10.0/24以外の要求元IPが評価対象となります。

　view{};セクションにはoptions{};セクションに指定できるものがそのまま使用できますが、（5）、（6）、（7）のような、どのview{};にも共通のゾーン情報でも、view{};セクションの数だけ記述する必要があります。

　match-clients{};が複数のIPやネットワークで複雑になる場合は、ACL（アクセスコントロールリスト）を用いることができます。

　options{};とview{};では、view{};での指定が優先されます。以下の例では、192.168.10.0/24からアクセスした場合、BINDは（A）ではなく（B）として振る舞います。

VIEW使用時の注意

　非常に便利なVIEWですが、スレーブサーバの運用には多少難儀します。

　スレーブサーバでも同様にVIEWを使う場合、view{};で使用するゾーン情報をマスターサーバから取得する必要があります。しかし、VIEWを用いたnamed.confのような場合でスレーブサーバのアドレスが192.168.10.203の場合、2番目のview{};セクション（3）にたどり着くことができません。先に紹介したように、view{};の評価は先頭から行われ、合致した時点で終了するため、（8）や（9）のゾーンファイルを見つけることができません。このような場合は、ゾーン転送ではなくrsyncや手動でゾーンファイルの同期を行うなどの運用が必要になります。