検索
連載

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

現在、標準化作業が進行中のDNSSEC。その仕組みとBIND 9での実現方法を解説する。後半では、スプリットDNSの設定方法を紹介。(編集局)

Share
Tweet
LINE
Hatena
前のページへ |       

VIEWによるスプリットDNS

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

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

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

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

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

図5 想定環境 注:第9回図1も参照。
図5 想定環境
注:第9回

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

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

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

VIEW使用時の注意

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

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


Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ |       
ページトップに戻る