前回はホスト名からIPアドレスを取得するための正引き情報設定を行ないました。今回はIPアドレスからホスト名を取得するための逆引き情報設定の方法について見ていきます。設定は逆引き用設定ファイルを編集することで行ないます。

まずは作成済みの逆引き用設定ファイルを見てみましょう。当ファイルはnamed.confのopionsステートメント「directory」で指定したディレクトリに、逆引き用zoneステートメントの「file」で指定したファイル名で作成します。

# vi webtest01.com.rev
$TTL    86400
@       IN      SOA     ns.webtest01.com. root.webtest01.com.(
                                2015123105  ; Serial
                                28800       ; Refresh
                                14400       ; Retry
                                3600000     ; Expire
                                86400 )
        IN      NS      ns.webtest01.com.
10      IN      PTR     ns.webtest01.com.
1       IN      PTR     pc01.webtest01.com.
2       IN      PTR     pc02.webtest01.com.
254     IN      PTR     router.webtest01.com.

上記を見てわかるように、$TTLディレクティブ、SOAレコードやNSレコードが表す意味は正引き用設定ファイルと同じです。今回は逆引き用のPTRレコードについて見ていきます。

PTRレコード

PTRレコードは逆引き(IPアドレスからホスト名を取得する)のための情報を記述します。1つのIPアドレスは1つの正規なホスト(ドメイン)名のみに対応させます。

10      IN      PTR     ns.webtest01.com.
1       IN      PTR     pc01.webtest01.com.
2       IN      PTR     pc02.webtest01.com.
254     IN      PTR     router.webtest01.com.

PTRレコードでこのDNSサーバーが管理しているドメインのIPアドレスとホスト名の対応を記述しています。ホスト名はFQDNで記述します。

上記レコードを追加することで、例えば、IPアドレス「172.16.0.1」に対する名前解決を要求されたときホスト名「pc01.webtest01.com.」が返されるようになります。

以上で逆引き用設定ファイルの編集は完了です。

今回は正引き用設定ファイルの編集方法について見ていきます。

前回作成したnamed.conf内で定義したゾーンごとに、正引き用設定ファイルを作成します。正引き用設定ファイルでは、ホスト名とIPアドレスの対応づけを定義します。

まずは作成済みの正引き用設定ファイルを見てみましょう。正引き用設定ファイルはnamed.confのopionsステートメント「directory」で指定したディレクトリに、正引き用zoneステートメントの「file」で指定したファイル名で作成します。

# vi /var/named/webtest01.com
$TTL      86400
@         IN       SOA     ns.webtest01.com.  root.webtest01.com.(
                                        2015123105 ; Serial
                                        28800      ; Refresh
                                        14400      ; Retry
                                        3600000    ; Expire
                                        86400 )    ; Minimum
          IN NS    ns.webtest01.com.
          IN MX 10 mail.webtest01.com.
localhost IN A     127.0.0.1
ns        IN A     172.16.0.10
pc01      IN A     172.16.0.1
pc02      IN A     172.16.0.2
router    IN A     172.16.0.254

正引き用設定ファイルに登録するエントリーには、ディレクティブと資源(リソース)レコードの2種類があります。

ディレクティブ

ディレクティブは、ネーム サーバーの制御情報、およびゾーンごとのオプションを記述します。行頭がドル記号($)で始まり、その後にディレクティブの名前が続きます。

$ORIGIN

修飾指定のないレコードに付加するドメイン名を指定します。通常、$ORIGINディレクティブは省略されます。省略した場合は、zoneステートメントで指定したドメイン名(この例では「webtest01.com.」)が、$ORIGINディレクティブ値として適用されます。また、$ORIGINディレクティブに設定した値そのものを名前として利用する場合、「@」で置き換えることができます。

$TTL

$TTLディレクティブでは、当該ゾーンの各レコードの寿命(Time To Live)の値を秒単位で指定します。ここで設定した値が資源レコードの有効期間として応答メッセージ中に含まれ、応答メッセージを受信したサーバーはTTLで定められた期間、得られた情報をキャッシュします。そのため、プライマリDNSサーバー側で何らかの変更を行なった場合、すぐには反映されず、最大$TTLディレクティブで指定した時間、他のDNSサーバーに更新が反映されない可能性があります。

資源(リソース)レコード

ホスト名とIPアドレスを対応づけるための定義を記述します。
SOA、NS、Aなどの「レコード」と呼ばれる単位で記述していきます。レコードには以下のような種類があります。

レコード	意味
SOA	ドメイン自体に関する情報
NS	DNSサーバーの情報
A	正引きの情報
MX	メールサーバーの情報
CNAME	ホストの別名
PTR	逆引きの情報

SOAレコード

SOAは「Start Of Authority」の略です。直訳のとおり、権威のあるゾーンの定義を開始することを意味します。ゾーン(ドメイン)定義を宣言するレコードと考えればわかりやすいでしょう。
SOAレコードはルートゾーン用の正引き用設定ファイル(named.ca)以外のファイルで必要であり、1つのファイル中で有効なSOAレコードは1つのみとなります。SOAレコードは、ディレクティブの直後かつ資源レコードの先頭に記述します。

@         IN       SOA     ns.webtest01.com.  root.webtest01.com.(
                                        2015123105 ; Serial
                                        28800      ; Refresh
                                        14400      ; Retry
                                        3600000    ; Expire
                                        86400 )    ; Minimum

複数行にわたっていますが上記がSOAレコードの記述になります。まずはSOAレコードから見ていきます。

項目	設定値	内容
名前	@	$ORIGINディレクティブに設定した値を示す。$ORIGINディレクティブを省略した場合は、zoneステートメントで指定したドメイン名(この例では「webtest01.com.」)となる。「@」の代わり に、ゾーン名をそのまま書くことも可能。
クラス	IN	インターネットであることを表す「IN」を指定。
レコードの種類	SOA	本レコードがSOAレコードであることを示す。
MNAME	ns.webtest01.com.	本ゾーンのプライマリーDNSサーバーをFQDNで指定。(末尾の「.」は必須)
RNAME	root.webtest01.com.	本ゾーンの管理者メールアドレスをFQDNで指定。
Serial	2015123105	ゾーン情報のシリアル番号(バージョン)を指定。ゾーン情報を更新する場合はこの値を加算する。
Refresh	28800	セカンダリDNSサーバー(スレーブ)がゾーン情報の更新の有無(「SERIAL」の増加)をチェックする周期を秒単位で示す数値を指定。
Retry	14400	Refreshでゾーン情報の更新ができなかった場合の再試行周期を秒単位で指定。Retryで指定された時間後に再度リフレッシュを試みる。
Expire	3600000	何らかの理由でゾーン情報のリフレッシュができない状態が続いた場合、セカンダリDNSサーバーが持っているデータをどれだけの時間利用してもよいかを秒単位で指定。
Minimum	14400	各資源レコードのデフォルトのTTL(Time To Live=有効期間)を秒数で指定。

「Minimum」でTTL(有効期間)を指定していますが、前述の$TTLディレクティブで指定してした設定と内容がかぶっているように見えます。ただ実際は、両者が意味する内容は異なります。

TTLは、DNS問い合わせに成功したものをキャッシュ(ポジティブキャッシュ)する時間とDNS問い合わせを受けたがドメインが存在しない等の理由で失敗した結果をキャッシュ(ネガティブキャッシュ)する時間の2つのタイプに分かれます。

ポジティブキャッシュとネガティブキャッシュそれぞれの性質を考えると、同じTTLの値を使用するのはあまり都合よくありません。

そこで、BIND 8.2以降ではSOAレコードにあるTTL(Minimum)の値をネガティブキャッシュ用とし、新たに$TTLディレクティブを設けて各資源レコードのデフォルトTTLの値を指定するようにされました。また、各資源レコード内でもTTLを定義することが可能で、$TTLディレクティブの値を上書きすることができます。これにより、例えば、変更を予定しているホストに関しては、個別にTTL値を短くするなどの対応を取ることができます。

NSレコード

NSレコードには、自身が管理しているゾーンのDNSサーバーのFQDNを記述します。DNSサーバーが複数ある場合は、その数だけNSレコードが必要になります。

          IN NS    ns.webtest01.com.

NSレコードは必ず記述する必要があります。本レコードでは行頭の「名前」を省略しています。この場合、直前のレコードに利用したものを指定したことになります。つまりここではSOAレコードで指定した「@」が指定されます。

MXレコード

MXレコードには、メールサーバーのアドレスと優先順位を記述します。

          IN MX 10 mail.webtest01.com.

優先順位は数値が低いほど高く、優先順位の高いメールサーバーが停止したときに、低いサーバーをバックアップ用として利用します。上記サンプルでは1台分のみ定義し、優先順位を10としています。

Aレコード

Aレコードには、正引き(ホスト名からIPアドレスを取得する)のための情報を記述します。

localhost IN A     127.0.0.1
ns        IN A     172.16.0.10
pc01      IN A     172.16.0.1
pc02      IN A     172.16.0.2
router    IN A     172.16.0.254

AレコードでこのDNSサーバーが管理しているドメインのホスト名とIPアドレスの対応を記述しています。ドメイン名は省略しても構いません。

これで例えば、ホスト名「pc01.webtest01.com.」に対する名前解決を要求されたときIPアドレス「172.16.0.1」が返されるようになります。

以上で正引き用設定ファイルの編集は完了です。次回は逆引き用設定ファイルの編集方法について見ていきます。

BINDをインストールするには、ソースアーカイブをダウンロードしてビルドする方法と、バイナリパッケージを利用する方法があります。

通常はパッケージ管理ユーティリティ(yumやrpm等)を利用できるバイナリパッケージをインストールします。

ここではyumを使用して、BINDをインストールします。以前はcaching-nameserver(キャッシュネームサーバー)というパッケージがあり、それも併せてインストールする必要がありましたが、最新バージョンのBINDでは左記パッケージも含まれるようになったため、インストールは不要です。caching-nameserverは、1度問い合わせを行うと一定期間、その結果をローカルに記憶しておきます。

# yum -y install bind
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
 * base: ftp.iij.ad.jp
 * extras: ftp.iij.ad.jp
 * updates: ftp.iij.ad.jp
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package bind.i686 32:9.8.2-0.17.rc1.el6_4.6 will be installed

～　省略　～

Installed:
  bind.i686 32:9.8.2-0.17.rc1.el6_4.6

Dependency Installed:
  portreserve.i686 0:0.0.4-9.el6

Dependency Updated:
  bind-libs.i686 32:9.8.2-0.17.rc1.el6_4.6
  bind-utils.i686 32:9.8.2-0.17.rc1.el6_4.6

Complete!

以上でBINDのインストールは完了です。yumを使用すると上記のようにインストールは簡単に行なえます。

次回からはBINDの設定方法について見ていきます。

今回からはDNSサーバーを構築していきます。構築する前にまずは前提となる基礎知識から見ていきます。

DNSとは

DNS(Domain Name System)とは、インターネットなどのTCP/IPネットワーク上でホスト名やドメイン名とIPアドレスの対応関係を管理するシステムのことです。

つまり、一言で表すと「インターネットにおける電話帳のようなもの」です。

例えば、Googleにアクセスしたいとき、実アドレスである74.125.153.103をブラウザのアドレスバーに打ち込む人はいないと思います。「google.jp」または「google.co.jp」などと入力するはずです。
クライアントはこの名前をDNSサーバーに問い合わせ、対応するIPアドレスを取得・接続します。その結果、ユーザーはWebサイトの実アドレスを意識せずコンテンツを閲覧できるというわけです。

ホスト名もしくはドメイン名からIPアドレスへ変換することを名前解決と言います。

問い合わせを出すソフトウェアを「リゾルバ」と言い、その問い合わせに返信するのが「DNSサーバー」となります。

FQDNとは

「ホスト名」や「ドメイン名」といった用語についても整理しておきます。

ドメイン名とは、ネットワーク内にあるコンピュータや機器(ホスト)の所属を表すものです。そのドメインの中からひとつのホストを表すものがホスト名です。

FQDN(Fully Qualified Domain Name)とは、ホスト名、ドメイン名（サブドメイン名）などすべてを省略せずに指定した記述形式のことです。例えば、FQDN「www.yahoo.co.jp.」は、ホスト名「www」、ドメイン名「yahoo.co.jp」という関係になります。

なお、FQDNを正確に記述する場合、一番右端に「.（ピリオド）」を付ける必要があります。このピリオドは、ルート・ノードを示していますが、省略されることがほとんどです。

BINDとは

BINDとは、最も広く普及しているDNSサーバーソフトウェアの一つです。

Windows Serverに含まれるMicrosoft DNSサーバーなどもありますが、BINDはDNSサーバー実装の事実上の標準として幅広く使われています。

BINDの特徴として以下が挙げられます。

• DNSサーバー実装の事実上の標準
• DNSの仕様として規定されているほとんどの機能を実装しており高機能
• サーバー向けOSパッケージなどでは標準のDNSサーバーとして同梱されている
• オープンソースソフトウェアとして公開されており、誰でも自由に入手、利用、改変、再配布などが可能

設定が複雑で導入・管理が比較的難しいことや、広く普及していることもあり攻撃の標的となりなすいなどの面もあります。

Apacheなどと同じでデーモン(常駐プログラム)として動作し、プロセス名は「named」となります。

DNSの名前解決方法

DNSの名前解決方法には「再帰問い合わせ」と「反復問い合わせ」の2種類があります。

再帰問い合わせ	リゾルバからの問い合わせを受けたDNSサーバーが、他のDNSサーバーに問い合わせを行いその最終的な結果をリゾルバに応答する問い合わせのこと。
反復問い合わせ	リゾルバから再帰問い合わせを受けたDNSサーバーが、再帰問い合わせの結果を返すために、答えを得られるまで繰り返し他のDNSサーバへ行う問い合わせのこと。

例えば、WebブラウザにURLを入力し、あるWebサイトを表示しようとした場合、Webブラウザに実装されるリゾルバがDNSサーバーに名前解決を依頼します。

パソコンのリゾルバが出した問い合わせは、最終的な答えを要求するタイプであり、再帰問い合わせを行ないます。再帰問い合わせを受け取ったDNSサーバーは、自分で調べて答えを返信しなければなりません。

これに対して上図で言う社内DNSサーバーのリゾルバが出した問い合わせは、必ずしも最終的な答えを要求するものではありません。もし、問い合わせたDNSサーバーが答えを知らなかったら、知ってそうな別のDNSサーバーのIPアドレスを教えてもらいます。この問い合わせを繰り返すことで、最後に答えを知っているDNSサーバーにたどり着くというわけです。このような問い合わせを反復問い合わせといいます。

DNSフォワーダ

フォワーダ機能を使用すると、自身のDNSで解決できない問い合わせをフォワーダに指定したDNSサーバーに転送することができます。
例えば、外部に公開したくない社内専用のDNSサーバーがあったとします。その社内専用DNSサーバーが答えられない名前解決の問い合わせが来た場合、外部へ抜けられるDNSサーバーへその問い合わせを転送してやります。あとは、転送先のDNSサーバーが答えを返してくれるのを待ち、返ってきたら、自身が受けた問い合わせ元へ結果を返してやるという仕組みです。

フォワーダの指定先は一般的にプロバイダのDNSサーバーになります。なお、フォワーダを指定しない場合は、自身が知っている範囲でしか応えられません。