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

[鶴長鎮一，＠IT]

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サーバを設定する必要があります。

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         recursion yes; }; zone "." {         type hint;         file "named.ca"; }; zone "localhost" {         type master;         file "local.zone"; }; zone "0.0.127.in-addr.arpa" {         type master;         file "local.rev"; }; zone "example.jp" {         type master;         file "example_internal.zone";　←内部向け正引きゾーンファイル }; zone "10.168.192.in-addr.arpa" {         type master;         file "example_192.rev";　←192.168.10.0/24逆引きゾーンファイル };

内部向けnamed.conf 注：それぞれのゾーンファイルの記述については、第2回を参照してください。

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         recursion no; }; zone "." {         type hint;         file "named.ca"; }; zone "localhost" {         type master;         file "local.zone"; }; zone "0.0.127.in-addr.arpa" {         type master;         file "local.rev"; }; zone "example.jp" {         type master;         file "example_external.zone";　←外部向け正引きゾーンファイル }; zone "XX.XX.133.in-addr.arpa" {         type master;         file "example_133.rev";　←133.xx.xx.0/24逆引きゾーンファイル };

外部向けnamed.conf

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

options {         directory "/var/named";         pid-file "/var/run/named/named.pid"; }; view "internal" {　←内部向けVIEWの定義　（1）         match-clients { 192.168.10/24; };　（2）         recursion yes;         zone "." {                 type hint;                 file "named.ca";         };         zone "localhost" {                 type master;                 file "local.zone";         };         zone "0.0.127.in-addr.arpa" {                 type master;                 file "local.rev";         };         zone "example.jp" {                 type master;                 file "example_internal.zone";　←内部向け正引きゾーンファイル         };         zone "10.168.192.in-addr.arpa" {                 type master;                 file "example_192.rev";　←192.168.10.0/24逆引きゾーンファイル         }; }; view "external" {　←外部向けVIEWの定義　（3）         match-clients { any; };　（4）         recursion no;         zone "." {　（5）                 type hint;                 file "named.ca";         };         zone "localhost" {　（6）                 type master;                 file "local.zone";         };         zone "0.0.127.in-addr.arpa" {　（7）                 type master;                 file "local.rev";         };         zone "example.jp" {　（8）                 type master;                 file "example_external.zone";　←外部向け正引きゾーンファイル         };         zone "XX.XX.133.in-addr.arpa" {　（9）                 type master;                 file "example_133.rev";　←133.XX.XX.0/24逆引きゾーンファイル         }; };

VIEWを用いたnamed.conf 注：view名"internal"、"external"には運用しやすい任意の名前を指定します。

　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（アクセスコントロールリスト）を用いることができます。

acl "example-net" {         localhost;       #定義されたACLを用いた場合（none／any／localhost／localnetsを既定のACLとして利用可能）         192.168.10.250;  #直接要求元のIPを指定した場合         192.168.10/24;   #ネットワーク単位で指定した場合 }; view "internal" {　←内部向けVIEWの定義         match-clients { "example-net"; }; （省略）

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

options {         directory "/var/named";         pid-file "/var/run/named/named.pid";         recursion no;　（A） }; view "internal" {         match-clients { 192.168.10/24; };         recursion yes;　（B）         zone "." { （省略）

VIEW使用時の注意

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

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

「次回」へ

「実用 BIND 9で作るDNSサーバ」バックナンバー

• BIND 9を徹底活用するためのTips集
• DNSの拡張仕様、SRVレコードとENUM
• 次世代のセキュリティ拡張DNSSECをBIND 9で実現
• IPv6対応DNSサーバの実現
• BIND 9のチューニングと大規模運用
• BIND 9の運用情報収集と分析方法
• BIND 9のセキュリティ対策
• DHCPとDynamic DNSの連携システム
• Dynamic DNSの基礎とnsupdateコマンド
• サブドメインの運用と委任
• スレーブ・サーバのゾーン転送とセキュリティ
• キャッシュ／逆引きDNSの構築と運用
• メール／Webサーバを効率的に動かすゾーン設定
• すべての基礎、マスター・ゾーンサーバの設定
• BIND 9の改ざんチェックとインストール