DNSサーバの役割を理解して、自分のサーバに必要な設定を理解しよう

ただDNSサーバを動作させるだけなら、解説に合わせて設定ファイルを書き換えるだけです。しかしそれでは偶然自分の環境に合った解説を見つけない限り、設定できません。また、環境の変化にも対応できません。
BINDの設定は複雑ではありませんが、仕組みを理解するとなると、かなり難易度が高くなります。

そのため今回は各種の設定について理解できる程度に、DNSサーバの役割を解説します。

DNSサーバと名前解決の仕組み

「特定のURLを入力すると、Webサイトが表示される」何気なく行われているWebページへのアクセスですが、裏側では世界中の「DNSサーバ」が連動して実現しています。この「DNSサーバ」が行う「IPアドレスとドメインを結びつける」ことを「名前解決」といいます。
それでは「名前解決」の仕組みを見ていきましょう。

1.まずブラウザで「http://example.com」へアクセスする。するとクライアント側から「リゾルバ」というプログラムを使ってDNSサーバへ問い合わせます。

2.問い合わせを受けたDNSサーバは「http://example.com」のIPアドレスは「192.168.0.1」だと教えてくれます。

3.クライアントはDNSサーバに教えて貰った「192.168.0.1」というサーバへアクセス。

4.目的のサーバから画像やhtmlファイルなどが、クライアントのブラウザに表示される。

このような流れで「名前解決」を行なっています。

ローカルネームサーバと権威ネームサーバのやり取り

上の例でクライアントがIPアドレスを問い合わせているのが「ローカルネームサーバ」です。このサーバはISP（インターネットサービスプロバイダー）などに設置されています。

問い合わせを受けたローカルネームサーバは、さらに上位のDNSサーバへ問い合わせます。ちなみにローカルネームサーバは、負荷軽減のため1度問い合わせた情報を一定期間キャッシュにして保持し、2度目からはキャッシュで応答します。

この上位のDNSサーバのことを「権威ネームサーバ」と呼びます。
「権威ネームサーバ」は負荷の分散と、ダウンした際の保険として、同じ情報を持つ複数のサーバ群で構成されています。
大本を「プライマリマスター」、コピーを「セカンダリマスター（またはスレーブ）」といいます。

権威ネームサーバの分散

先ほど「権威ネームサーバ」はアクセスの負荷を分散するために、大本の「プライマリマスター」と、コピーである「セカンダリマスター」で構成されていると解説しました。
他にも負荷を軽減する仕組みを持っていて、「権威ネームサーバ」は下のイラストのように階層構造になっています。

これはローカルネームサーバが権威サーバに「example.com」に関する問い合わせをした例です。

1.まずローカルネームサーバは最上位の「ルートネームサーバ」とよばれるDNSサーバに問い合わせを行います。
すると「ルートネームサーバ」は「com」を管理するサーバを教えてくれます。

2.「com」を管理するネームサーバに問い合わせると今度は「example.com」を管理するネームサーバを教えてくれます。

3.「example.com」を管理するネームサーバは「example.com」のIPアドレスは「192.186.0.1」だと教えてくれます。

このような階層構造にすることで、各DNSサーバは単純なやり取りだけを行えばよいため、負荷が軽減します。

正引きと逆引き

正引きについて

上の例で紹介した「example.com」のIPアドレスを問い合わせることを「正引き」または「順引き」といいます。

逆引きについて

それに対して「192.186.0.1」というIPアドレスからドメインを問い合わせることを「逆引き」といいます。

BIND DNSサーバの役割

大まかにDNSネットワークについて理解したところで、これから設定をする「BIND（バインド）」の役割について解説します。
「BIND」とは「Berkeley Internet Name Domain」の頭文字を取ったもので、自分のサーバを表す固定のIPアドレス（例：192.168.0.1）と、取得したホスト名（例：example.com）を関連付けるためのツール群です。
BINDは世界で最も利用されているDNSサーバソフトで、先ほど紹介したルートネームサーバも、多くはBINDで動作しています。

ゾーンファイルとリソースレコード

BINDでは「ゾーンファイル」と呼ばれるファイルに各種設定を記述していきます。（ゾーンとは管理する範囲のことです。）
「ゾーンファイル」には「リソースレコード」単位で記述をしていきます。それぞれの「リソースレコード」で指定する項目は以下のとおりです。

SOAレコード

ゾーンのドメイン名、ドメイン名に対して権威を持つプライマリネームサーバ、管理者のメールアドレス、ゾーンファイルのバージョンを表すシリアル番号、各ネームサーバにてキャッシュを保持する機関の指定

NSレコード（ネームサーバレコード）

「example.com」ドメインへ権威のあるネームサーバの指定、構築
通常片方がダウンしても機能が停止しないようにプライマリネームサーバ、セカンダリネームサーバを指定します。
（ns.example.comとns2.example.comなど）

Aレコード（アドレスレコード）

ホスト名に対応するIPアドレスの指定。
（example.comへのアクセスを192.168.0.1へ）

PTRレコード（ポインタレコード）

反対にIPアドレスからホスト名を指定
（192.168.0.1のホスト名はexample.comであると指定）

CNAMEレコード（キャノニカルネームレコード）

ホスト名の別名を指定
（ftp.example.comやwww.example.comもexample.comと同じ扱いにするなど）

MXレコード（メールエクスチェンジレコード）

メール配送先であるメールサーバの指定
（mail.example.comなど）

これらの設定を世界中のルートネームサーバへ転送することで、「ホスト名からIPアドレスを導き出す」という、「名前解決」が可能になります。

chroot化

これはBINDに限った話ではありませんが、DNSサーバなど外部から接続可能なソフトウェアは、脆弱性を突かれるとシステム全体が乗っ取られてしまうことがあります。もしもソフトを乗っ取られたとしても、被害をソフト内だけで留めるのが「chroot（チェンジルート）化」という技術です。

簡単に説明すると本来の「ルートディレクトリ（一番上のディレクトリ）」とは別に、個別のソフト用に「ルートディレクトリ」を作ります。そのため、「チェンジルート（ルートディレクトリを変更）」という名前が付いています。

本来のBINDのファイル構造（簡略化）

chroot化したBINDのファイル構造

このように「chroot化」することで、本来のetcディレクトリやvarディレクトリに保存された重要な情報の流出を防げます。
「chroot化」だけでセキュリティが万全とは言えませんが、DNSの脆弱性を利用した攻撃が連日のごとくニュースを賑わせている昨今、取れる施策は積極的に取り入れたほうが安心です。

これら煩雑な仕組みを一手に担ってくれるのが「BIND DNS サーバ」です。
ここに記載したのはBINDの機能の一部分だけで、他にも多くの機能をサポートしています。興味のある方は専門書や公式サイトにて確認してください。

BIND公式サイト

次回は「BIND DNS サーバの正引き用ゾーンファイルと、逆引き用ゾーンファイルの作成方法」です