以前は、DNSキャッシュサーバとDNSコンテンツサーバは、同じサーバでサービス提供していました。しかし、現在は、このような構成はセキュリティ上好ましくないと言われています。unboundは、DNSコンテンツサーバの機能を持っていません。そのため、DNSキャッシュサーバとDNSコンテンツサーバの分離は、必須です。
ここでは、unboundを利用する場合のシステム構成について説明します。
もっとも基本的な構成は、DNSコンテンツサーバをインターネットに向けて公開するためDMZに配置し、DNSキャッシュサーバを組織内に配置する構成です。
次のようにローカルデータを定義することで、内部DNSコンテンツサーバとしての役割をunboundに持たせることもできます。
/etc/unbound/local.d/example.conf ---------------------------------- local-zone: "example.com" static local-data: "www.example.com IN A 192.168.1.7" ----------------------------------
unboundは、簡易的なDNSコンテンツサーバとしても動作します。しかし、大きなゾーンを管理するためには、専用の内部DNSコンテンツサーバを配置することもできます。
この場合、組織内のPCに設定するDNSサーバとしては、unboundのIPアドレスを登録します。そして、unboundには、内部DNSコンテンツサーバへの参照を行う設定が必要です。
内部DNSコンテンツサーバを参照させるには、unboundにスタブゾーンの設定をします。例えば、次のような設定を行います。
/etc/unbound/conf.d/stub.conf ------------------------------------ stub-zone: name: example.com ← 内部DNSサーバで管理するゾーン stub-addr: 192.168.1.5 ← 内部DNSサーバのIPアドレス stub-prime: no stub-first: no ------------------------------------
この設定をすると、unboundは、example.comへの問い合わせを受けとると、192.168.1.5に対してアドレスの調査を行うようになります。
この構成は、単純明解です。しかし、さらに下位のゾーンを権限委譲する場合には、注意が必要です。unboundは、example.comの配下のゾーンへの問い合わせは、192.168.1.5に対して行いますが、権限委譲してあっても、その先の問い合わせを行うことができません。
例えば、次のような権限委譲の設定を行ったとします。
--------------------------------------- sub.example.com IN NS ns.sub.example.com ns.sub.example.com IN A 192.168.3.2 ---------------------------------------
しかし、unboundは、example.comの配下のゾーンはすべて192.168.1.5へ問い合わせようとするため、うまく働きません。そのため、ゾーンにNSレコードを定義するのではなく、同様にスタブゾーンを設定することで権限委譲を行うことになります。
--------------------------------------- stub-zone: name: sub.example.com ← 権限委譲先のゾーン stub-addr: 192.168.3.2 ← 権限委譲先のネームサーバのIPアドレス stub-prime: no stub-first: no ---------------------------------------
このように、内部のDNS空間はスタブゾーンの定義で行うことになります。これが不便な場合には、DNSキャッシュサーバを多段構成にするなど、別の工夫が必要になります。
外部DNSサーバで、DNSキャッシュサーバとDNSコンテンツサーバの両方の役割を担っている構成から、分離構成へ移行する場合に、次のようなジレンマが発生することがあります。
こうなると、DNSサーバのIPアドレスは変えることができず、unboundとDNSコンテンツサーバを同じサーバ内に共存させざるおえません。弊社の顧客環境でも、このようなケースがよくあります。ここでは、unboundとDNSコンテンツサーバを同じサーバ上に混在させる方法について解説します。
unboundとDNSコンテンツサーバを別のポートで立ち上げます。unboundは、DNSの標準ポートである53ポートを使い、DNSコンテンツサーバは任意の別のポートで立ち上げます。
unboundには、次のようなスタブゾーンの設定を行います。
--------------------------------------- stub-zone: name: example.com ← DNSコンテンツサーバのゾーン stub-addr: 127.0.0.1@10053 ← DNSコンテンツサーバのアドレス・ポート stub-prime: no stub-first: no ---------------------------------------
この構成では、外部からの問い合わせはすべてunboundが受けることになります。この構成は上手く動作しますが、次の点には注意が必要です。
上記のような制約が好ましくない場合には、パケットフィルタリングで問い合わせを振り分けます。組織内からのローカルアドレスからの問い合わせはunboundへ、インターネットからのグローバルアドレスでの問い合わせはDNコンテンツサーバへポートフォワーディングをします。
この構成はunboundを前面にした構成に比べて欠点がほとんどなく、上手く動作します。ただし、次のような問題があります。
最後の構成は、dnsdistを使った構成です。dnsdistは、PowerDNSの開発元であるPowerDNS.COM BV社により開発されたDNSのロードバランスを行うソフトウェアです。dnsdistでは、DNS問い合わせの種別をチェックして、参照先のDNSサーバを変えることができます。また、参照元のIPアドレスによって、動作を制御することもできます。そのため、再帰問い合わせの場合にはunboundへ、それ以外はDNSコンテンツサーバへ処理を振り分けることができます。また、グローバルアドレスからの再帰問い合わせの要求を拒絶することもできます。
dnsdistには、独自のセキュリティ機構も組み込まれており、dnsdistでログを保管することもできます。そのため、この構成は欠点が少なく、最も安全な構成です。
もっと使い方が知りたい方へ
unboundの操作方法や操作性をデモにてご確認いただけます。使い方のイメージを把握したい、使えるか判断したい場合にご活用下さい。unboundのデモをご希望の方は、下記よりお申込みいただけます。
