DNSサーバ設計
１．主な構成
(1) 構成概要図
(2) プロセス構成
管理するドメインは「ranonet.ne.jp」のみなので BINDのデーモンは1つで運用します。 セカンダリDNSサーバはありません。
２．名前解決機能
(1) リスニングポート
名前解決では標準で53/udpのポートが使用されます。 特に変更する要件はないためそのまま使用します。
| IPアドレス | ポート番号 |
|---|---|
| 192.168.0.11 | 53/udp |
ゾーン転送では53/tcpが使用されますが、DNSサーバが1台のみで ゾーン転送自体を行わないため特に触れないものとします。
(2) ドメイン管理
DNSサーバでは「ranonet.ne.jp」のゾーン情報を管理します。 正引き、逆引き双方の情報を管理対象とし、リゾルバ（ブラウザ等） からのクエリーに応答します。
| 正引きゾーン | 逆引きゾーン |
|---|---|
| ranonet.ne.jp | 0.168.192.in-addr.arpa |
(3) クエリーの回送
インターネット経由で社外のウェブサーバを利用するような場合、 ranonet.ne.jpドメイン以外のドメインに対する名前解決が必要となります。 社内DNSサーバは自身が管理していないドメイン（ranonet.ne.jp以外の全て）に対する クエリーを受け取った場合、対象のドメイン情報を管理している 外部のDNSサーバに代理で問い合わせを行い、その結果を リゾルバに応答します。
(4) DNSキャッシュ
DNSサーバが持っているキャッシュ機能を利用します。 外部DNSサーバに代理で問い合わせを行った際にドメイン情報をキャッシュに保持します。 キャッシュの保持期間は問い合わせ先のDNSサーバで設定されているTTL(Time To Live)に従います。 そのためドメイン毎にキャッシュの保持期間は異なります。 リゾルバからクエリーを受け取った際に、まずはDNSキャッシュを確認し、 キャッシュ上に対象のドメイン情報があれば外部DNSサーバに問い合わせを 行わずにキャッシュの情報を元にリゾルバへ応答します。
３．セキュリティ対策
(1) ルートディレクトリ変更
DNSサーバはその性質上、常時アクセス可能状態であることから、 悪意ある攻撃の対象となるケースが多いのが実状です。 既知の不具合対策としてBINDを最新バージョンにアップデートしても 未知の脆弱性を突いたバッファオーバーフロー攻撃等により BINDの動作権限を奪取された場合も考慮し、対策を講じます。 BINDではchroot jail機能をサポートしているため、この機能を利用します。 chroot jail機能ではBINDが動作可能なルートディレクトリを個別に準備し、 それ以外のディレクトリへアクセスできない状態とすることで 攻撃を受けた場合の被害範囲をBIND内にとどめます。
(2) バージョン情報の秘匿
アプリケーションの脆弱性を突いた攻撃が行われる場合、 まず始めに導入されているバージョンの確認を行う手口が使われます。 BINDは初期状態ではバージョン情報の問い合わせに対して正常に応答してしまうため、 バージョン情報以外の情報を応答する対策を行います。 応答するバージョン情報はBINDの設定ファイルで行います。 "options"定義項目において、バージョン情報（パラメータ：version）に 任意の文字列を指定します。 ここでは"Unknown"の文字列を応答することとします。
(3) クエリー元ホストの制限
初期状態ではBINDはすべてのホストからの名前解決を受け付けます。 しかし、悪意あるユーザ（ホスト）からの処理を受け付けないため、 また、不要なホストからの問い合わせの受け付けによりサーバに過剰な 負荷を与えないために、クエリーを処理可能なホストを制限します。 クエリーを受け付けるホストは同一サブネット内（192.168.0.0/24）に制限します。 このサブネットのみをクエリー許可ホストとして登録することで、 他ホストからのクエリーを制限します。 なお、許可されていないホストからのクエリーを受け付けた場合は、 REFUSEのレスポンスをリゾルバへ返します。 ただし、本機能で制限可能となるのは、ホスト、サブネット単位のクエリーであり、 許可されたホストを利用して悪意ある処理が実行された場合については制限できません。
(4) クエリー回送元ホストの制限
クエリー元ホストの制限機能では当DNSサーバが管理している ドメイン情報に対する制限をかけますが、回送元ホストの制限機能では 管理していないドメイン情報に対する制限をかけることができます。 それ以外の機能や特徴は同様です。 クエリーの回送も同じく同一サブネット内（192.168.0.0/24）のホストに制限します。
(5) ゾーン転送の制限
通常DNSサーバは耐障害性を考慮して2台以上で構成します。 これら複数のDNSサーバが同じゾーン情報を保持できるようにするために ゾーン転送機能を有しています。DNSサーバの種類は ゾーン情報を管理しているマスタサーバと、マスタサーバから ゾーン情報をコピーして保持するスレーブサーバの2種類に分かれます。 ゾーン転送機能ではスレーブサーバからマスタサーバにゾーン転送を要求し、 マスタサーバからスレーブサーバにゾーン情報を送信します。 初期状態では要求されればどのホストに対してもゾーン転送を 行ってしまうため、悪意あるユーザ（ホスト）にゾーン情報を 詐取されてしまうことがあります。 本システムではDNSサーバは1台のみであり、ゾーン転送機能を利用しません。 ゾーン転送されないように全てのホストに対してゾーン転送を禁止する設定とします。
４．起動・停止
(1) 起動・停止方式
DNSサービスはOS稼働時に常時利用可能とするために 起動停止をrcで制御します。 これによりOS起動時にrcからnamedデーモンが自動で起動され、 OS停止時に自動で停止されます。
(2) ランレベル
Linuxはランレベル3で運用しますが、 その他ランレベルに切り換えた場合でもnamedサービスが利用できるように ネットワークサービスが利用できるランレベルでは namedデーモンを起動することとします。
| ランレベル | 動作内容 | 設定 |
|---|---|---|
| 0 | システムの停止 | OFF |
| 1 | シングルユーザモード | OFF |
| 2 | NFSファイル共有のないマルチユーザモード（テキストベース） | ON |
| 3 | 完全マルチユーザモード（テキストベース） | ON |
| 4 | 通常、未使用 | ON |
| 5 | 完全マルチユーザモード（GUIベース） | ON |
| 6 | システムの再起動 | OFF |
５．ログ出力
BINDは初期状態ではシスログ（/var/log/messages）へメッセージを出力する設定となっています。 ただし、このままでは多数のアプリケーションのログが混在するため可読性が悪いです。 そのため個別のログファイルに出力する設定とします。 BINDではメッセージの種別とログレベルに応じて出力先を設定することが可能であるため、 全般の稼働情報を記録する「稼働ログ」とリゾルバからのクエリーを記録する 「クエリーログ」の2通りのログを取得することとします。
(1) 稼働ログ
BINDの動作を記録するログです。 問題発生時にBINDの動作を時系列で確認するために正常メッセージも含めて出力します。 デバッグレベルのログを出力するとファイスサイズが巨大になり ディスク領域を圧迫することが懸念されるため出力しません。 デバッグレベルは障害発生後の再現テストなどで使用することも考えられますが、 その際は一時的に設定を変更することで出力することとします。 BINDで出力可能なログのカテゴリとログレベルを以下に示します。
| # | ログレベル | 重要度 | 情報量 | 内容 |
|---|---|---|---|---|
| 1 | critical | 高い 低い | 少ない 多い | |
| 2 | error | |||
| 3 | warning | |||
| 4 | notice | |||
| 5 | info | |||
| 6 | debug [0～99] | |||
| 7 | dynamic | - | - | コマンドにより動的に変更する場合に使用 |
| # | カテゴリ | 内容 |
|---|---|---|
| 1 | database | ゾーン情報やキャッシュ情報など、データベースに関する記録 |
| 2 | security | 要求の承認／否認の記録 |
| 3 | config | 構成ファイルの構文解析と処理の記録 |
| 4 | resolver | クライアントに代わって実行されるキャッシュサーバの動作に代表される、再帰検索のようなDNS解決の記録 |
| 5 | xfer-in | サーバが受信したゾーン転送の記録 |
| 6 | xfer-out | サーバが送信したゾーン転送の記録 |
| 7 | notify | NOTIFY（通知）プロトコルの記録 |
| 8 | client | クライアント要請の処理記録 |
| 9 | network | ネットワーク操作の記録 |
| 10 | update | DDNSの記録 |
| 11 | queries | 問い合わせクエリーの記録 |
| 12 | dispatch | サーバモジュールへ入ってくるパケットを処理するCPU割り当て（ディスパッチ）の記録 |
| 13 | dnssec | DNSSECやTSIG処理の記録 |
| 14 | lame-servers | DNS解決の際にほかのサーバで見つけた設定ミス（lame）の記録 |
| 15 | general | 上記以外の多くのログはカテゴリが未分類であり、それらはgeneralに分類される |
| 16 | default | categoryで意図的に指定された以外のカテゴリがここで定義される |
本システムでは稼働ログとして取得する情報はログレベルinfo以上とし、 上記項目11を除く全てのログを1ファイルに出力するものとします。
【ログ出力例】
(2) クエリーログ
リゾルバから受け付けたクエリーの履歴（上記カテゴリの項番11）を出力します。 当該情報は1リクエスト1レコードで出力されるため、他のカテゴリと異なり出力量が膨大になります。 そのため、可読性を考慮してカテゴリがクエリーのみ個別のファイルに記録するものとします
【ログ出力例】