Introduction

DNS (Domain Name System) は、Web サイトやサーバーの構成方法を学ぶ際に、正しく理解するのが難しいコンポーネントであることがよくあります。 ほとんどの人は、ホスティング会社またはドメイン登録者によって提供される DNS サーバーを使用することを選ぶでしょうが、独自の DNS サーバーを作成することにはいくつかの利点があります。

このガイドでは、Ubuntu 14.04 マシンに Bind9 DNS サーバーを権威のみの DNS サーバーとしてインストールおよび構成する方法について説明します。 これらを、プライマリ/セカンダリ構成でドメイン用に 2 つの Bind サーバーを設定します。

前提条件と目標

このガイドを完了するには、まず、いくつかの一般的な DNS 用語に精通している必要があります。 このガイドで実装する概念については、このガイドを参照してください。

また、少なくとも 2 つのサーバーが必要です。 1つはドメインのゾーンファイルを生成する「プライマリ」DNSサーバ、もう1つは転送によってゾーンデータを受け取り、もう1つのサーバがダウンした場合に利用できる「セカンダリ」サーバになります。

キャッシュまたは転送DNSサーバーや多目的DNSサーバーとは異なり、認証専用サーバーは、認証しているゾーンの反復クエリにのみ応答します。 これは、サーバーが答えを知らない場合、クライアント (通常は何らかの解決 DNS サーバー) に答えを知らないことを伝え、より多くを知っているかもしれないサーバーへの参照を与えるだけであることを意味します。

認証専用 DNS サーバーは、クライアントからの再帰クエリを解決するオーバーヘッドがないため、高いパフォーマンスにとって良い構成であることがよくあります。 このガイドの目的では、実際には3つのサーバーを参照することになります。 前述の2つのネームサーバーと、ゾーン内のホストとして構成したいWebサーバーです。

このガイドでは、ダミードメインexample.comを使用します。 設定するドメインに置き換えてください。 以下は、設定するマシンの詳細です：

目的	DNSのFQDN	IPアドレス
一次ネームサーバー	ns1.NAS	FQDN	IPアドレス	192.0.2.1
セカンダリネームサーバ	ns2.Secondary(1)(2)(3)(4)(5)(6)(7)です。example.com.	192.0.2.2
Web Server	www.example.com.	192.0.2.3

このガイドが完了したら、ドメインゾーンに設定された2つの権威のみのネームサーバーを持っていなければなりません。 上の表の中央の列の名前は、あなたの様々なホストに到達するために使用することができるようになります。 この構成を使用して、再帰的DNSサーバーは、ドメインに関するデータをクライアントに返すことができます。

ネームサーバー上のホスト名の設定

ネームサーバーの構成に入る前に、ホスト名が主および副DNSサーバーの両方で適切に構成されていることを確認する必要があります。 sudo 権限でファイルをテキストエディタで開きます。

sudo nano /etc/hosts

各サーバーのホスト名と FQDN を正しく識別するように、これを設定する必要があります。 プライマリ・ネーム・サーバーでは、このファイルは最初は次のようになります：

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

2行目を修正して、特定のホストとドメインの組み合わせを参照し、これを公開の固定IPアドレスに向ける必要があります。 そして、最後に未修飾名をエイリアスとして追加することができます。 この例のプライマリ サーバーでは、2 行目を次のように変更します:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

終了したら、ファイルを保存して閉じます。

また、非限定ホスト名を含むように /etc/hostname ファイルを変更します:

sudo nano /etc/hostname

ns1

この値は、現在実行中のシステムで読み取り、次のようにタイプします:

sudo hostname -F /etc/hostname

2 次サーバーの同じ手順を実行したいと思います。

/etc/hosts ファイルから開始します。

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

終了したら、ファイルを保存して閉じます。

次に、/etc/hostname ファイルを修正します。 このファイルでは、実際のホスト (この例では ns2) のみを使用することを忘れないでください:

sudo nano /etc/hostname

ns2

もう一度、現在のシステムを修正するためにファイルを読みます:

sudo hostname -F /etc/hostname

これで、サーバーのホスト定義が正しく設定されたはずです。

両方のネーム サーバーに Bind をインストールする

ネーム サーバーのそれぞれに、これから使用する DNS サーバーである Bind をインストールすることができました。 また、ドキュメントといくつかの一般的なユーティリティも含めます。

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

適切なファイルを取得するために、プライマリとセカンダリの DNS サーバーでこのインストール コマンドを実行します。

Configure the Primary Bind Server

ソフトウェアをインストールしたので、プライマリ サーバー上の DNS サーバーを設定することから始めます。

Configuring the Options File

始めるにあたって最初に設定するのは named.conf.options ファイルです。

Bind DNS サーバーは named という名前でも知られています。 主な設定ファイルは /etc/bind/named.conf にあります。 このファイルは、実際に設定する他のファイルを呼び出します。

エディタで sudo 権限でオプション ファイルを開きます:

sudo nano /etc/bind/named.conf.options

以下では、簡潔にするためにコメント行をほとんど削除していますが、一般に、インストール後はこのようになります:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

このファイルで設定する必要があるのは主に再帰性です。 ここでは権威のみのサーバをセットアップしようとしているので、このサーバでは再帰を有効にしたくありません。

また、転送を許可しないことをデフォルトにするつもりです。

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

終了したら、ファイルを保存して閉じます。

ローカルファイルの設定

次に必要なステップは、このサーバーを制御するゾーンを指定することです。

私たちはexample.comドメインを構成しており、他のサーバーにドメインの任意の部分の責任を再委託するつもりはありません。

ゾーンを設定するには、sudo 権限で /etc/bind/named.conf.local ファイルを開く必要があります。

sudo nano /etc/bind/named.conf.local

このファイルは、最初はコメント以外の何もない状態になっています。 一般的な管理のためにサーバーが知っている他のゾーンがありますが、これらは named.conf.default-zones ファイルで指定されます。

最初に、example.com ドメインの転送ゾーンを構成する必要があります。 フォワードゾーンは、DNSについて議論するときにほとんどの人が思い浮かべる、従来の名前からIPへの解決策です。

zone "example.com" {};

注意：多くのDNSツール、その設定ファイル、およびドキュメントでは、”マスター “と “スレーブ “という用語を使用していますが、DigitalOceanは一般的に別の記述子を好んで使用します。 混乱を避けるために、我々はサーバー間の関係を示すために “プライマリ “と “セカンダリ “という用語を使用することを選択し、設定指令がそれを必要とする場合にのみ “マスタ “または “スレーブ “を使用します。

このブロックの内部に、このゾーンに関する管理情報を追加しています。 このDNSサーバとゾーンとの関係を指定する。 このマシンをすべてのゾーンのプライマリネームサーバとして構成しているので、 この後のサンプルゾーンではtype master;となっている。

我々は、Bind設定ディレクトリ内のzonesというサブディレクトリに プライマリゾーンファイルを保持するつもりである。 Bindディレクトリ内の他のゾーンファイルから慣習を借用するために、我々のファイルをdb.example.comと呼ぶことにする。 ブロックは次のようになります：

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

このゾーンがセカンダリサーバーに転送されるようにしたいので、次のような行を追加する必要があります：

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

次に、ドメインのリバースゾーンを定義するつもりです。

リバース ゾーンについて

IPアドレスを与えた組織がネットワーク範囲を与えず、その範囲の責任を委任した場合、リバース ゾーン ファイルは参照されず、組織自体によって処理されます。

ホスト プロバイダでは、リバース マッピングは通常会社自体によって処理されます。 たとえば、DigitalOcean では、コントロール パネルでマシンの FQDN をサーバー名として使用すると、サーバーのリバース マッピングが自動的に作成されます。 例えば、このチュートリアルのリバースマッピングは、次のようなサーバ名で作成されます：

このような場合、管理するアドレスの塊を割り当てられていないため、この戦略を使用する必要があります。 以下に概説する戦略は、完全を期すため、および、連続したアドレスのより大きなグループの制御を委任された場合に適用できるようにするために網羅されています。 しかし、ドメインネームシステムはもともと順方向のマッピングのために設計されたので、逆方向のマッピングを可能にするためにこれを適応させるためには、いくつかの考えが必要です。 IPアドレスの場合、最も具体的な部分は右側です。

ドメインの仕様で最も具体的な部分は、サブドメインまたはホスト名です。 これはドメインのゾーンファイルで定義されます。

各サブドメインは、順番に、より多くのサブドメインまたはホストを定義できます。

すべてのリバースゾーンマッピングは、インターネット番号割り当て機関（IANA）によって制御されている特殊ドメインin-addr.arpaで定義されています。 このドメインの下には、IPアドレスの各オクテットをマッピングするためにサブドメインを使用するツリーが存在します。 IPアドレスの特異性が通常のドメインと同じになるように、IPアドレスのオクテットは実際には逆になっています。

つまり、IPアドレスが192.0.2.1のプライマリDNSサーバーは、1.2.0.192と反転して表示されることになります。 このホスト指定をin-addr.arpaドメインの下に存在する階層として追加すると、特定のホストは1.2.0.192.in-addr.arpaとして参照できる。

DNSの使用時には、ゾーンファイル自体の中で個々のホスト（ここでは先頭の「1」のように）を定義するので、設定するゾーンは2.0.192.in-addr.arpaとなる。

リバースゾーン名の指定方法はわかりましたが、実際の定義はフォワードゾーンと全く同じです。 example.com ゾーン定義の下に、与えられたネットワーク用のリバースゾーンを作成する。 繰り返しますが、これはおそらくアドレスブロックの制御を委任された場合にのみ必要です:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

ファイル名をdb.192.0.2としました。

Forward Zone Fileの作成

現在、BindにForwardとReverseのゾーンについて伝えていますが、これらのゾーンを定義するファイルをまだ作成していません。

sudo mkdir /etc/bind/zones

ここで、Bindディレクトリにある既存のゾーンファイルのいくつかを、作成したいゾーンファイルのテンプレートとして使用することができます。 フォワードゾーンの場合、db.localファイルが必要なものに近いでしょう。 そのファイルをnamed.conf.localファイルで使用されている名前でzonesサブディレクトリにコピーします。

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

これを行う間に、リバースゾーンのテンプレートもコピーできます。

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

次に、テキスト エディターで sudo 権限を使用してフォワード ゾーン ファイルを開きます。

私たちはlocalhost.をこのマシンのFQDN名に置き換える必要があります。 レコードのこの部分は、定義されるゾーンに対して権威を持って応答する あらゆるネームサーバーを定義するために使用される。 これは現在設定中のマシン、この例ではns1.example.com.となる(末尾のドットに注目。 これは、このエントリーを正しく登録するために重要である!）

また、次の部分を変更したいと思います。これは実際には、@をドットに置き換えた、特別にフォーマットされた電子メールアドレスです。 私たちは電子メールをドメインの管理者に送りたいので、従来の電子メールは [email protected] です。 これを翻訳すると、admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

次に編集する必要があるのは、シリアル番号です。 シリアル番号の値は、Bindがセカンダリサーバに更新情報を送信する必要があるかどうかを判断する方法です。

注意: シリアル番号を増加させないことは、ゾーン更新の問題につながる最も一般的な間違いの1つです。 編集を行うたびに、シリアル番号を増加させなければなりません。

一つの一般的な方法は、番号を増加させるための規約を使用することです。 1 つのアプローチは、最後に追加された日のリビジョン番号と一緒に YYYYMMDD フォーマットの日付を使用することです。 つまり、2014年6月5日に行われた最初のリビジョンは2014060501というシリアル番号を持ち、その日のうちに行われたアップデートは2014060502というシリアル番号を持つ可能性があります。

使いやすさのために規約を採用する価値はありますが、このデモでは物事をシンプルに保つために、今のところ 5 に設定します。

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

次に、独自のものを作成するので、ファイルの最後の 3 行 (@ で始まる下部の行) を削除してください。

SOAレコードの後に確立したい最初のものは、ゾーンのネームサーバーです。 ドメインと、そのゾーンの権威となる2つのネームサーバーを、名前で指定する。 これらのネームサーバーはドメイン自体の中のホストであるため、少し自己参照的に見えるでしょう。

このガイドの場合、以下のようになります。 繰り返しになりますが、最後のドットに注意してください！:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

ゾーンファイルの目的は主にホスト名とサービスを特定のアドレスにマップすることなので、まだ終わりではありません。

次に、これらのネームサーバー名とネームサーバーの実際のIPアドレスを関連付けるAレコードを作成する必要があります。 私たちのホストの1つに、私たちのサイトを提供するために使用したいWebサーバーがあることを思い出してください。 一般的なドメイン（この例ではexample.com）に対するリクエストをこのホストに向け、wwwホストに対するリクエストもこのホストに向けることになります。 これは次のようになります:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

あなたが定義する必要がある追加のホストは、追加のAレコードを作成することによって追加することができます。

終了すると、ファイルは次のようになります:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

終了したら、ファイルを保存して閉じます。

リバースゾーンファイルの作成

さて、フォワードゾーンは設定されましたが、設定ファイルで指定したリバースゾーンファイルを設定する必要があります。

sudo権限でテキストエディタでファイルを開きます:

sudo nano db.192.0.2

ファイルは次のようになります:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

順方向ゾーンで行ったのとほぼ同じ手順を実行します。 まず、ドメイン名、管理者メールアドレス、およびシリアル番号を、前回のファイルと正確に一致するように調整します（シリアル番号は異なっていてもかまいませんが、増加させる必要があります）:

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

もう一度、SOAレコードの閉じ括弧の下の行を消去します。 ネットワーク範囲内の各IPアドレスの最後のオクテットを取得し、PTRレコードを使用してそのホストのFQDNにマッピングする予定です。 各IPアドレスは、一部のソフトウェアでの問題を避けるために、単一のPTRレコードのみを持つべきです。したがって、逆マップするホスト名を選択する必要があります。

たとえば、メールサーバーを設定している場合、多くのシステムがアドレスを検証するために逆マップを使用するので、おそらくメール名への逆マップを設定したいと思います。

最初に、ネーム サーバーを再度設定する必要があります。

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

次に、参照している IP アドレスの最後のオクテットを使用して、返したい完全修飾ドメイン名をポイントバックします。 この例では、次のように使用します：

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

終了すると、ファイルは次のようになります：

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

終了したら、ファイルを保存して閉じます。

ファイルのテストとサービスの再起動

プライマリ サーバーの構成はこれで完了ですが、まだ変更を実装する必要があります。

サービスを再起動する前に、すべての構成ファイルをテストして、正しく構成されていることを確認する必要があります。

最初に、named-checkconf コマンドを使用して named.conf.local および named.conf.options ファイルをチェックできます。

sudo named-checkconf

これが何のメッセージもなく返された場合、named.conf.local および named.conf.options ファイルは構文的に有効であることを意味します。

次に、named-checkzone コマンドにゾーンが処理するドメインとゾーン ファイルの場所を渡すことによって、個々のゾーン ファイルをチェックすることができます。

sudo named-checkzone example.com /etc/bind/zones/db.example.com

ファイルに問題がない場合、正しいシリアル番号を読み込んだことを伝え、「OK」メッセージを表示します。 通常、メッセージはどの部分が無効であるかについて、かなり詳細に記述されています。

in-addr.arpaアドレスとファイル名を渡すことで、リバースゾーンを確認することができます。 このデモでは、次のように入力します:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

再び、正しいシリアル番号を読み込むことについて同様のメッセージを表示します:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

すべてのファイルがチェックアウトされていれば、Bind サービスを再起動できます:

sudo service bind9 restart

ログを確認するには、次のように入力します：

sudo tail -f /var/log/syslog

このログを見て、エラーがないことを確認します。

Configure the Secondary Bind Server

プライマリ サーバーの設定が完了したので、セカンダリ サーバーを設定することができます。

Configuring the Options File

ここでも、named.conf.options ファイルから開始します。

sudo nano /etc/bind/named.conf.options

このファイルに対して、プライマリ サーバーのファイルに行ったのとまったく同じ変更を行います。

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

終了したら、ファイルを保存して閉じます。 sudo権限でテキストエディタで開きます。

sudo nano /etc/bind/named.conf.local

ここで、プライマリサーバーで行ったように、各ゾーンの仕様を作成します。 ただし、値や一部のパラメータは異なります。

まず、フォワードゾーンを作成します。

zone "example.com" {};

今回は、このサーバがこのゾーンのセカンダリとして動作しているため、typeをslaveに設定するつもりです。 これは単に、ローカルシステム上のファイルではなく、転送によってゾーンファイルを受け取ることを意味する。 さらに、ゾーンファイルへの絶対パスの代わりに相対ファイル名を指定するだけである。

この理由は、セカンダリゾーンの場合、Bindはファイルを/var/cache/bindに格納するからである。

Forward Zoneの場合、これらの詳細は以下のようになる:

zone "example.com" { type slave; file "db.example.com";};

最後に、allow-transfer指示文の代わりに、このサーバがゾーン転送を受け入れる主サーバをIPアドレスで指定することになる。 これは、masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

というディレクティブで行う。

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

終了したら、ファイルを保存して閉じます。

ファイルのテストとサービスの再起動

前述のように、このサーバはプライマリサーバからゾーンファイルを受信するので、実際には、セカンダリマシンで実際のゾーンファイル作成は一切行う必要はありません。

もう一度、設定ファイルの構文を確認します。 チェックするゾーンファイルがないので、named-checkconfツールを使用するだけです。

sudo named-checkconf

これがエラーなしで返された場合、変更したファイルに構文エラーがないことを意味します。

この場合、Bindサービスを再起動できます。

sudo service bind9 restart

プライマリとセカンダリの両方のサーバーのログを、

sudo tail -f /var/log/syslog

ゾーンファイルが正しく転送されたことを示すいくつかのエントリが表示されるでしょう。

これを行うには、ドメイン名を購入した Web サイトに移動する必要があります。 インターフェイスとおそらく用語は、使用したドメイン名レジストラによって異なるでしょう。

ドメインの設定で、使用するネームサーバーを指定するオプションを探します。

レジストラは、NSレコードの使用によりゾーンの権限を単に委譲するのではなく、グルーレコードを作成する必要があります。 グルーレコードとは、権限を委譲するネームサーバーを指定した後に、そのネームサーバーのIPアドレスを指定するAレコードです。

通常、委譲はドメインの権限を処理するネームサーバーをリストするだけですが、ネームサーバーがドメイン自体の中にある場合、親ゾーンのネームサーバーに対してAレコードが必要です。 これが起こらない場合、DNS リゾルバは、委任のパスをたどるためにドメインのネームサーバーの IP アドレスを見つけることができないので、ループにはまり込んでしまいます。

そこで、ネームサーバーとその IP アドレスを指定できるドメイン登録機関のコントロールパネルのセクションを見つける必要があります。

デモンストレーションとして、登録機関の Namecheap には 2 つのネームサーバーのセクションがあります。

「ネームサーバー登録」というセクションがあり、ドメイン内のネームサーバーの IP アドレスを指定できます。

内部では、ドメイン内に存在するネームサーバーの IP アドレスを入力できます。

これを行った後、アクティブなネーム サーバーをドメインのサーバーに変更することができるはずです。 NameCheap では、[Domain Name Server Setup] メニュー オプションを使用して行います:

ここで、サイトの権威サーバーとして追加したネーム サーバーを使用するように指示できます:

変更は伝播するのにしばらくかかるかもしれませんが、ほとんどのレジストラでは 24-48 時間以内にネーム サーバーのデータが使用されていることが確認できるはずです。

まとめ

これで、ドメインをサーバーするために、2 つの権威のみの DNS サーバーが構成されたはずです。 これらは、さらにドメインを取得したときに、追加ドメインのゾーン情報を格納するために使用できます。

独自のDNSサーバーを構成および管理することで、DNSレコードがどのように処理されるかを最も制御することができます。 あなたは変更を加えることができ、DNSデータのすべての関連する部分がソースで最新であることを確認することができます。 他のDNSソリューションでは、このプロセスを容易にすることができますが、選択肢があることを知り、よりパッケージ化されたソリューションで何が起こっているかを理解することが重要です。