社内DNSサーバーの構築

01 Feb 2019

Reading time ~1 minute

社内DNSサーバーを構築する

構築する理由

社内ネットワーク内の情報管理が可能になる

社内に独自のネットワークを構築したい場合（今回の場合だと「gitlab.seven.asia」と社内ネットワーク内で検索すると「192.16.13.111」のIPアドレスにアクセスさせたい場合）、社内で独自のアドレス解決ができるDNSサーバーを構築することでそれが実装できる。

さらに、このDNSサーバーへのアクセス許可を社内LAN内からのみに制限することで、インターネット上にはつながっていない社内専用のGitlabや特定のサービスを利用することができる。

セキュリティ性の高いドメイン管理が可能になる

現在、レンタルサーバー会社等で運用されているドメイン管理のずさんさは数多く報告されており、例えば共用DNSコンテンツサーバの管理運用についての問題等JPRSなども指摘しているものがある。

また、キャッシュ内容を書き換え間違ったサーバーのIPアドレスにアクセスしてしまうDNSキャッシュポイズニングによる攻撃被害を受ける確率が減るというメリットもある。

構築したい状態

今回は以下の要項を満たしたDNSサーバーを構築する。

*.seven.asia のドメインが内部で使用できるようにする
mx, gitlab, nas のレコードを準備 mx: 192.16.13.110 gitlab: 192.16.13.111 nas: 192.16.13.112 ns: 192.16.13.113
それ以外ドメインは外部のネームサーバー(8.8.8.8) に問い合わせする
リクエストは 172.16.10.0/24 からのみ受け付ける

サーバーにアクセス

構築をするサーバーにアクセスする。

$ ssh ユーザー名@アクセス先IPアドレス

BINDをインストール

BINDとは

BINDとは、現在最も広く普及している DNSサーバーソフトウェアの１つであり、DNSサーバー実装の事実上の標準として幅広く使われているものである。

DNSの仕様として規定されているほとんどの機能を実装しているため高機能だが、設定が複雑で導入・管理が難しいとされることもある。広く普及していることもあり攻撃の標的となることが多く、保安上の弱点（セキュリティ脆弱性）が頻繁に発見され、その度に利用者がソフトウェアの更新・入れ替えを余儀なくされることでも有名。(IT用語辞書より)

インストール

$ sudo apt-get install -y bind9

プライベートネットワークアドレスの確認

まず、自分がこれからDNSを構築するネットワークを確認する。今回は内部に構築するため、プライベートネットワークアドレスを確認すればよい。

$ ifconfig

172.—とか192.—-みたいなやつがプライベートネットワークアドレスである（はず）
このアドレスのうち、最初の３つのブロックを使用するためどこかにメモしておく。
（今回の場合だと「192.16.13」の部分）

BINDの設定

そうしたら、いよいよBINDの設定を目的の要項に合わせてしていく。

オプションの設定

まずは、/etc/bind/named.conf.optionsを開き、以下のようにオプションを編集する。

$ sudo vim /etc/bind/named.conf.options

options {
  directory "/var/cache/bind";
  listen-on port 53 { localhost; 192.16..10/24; };
  allow-query { localhost; 192.16.13.0/24; };
  allow-transfer { localhost; 192.16.13.0/24; };
  forwarders { 8.8.8.8; };
  recursion yes;
}

それぞれのオプションやその他のオプションの説明についてはこちらがわかりやすく説明をしてくれている。
その時々も目的に応じて、オプションを変更する必要がある。

こっちも見ておくと良いかも。

オープンリゾルバについて

ここでは、「リクエストは 172.16.10.0/24 からのみ受け付ける」理由として、オープンリゾルバについて説明をする。

オープンリゾルバとは「アクセス元を制限していない状態のDNSサーバー」のことであり、こうした状態にいることで「DNS Amp攻撃」（「DNSリフレクター攻撃」）といった攻撃を受けてしまう可能性がある。

具体的には、DNSにリクエストを送る自分自身のIPアドレスを偽装することで、何も関係のない人にDNSサーバーからの回答（リクエスト先のWebページなど）を送ることが可能になる。

そこで、今回は、サーバーへのリクエストを社内LANからのみに（allow-queryを使って）制限することで、こうした攻撃を防御している。

オープンリゾルバについて詳しくは、こちらがわかりやすく説明をしている。

プライベートネットワーク向けの設定

BINDのオプションの設定が完了したら、いよいよゾーン（今回は sawada.asia）の設定をしていく。

ゾーンファイルの設定

インクルード

まず、プライベートネットワーク向けの設定ファイルは/etc/bind/named.confからインクルードされているため、ここを編集する。

$ sudo vim /etc/bind/named.conf.local

zone "sawada.asia" IN {
  type master;
  file "seven.asia.zone";
};

ゾーンファイルの編集

ここでは、DNSサーバーのホスト名を指定し、そこに対してDNSサーバー（自分自身）がある場所を記載する必要がある。（今回の場合だと、「ns」をホスト名とし、そこにサーバーがある「 172.16.10.113」を記載している）

$ sudo vim /var/cache/bind/seven.asia.zone

$TTL 86400

@ IN SOA seven.asia root.seven.asia (
  2018050600
  3600
  900
  604800
  86400
)

@      IN NS ns.
ns IN A  192.16.13.113
gitlab IN A  192.16.13.111
mx IN A 192.16.13.110
nas IN A 192.16.13.112

ここでの注意点として、named プロセスは、ゾーンファイルのレコードに書かれている資源レコード名およびドメイン名が FQDN ( 末尾がドットの表記法 ) であることを前提としていることがある。
そのため、末尾に「.(ドット)」をつけないと、自動的に「sawada.asia」が追加されて認識してしまう。
そこで、ここではホスト名を「ns」にしたいため末尾に「.」をつける必要がある。

設定の検証

named-checkconfで/etc/bind/named.confを検証。

$ /usr/sbin/named-checkconf

named-checkzoneでzoneファイルを検証します。

$ /usr/sbin/named-checkzone sawada.asia /var/cache/bind/sawada.asia.zone

OKと表示されれば大丈夫

BINDの起動

systemctlで起動

$ sudo systemctl enable bind9
$ sudo systemctl restart bind9

##　動作確認今回はdigコマンドで動作確認する。 (nslookupでも良いと思う)

サーバー内での動作確認

gitlab.sawada.asiaの名前解決を確認

$ dig gitlab.seven.asia @localhost a

192.16.13.111とアドレス解決されていればOK

google.comの名前解決を確認

$ dig google.com @localhost a

なんかそれっぽいIPアドレスが返ってくればOK 指定していないドメインは、外部のネームサーバー(8.8.8.8) に問い合わせていることがわかる。

自分のPC内での動作確認

ssh接続をexitで退出して、社内LANに接続している自分のPCで動作検証

gitlab.sawada.asiaの名前解決を確認

$ dig gitlab.seven.asia @localhost a

192.16.13.111とアドレス解決されていればOK

google.comの名前解決を確認

$ dig google.com @localhost a

なんかそれっぽいIPアドレスが返ってくればOK

感想

目的に沿ったDNSサーバーを構築するためには、BINDのオプションの意味をそれぞれ理解することが超重要（ただ構築するだけなら、誰かが公開しているやつをコピペすれば良いだけ）
ゾーンファイルの中の意味を理解できていないと結構詰まる（そもそものDNSサーバーの仕組みとか理解する必要あり、ココ適当にやってたから問題解決するのに毎回すごい時間かかった。。）
DNSSECというものがあるらしい。今後扱いたい。

以上