【実践編2】シナリオに沿ったDNSサーバを検討してみる

ある企業では10年以上、bindで構築されたDNSサーバ群を運用しています。
bindでは多くの脆弱性が見つかるため多くのパッチ適用や、DNSSECの設定が複雑であることから管理/運用に手間がかかっており、これらを課題に感じています。またBindの基盤OSのサポート終了からDNSサーバをリプレイスすることを計画しています。今回はこういったシナリオにおけるDNSサーバリプレイス案件を想定した新規DNSサーバの構築とその評価/検証を行います。

この記事は「2. 概要・要件定義 / 3. システム設計」と重なる部分を多く含みます。
今回のDNS構成を決定した背景と仮定的な課題を紹介しています。

シナリオ

背景

ある企業/組織では外部向け権威DNSサーバ、内部向け権威DNS兼DNSキャッシュサーバをBINDで運用しています。
この組織ではBINDのセキュリティ面の課題と運用の課題を抱えており、またBINDの基盤OSのサポート終了からDNSサーバをリプレイスすることを決定しました。既存の社内ITインフラストラクチャーの大まかな構成は以下の通りです。

構成3

課題

この企業では現状DNSの環境/運用に関して以下の課題を感じています。

セキュリティに関する課題
- 内部DNSサーバ機能が1つのソフトウェア/1つのサーバで実現されているため、セキュリティと耐障害性に対する不安がある
- BINDのセキュリティに関して不安があり、別のDNSソフトウェアの使用を検討している
運用負荷に関する課題
- BINDは毎年多くの脆弱性が発見されているため、現行の運用ではパッチを当てる頻度が多い
- BINDはCUIによる管理が基本であるため現状bashファイルによる設定管理を行っているが、Webで確認できるようにしたい

提案

今回の条件では以下構成でDNSサーバ群を構成することを提案しました。

構成3

外部用権威DNSサーバ … PowerDNS
内部用権威DNSサーバ … PowerDNS+Poweradmin
内部用DNSキャッシュサーバ … UnboundDNS

外部と内部の権威DNSサーバにPowerDNSを採用し、DNSキャッシュサーバにUnboundDNSを採用する構成です。
PowerDNSを採用した理由はゾーン管理にデータベースを利用できること、サードパーティではあるが管理用WebUIが提供されているためです。これにより堅牢なDNSゾーンファイルの管理と運用負荷の軽減を見込むことができます。
また、UnboundDNSをDNSキャッシュサーバとして採用した理由は、再帰的な問い合わせとDNSSEC検証に特化していること、高速かつ安全なキャッシュサーバとして数多くの実績があるためです。