この章では、DNS (Domain Name System) ネームサーバーを設定する方法について説明します。
DNS サーバーを設定する手順は次のとおりです。
サーバーを DNS クライアントとして設定します (サーバーの resolv.conf ファイルの設定も含む)。
詳細は、第 12 章「DNS クライアントの設定」を参照してください。
ブートファイルを設定します。
詳細は、「ブートファイルの設定」を参照してください。
データファイルを設定します。
詳細は、「データファイルの設定」を参照してください。次の 4 つのデータファイルを設定する必要があります。
詳細は、「named.ca ファイルの設定」を参照してください。
詳細は、「hosts ファイルの設定 」を参照してください。
詳細は、「hosts.rev ファイルの設定 」を参照してください。
詳細は、「named.local ファイルの設定」を参照してください。
サーバーの初期設定を行います。
詳細は、「サーバーの初期設定」を参照してください。
サーバーをテストします。
詳細は、「設定の確認」を参照してください。
DNS の最も一般的な役割は、ローカルなネットワークをグローバルなインターネットに接続することです。そして、インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。誰が管理するのかは、ネットワークの地理的な位置と、親ドメインの種類によって異なります。ドメイン管理者にネットワークを登録してもらう方法については、本書では説明していません。
in.named デーモンを正しく機能させるには、1 つのブートファイルと 4 つのデータファイルが必要です。
この例で使われている IP アドレスとネットワーク番号、および本書で使われているサンプルコードは、説明に具体性を持たせるために仮に決めたものです。実際のネットワークやホストに使われていることがありますので、それらをそのまま使うのは避けてください。
マスターサーバーのブートファイルは、/etc/named.boot. です (「ブートファイルの設定」を参照)。ブートファイルには、ドメイン名と、ホスト情報が含まれているファイル名が記述されています (named.boot ファイルの詳細は、『Solaris ネーミングの管理』 を参照)。
内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。この柔軟性のために他のサイトで作業をしたり、DNS 間連の他のマニュアルなどを参照する場合に、混乱するかもしれません。
たとえば、Sun のマニュアルや大多数の Solaris サイトで使われているファイル名は、『DNS and BIND』(Paul Albeltz & Criclcet Liu 著、浅羽登志也/上水流由香監訳 、アスキー出版局、1995年) で使われているファイル名とは異なります。そしてこれら 2 派の命名方法は、『Name Server Operations Guide for BIND』(カリフォルニア州立大学刊、ハブリックドメイン) の命名方法とも若干の相違があります。
さらに、本書とその他の DNS ドキュメンテーションでは、説明にはファイルの主な役割を表す総称名を使い、レコード例には具体的な固有の名前を使っています。たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能や役割を説明する場合は hosts という総称名を使い、例では db.doc や db.sales といった名前を使っています。
参考のため、表 13-1 でこれら 3 派の BIND ファイル名を比較します。
表 13-1 ファイル名
Solaris |
O'Reilly その他 |
カリフォルニア州立大学バークレイ校 |
ファイルの内容と役割 |
---|---|---|---|
/etc/named.boot |
/etc/named.boot |
/etc/named.boot |
ブートファイル。稼動させるサーバーの種類と制御対象のゾーンを指定する。ドメイン名とデータファイル名が記述されている |
/etc/resolv.conf |
/etc/resolv.conf |
/etc/resolv.conf |
各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す |
named.ca |
db.cache db.root |
root.cache |
ルートサーバー名とそのアドレスがリストされている |
総称名: hosts 例: db.doc db.sales |
総称名: db.domain 例: db.movie db.fx |
総称名: hosts 例: ucbhosts |
サーバーがサービスを提供するローカルゾーン内のマシンに関する全データが格納されている |
総称名: hosts.rev 例: doc.rev |
総称名: db.ADDR 例: db.192.249.249 db.192.249.253 |
総称名: hosts.rev |
逆変換 (アドレスから名前への変換) が可能な特殊ドメイン in-addr.arpa. 内のゾーンを指定する |
named.local |
総称名: db.cache 例: db.127.0.0 |
named.local |
ローカルループバックインタフェース (local host) 用のアドレスを指定する |
$INCLUDE ファイル |
$INCLUDE ファイル |
$INCLUDE ファイル |
データファイル内の $INCLUDE() ステートメントによって識別されるファイル |
必要なデータファイルは次の 4 種類あります。
/var/named/named.ca
named.ca ファイルの詳細は、「named.ca ファイルの設定」、および『Solaris ネーミングの管理』を参照してください 。内部で一貫性さえとれていれば、このファイルには何でも好きな名前を付けることができます。
/var/named/hosts
hosts ファイルの詳細は、「hosts ファイルの設定 」、および『Solaris ネーミングの管理』を参照してください。
hosts はファイルの目的や中身を表す総称名です。しかし、/etc/hosts との混乱を避けるため、このファイルには hosts 以外の名前を付けることをお勧めします。最も一般的な名前の例は、db.domainname です。たとえば、doc.com ドメインにある hosts ファイルであれば、その名前は db.doc となります。
ゾーンがいくつかに分かれている場合、各ゾーンにはそれぞれ専用の hosts ファイルが必要です。そして、各ゾーンの hosts ファイルにはそれぞれ固有の名前が付けられていなければなりません。たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts ファイルの名前は db.doc、もう一方の名前は db.sales とします。
/var/named/hosts.rev
hosts.rev ファイルの詳細は、「hosts.rev ファイルの設定 」、および『Solaris ネーミングの管理』 を参照してください
hosts.rev はファイルの目的や中身を表す総称名です。ゾーンがいくつかに分かれている場合、各ゾーンにはそれぞれ専用の hosts.rev ファイルが必要です。そして、各ゾーンの hosts.rev ファイルにはそれぞれ固有の名前が付けられていなければなりません。たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts.rev ファイルの名前は doc.rev 、もう一方の名前は sales.rev とします。
/var/named/named.local
named.local ファイルの詳細は、「named.local ファイルの設定」、および『Solaris ネーミングの管理』を参照してください。内部で一貫性が取られてさえいれば、このファイルには何でも好きな名前を付けることができます。
DNS データファイルの $INCLUDE 宣言で名前が指定されているファイルのことをインクルードファイルといいます。$INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。(詳細については、『Solaris ネーミングの管理』を参照)。
「ドメイン名」とは、ローカルネットワークの中で DNS 管理ファイルを共有する複数のシステムを 1 つのグループとして扱い、そのグループに付けた名前のことです。ドメイン名は、ネットワーク情報サービスデータベースが正常に動作するために必要です。
DNS がデフォルトで使用するドメイン名は resolv.conf ファイルに指定されています。
resolv.conf ファイルがない場合、あるいは resolve.conf ファイルにデフォルトのドメイン名が指定されていない場合で、しかも、企業レベルで使っているネームサービスが NIS+ または NIS のどちらかである場合は、DNS はそれらのサービスからデフォルトのドメイン名を取得します。
resolv.conf ファイルがない場合、あるいは resolv.conf ファイルにドメイン名が指定されていない場合で、しかも、NIS+ と NIS のどちらも使っていない場合は、そのドメインを指定するすべてのマシンに resolv.conf ファイルを格納するか (「resolv.conf ファイルの設定 」を参照)、LOCALDOMAIN
環境変数を設定しなければなりません。
各種 DNS ファイルに関連して、ドメイン名の末尾のドットには次のような規則があります。
hosts、hosts.rev、named.ca、named.local の各データファイルの中では、ファイル名の末尾にドットを付けます。たとえば、sales.doc.com. は、これらのファイルの中では有効です。
named.boot ファイル内、または resolv.conf ファイルの中では、ドメイン名の末尾にドットを付けません。たとえば、sales.doc.com は、これらのファイルの中では有効です。
ここでは、doc.com ドメインのサーバーに使う簡単な resolv.conf ファイルの例を示します。
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 0.0.0.0 nameserver 111.22.3.5
/etc/resolv.conf ファイルの最初の行には、ドメイン名が次の書式で指定されています。
domain domainname
ここで、domainname の部分には、インターネット管理団体 (本書執筆の時点では InterNIC。日本では JPNIC) によって登録されている名前を指定します。
ドメイン名の末尾にスペースまたはタブを使うことはできません。ドメイン名の最後の文字を入力したら、必ずキャリッジリターンで強制改行してください。
2 行目には、サーバー自体を次の書式で指定します。
nameserver 0.0.0.0
それ以降の行では、副 DNS ネームサーバー、またはキャッシュ専用ネームサーバー の IP アドレスを 1 つまたは 2 つ指定します。リゾルバはこれらの行を照会して該当するアドレスを識別します。各行の書式は次のとおりです。
nameserver IP_address
ここで、IP_address の部分には、副 DNS ネームサーバー、またはキャッシュ専用ネームサーバー の IP アドレスを指定します。リゾルバは、必要な情報が見つかるまで、ここに指定されている順番どおりにネームサーバーを探していきます。
ブートファイルの内容は、サーバーの種類に応じて異なります。この節では、主サーバーおよび副サーバー、ならびにキャッシュ専用サーバーのブートファイルについて説明します。
ブートファイルの名前は必ず named.boot にします。サーバーの初期設定スクリプト /etc/init.d/inetsvc は、in.named デーモンのブートファイルを探すとき /etc/named.boot という名前を使用します。このスクリプトは、ブートファイルに別の名前を付けていれば in.named デーモンを起動しません。
; named.boot file on the dnsmastr ; ; files required by in.named are located here directory /var/named ; here are the names of the primary files cache . named.ca primary doc.com db.doc primary 0.0.127.in-addr.arpa db.127.0.0 primary 6.45.123.in-addr.arpa db.123.45.6 ;This system is also the secondary for the sales.doc.com domain secondary sales.doc.com 111.22.3.4 db.sales secondary 3.22.111.in-addr.arpa 111.22.3.4 db.192.168.8
この章で紹介するさまざまなサンプルファイルの中で、サーバー dnsmaster (IP アドレス 1213.45.6.1 の altair マシンの別名) のブートファイルがたびたび登場しますが、そのいずれもが上記のブートファイルを指しています。
directory 行 (「directory 行」を参照)
cache 行 (「cache 行」を参照)
1 つまたは複数のネームサーバー行 (「サーバー機能の指定」を参照)
ブートファイル内の以下の行は、ネームサーバーを実行するディレクトリを指定します。
directory /var/named
これによって、ブートファイル、または後で $INCLUDE
指令を使って、指定されたファイルの相対パス名を使用できます。管理すべきファイルが多数あり、しかもこれらをすべて 1 つの専用ディレクトリ内に置きたい場合、これは特に便利です。
ブートファイルに directory 行がない場合、この中に登録されたすべてのファイル名はフルパス名でなければなりません。
ネームサーバーは、どのサーバーがルートゾーンに対して権限を持つネームサーバーであるかを知っておく必要があります。そのために、これらの高い権限を持つアドレスを指定しなければなりません。
すべてのサーバーには、ルートネームサーバーを見つけるために、ブートファイル内に次の行が必要です。
cache . named.ca
cache (.) の後ろの最初のフィールドには、ルートサーバーについての手がかりをサーバーに探させるファイル (この場合は、/var/named ディレクトリにある /named.ca) を指定します。
サーバー役割行には、サーバーの役割 、つまり、サーバーを主ネームサーバーとして使うか副ネームサーバーとして使うかを指定します。詳細は、「サーバー機能の指定」を参照してください。
DNS サーバーには次の役割のいくつかを果たします。
「ゾーン主マスターサーバー」
各ゾーンには、主マスターサーバーを 1 ずつ指定します。主マスターサーバーとは、そのゾーンにおける正規の機能を有するサーバーのことをいいます (「主マスターサーバーの指定」を参照)。
「ゾーン副マスターサーバー」
各ゾーンには、「副」マスターサーバーを 1 つまたは複数指定します。副マスターサーバーは、そのゾーンにおける主マスターサーバーから DNS を取得するサーバーのことをいいます。副サーバー上のデータは直接変更しません。あるゾーンの主サーバー上のデータファイルが変更された場合、主サーバーを通じて副サーバーのファイルが更新されます (「副マスターサーバーの指定」を参照)。
「キャッシュ専用サーバー」
DNS データをキャッシュ維持するという意味では、すべてのサーバーがキャッシュサーバーであるといえます。キャッシュ専用サーバーは、in-addr.arpa. ドメイン以外のいかなるゾーンのマスターサーバーではないサーバーです。 (「キャッシュ専用サーバーの指定」を参照)。
「ルートドメインサーバー」
インターネットに接続されているネットワークでは、ルートドメインサーバーがインターネット上に置かれることになります。この場合は、named.ca ファイルに各ルートドメインサーバーの IP アドレスを指定するだけで済みます (「named.ca ファイルの設定」を参照)。ネットワークがインターネットに接続されていない場合は、独自にルートドメインサーバーを設定しなければなりません (「非インターネットルートマスターの設定」を参照)。
これらの様々なサーバーの機能は同じマシンで実行できます。たとえば、あるゾーンで主マスターサーバーとして使っているマシンを、他のゾーンでは副マスターサーバーとして使うことができます。本書で「主」、「副」、「キャッシュ専用」とマシンを形容している場合、それは特定のマシンを指しているのではなく、あるゾーンでマシンに割り当てられた役割を指しています。
これらのサーバーの役割の詳細は、『Solaris ネーミングの管理』を参照してください。
あるゾーンであるマシンを主サーバーとして使うことを指定する場合は、そのマシン (サーバー) 上の named.boot ファイルに次の 3 つの「主」レコードを書き込みます。
ゾーンの「主」レコードを作成します。
このレコードは、そのサーバーを主サーバーとして使用するゾーンを指定し、正規の hosts ファイルの場所を示すものです。この「主」レコードは次の 3 つのフィールドで構成されます。
第 1 フィールド - サーバーを主 (primary) サーバーとして指定する
第 2 フィールド - 対象のゾーンを指定する
次に示すブートファイルの行は、あるサーバーを doc.com ゾーンで主サーバーとして使い、正規の hosts ファイルとして db.doc を使うことを示すものです。
primary doc.com db.doc
このレコードは、そのサーバーを逆アドレス変換 (つまり、doc.com の逆アドレスドメイン) の主サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「主」レコードには 3 つの構成要素があります。第 1 フィールドではサーバーを主サーバーとして指定します。第 2 フィールドでは対象のゾーンを指定します。第 3 フィールドでは hosts.rev ファイルを指定します。
あるゾーンにおける逆アドレスドメインは、そのゾーンにおける IP アドレスを逆にならべ、最後に in-addr.arpa を配したものです。たとえば、doc.com ゾーンの IP アドレスが 123.45.6. だとすると、逆アドレスドメインは 6.45.123.in-addr.arpa になります。
次に示すブートファイルの行は、そのサーバーを doc.com ゾーンの逆アドレスドメインで主サーバーとして使い、正規の hosts ファイルとして doc.rev を使うことを示すものです。
primary 6.45.123 . in-addr.arpa doc.rev
ローカルループバック (ホスト) の逆アドレス関連の「主」レコードを作成します。
このレコードは、そのサーバーをループバックホストの主サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「主」レコードには 3 つの構成要素があります。第 1 フィールドではサーバーを主サーバーとして指定します。第 2 フィールドではループバックホストのリバースアドレスを指定します。第 3 フィールドでは hosts.rev ファイルを指定します。
ループバックホストは常に、0.0.127.in-addr.arpa といった書式で識別されます。
次に示すブートファイルの行は、そのサーバーをループバックホストの逆アドレスドメインで主サーバーとして使い、正規の hosts ファイルとして named.local を使うことを示すものです。
primary 0.0.127.in-addr.arpa named.local
あるゾーンであるマシンを副サーバーとして使うことを指定する場合は、そのマシン (サーバー) 上の named.boot ファイルに「副」レコードを書き込みます。別々のレコードにより、サーバーをそのゾーン、逆アドレスドメイン、およびループバックホストの副サーバーとして指定できます。
この「副」レコードは次の 3 つのフィールドで構成されます
第 1 フィールド - サーバーを副サーバーとして指定する
第 2 フィールド - 対象のゾーンを指定する
第 3 フィールド - そのゾーンの主サーバーの IP アドレスを指定する。副サーバーは主サーバーから正規データを取得する
「副」レコードでは、必須フィールドに続けて 1 つまたは複数の任意フィールドを設けることができます。任意フィールドには次の種類があります。
「副サーバー」
主サーバーの IP アドレスに続けて、他の副サーバーの IP アドレスを指定できます。これにより、副サーバーが情報を入手できる情報源が増えます。一方、状況によっては、副サーバーの IP アドレスを指定することで、パフォーマンスが下がることも考えられます (IP アドレスがマルチホーム主サーバーのもう一方のネットワークアドレスである場合を除く)。
「バックアップファイル」
主サーバー (および任意指定の副サーバー) の IP アドレスに続けて、バックアップ hosts ファイルの名前を指定できます。バックアップファイル名を指定すると、副サーバーはそのバックアップファイルからデータをロードし、続いて主サーバー (および任意指定の副サーバー) をチェックしてバックアプリケーションファイルのデータが最新のものであるかどうかを確認します。その結果、最新ではないことが分かった場合は、主サーバーから受け取った情報に基づいて更新されます。
次に示すブートファイルの行は、あるサーバーを doc.com ゾーンと逆アドレスドメインの副サーバーとして使うことを示します。さらに、その副サーバーが IP アドレス 129.146.168.119 の主サーバーから正規データを受け取り、サーバー 192.146.168.38 をゾーンデータの副情報源として使い、最初に doc.com.bakup ファイルから初期データをロードすることを示します。
secondary doc.com 129.146.168.119 192.146.168.38 doc.com.bakup secondary 4.0.32.128.in-addr.arpa 129.146.168.119
この章で紹介するさまざまなサンプルファイルの中で、サーバー dnssecondary (IP アドレス 192.146.168.38 の sirius マシンの別名) のブートファイルがたびたび登場しますが、そのいずれもが上記のブートファイルを指しています。
1 台のサーバーは、1 つまたは複数のゾーンの主サーバーとして機能し、さらに 1 つまたは複数のゾーンの副サーバーとしても機能できます。これを決めるのは、ブートファイル内のエントリの組み合せです。
キャッシュ専用サーバーは正規データは一切管理しません。キャッシュ専用サーバーは照会を行い、in.named ファイルにリストされているホストを照会して必要な情報を探します。つまり、キャッシュ専用サーバーは、正規のネームサーバーと同様の照会を行いますが、正規データそのものは一切管理しません。
例 13-3 では、キャッシュ専用サーバー用のブートファイルのサンプルを示します。
; ; Sample named.boot file for caching-only name server ; ; type domain source file or host ; directory /var/named cache . named.ca primary 0.0.127.in-addr.arpa named.local
サーバーをキャッシュ専用サーバーとして指定するための行は特に必要ありません。ブートファイル内に secondary または primary など、権限に関する行がないということが、キャッシュ専用サーバーであると判断する根拠になります(以下に示すものを除く)。
ブートファイルの directory 行
ブートファイルの primary 0.0.127.in-addr.arpa 行
ブートファイルの cache . named.ca 行
DNS デーモン in.named が使用するすべてのデータファイルは、標準資源レコード書式で記述されます。標準資源レコード書式では、ファイルの各行は、資源レコード (RR) と呼ばれるレコードです。各 DNS データファイルには決められた資源レコードが必要です。
資源レコード、その書式、フィールド、特殊文字、制御行 (エントリ) の詳細は、『Solaris ネーミングの管理』を参照してください。
最も一般的に使用される資源レコードの種類を表 13-2に示します。資源レコードは通常、表 13-2 の順番で入力されますが、必ずしもそうしなければならないということではありません。
表 13-2 一般的に使用される資源レコードの種類
種類 |
説明 |
---|---|
SOA |
権限の始まり |
NS |
ネームサーバー |
A |
インターネットアドレス (名前からアドレスへ) |
PTR |
ポインタ (アドレスから名前へ) |
CNAME |
標準名 (ニックネーム) |
TXT |
テキスト情報 |
MX |
メール交換 |
これらの資源レコードの詳細は、『Solaris ネーミングの管理』を参照してください。
これ以降に示すサンプルファイルでは、@ は現在のゾーンまたは現在の起点を示します。セミコロン (;) で始まる行はコメントです。
/var/named/named.ca ファイルには、ルートサーバーの名前とアドレスが格納されています。ルートサーバー名は NS レコードに、アドレスは A レコードに示されています。この named.ca ファイルを使用するサーバーごとに、NS レコードと A レコードを追加する必要があります。
named.ca ファイルの入手方法あるいは作成方法は、ネットワークがインターネットに接続されているかどうかによって異なります。
ネットワークがインターネットに接続されているのであれば、InterNIC Registration Service (本書執筆の時点) から次の手段で named.ca ファイルを入手できます。
匿名 FTP
FTP サイトは ftp.rs.internic.net、ファイル名は /domain/named.root です。
Gopher
Gopher サイトは rs.internic.net です。ファイルは named.root であり、これは [InterNIC Registration Service] メニューの [InterNIC Registration Archives] サブメニューで見つけることができます。
本書で説明した命名規則に従うならば、named.root を /var/named/named.ca に移動します。
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File
ネットワークがインターネットに接続されていない場合は、独自の named.ca ファイルを作成する必要があります。それには、サーバーのどれか 1 つをルートサーバーとし、 DNS サーバーごとにそのルートサーバーを指す named.ca ファイルを作成します。
たとえば、ドメイン private においてマシン ourroot を非インターネットルートサーバーに指定する場合を想定します。ourroot の IP アドレスが 192.1.1.10 であるとすると、named.ca ファイルには次の行を書き込みます。
ourroot.private. 999999 IN A 192.1.1.10
キャッシュファイルも SOA レコード、各ドメインおよびサブドメインの NS レコード、各サーバーの A レコードを必要とします。
たとえば、ourroot の他に、ourprimary と oursecondary という 2 つの DNS ネームサーバーがあるとします。その場合、DNS サーバー上の named.ca ファイルはいずれも次のようになります。
; @ IN SOA ourroot.private. hermit.ourroot.private ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day ; ourroot.private. 999999 IN A 192.1.1.10 ; private. IN NS ourprimary.private. 1.1.192.in-addr.arpa IN NS ourprimary.private. ourprivate.private. IN A 192.1.1.1 ; private. IN NS oursecondary.private. 1.1.192.in-addr.arpa IN NS oursecondary.private. oursecondary.private. IN A 192.1.1.2
インターネットに接続されていないドメインの設定の詳細は、「非インターネットルートマスターの設定」を参照してください。
hosts ファイルには、ゾーン内にある全マシンの全データが収められています。複数のドメインにまたがっているゾーンの場合は、そのゾーンを構成する全ドメインの全マシンがそのゾーンのホストファイルに列挙されます (「単一ゾーンのサブドメインの設定」を参照)。
hosts という名前はファイルの役割や中身を表す総称名です。この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にすることをお勧めします。ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、しかも、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つを db.doc、もう 1 つを sales.db.doc という名前にするとよいでしょう。
各ゾーンには個別の、一意の名前を持つ hosts ファイルが必要です。複数のゾーンが存在する場合は、各ゾーンの hosts ファイルには他のゾーンのマスター (主、副) サーバーに関する情報も含める必要があります。詳細は、「複数ゾーンのサブドメインの設定」を参照してください。
; ; SOA rec doc.com IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com IN NS sirius.doc.com sales.doc.com IN NS altair.sales.doc.com ; Addresses localhost IN A 127.0.0.1 sirius IN A 123.45.6.1 rigel IN A 123.45.6.112 antares IN A 123.45.6.90 polaris IN A 123.45.6.101 procyon IN A 123.45.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com IN A 111.22.3.4 ; aliases durvasa IN CNAME sirius.doc.com dnsmastr IN CNAME sirius.doc.com dnssales IN CNAME altair.sales.doc.com
hosts ファイルは、通常、次の 5 つの要素で構成されています。
SOA (権限の始まり) レコード
1 つまたは複数の NS (ネームサーバー) レコード。主および副の DNS ネームサーバーを示す
A (アドレス) レコード。ゾーン内の各ホストに必要
ゾーン内のホストの別名に対する CNAME (標準名) レコード
MX (メール交換) レコード
(これらの資源レコードの詳細は、『Solaris ネーミングの管理』を参照してください。
hosts.rev という名前はファイルの役割や中身を表す総称名です。ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts.rev ファイルを置き、しかも、各ゾーンの hosts.rev ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つを doc.rev、もう 1 つを sales.rev という名前にするとよいでしょう。
; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com 1 IN PTR sirius.doc.com
hosts.rev ファイルは、通常、次の 3 つの要素で構成されています。
SOA (権限の始まり) レコード
1 つまたは複数の NS (ネームサーバー) レコード
主および副の DNS ネームサーバーを示す。サーバー名は省略形で指定してはならない。
PTR レコード
ゾーン内の各ホストに必要。マシン名は省略形で指定してはならない
これらの資源レコードの詳細は、『Solaris ネーミングの管理』を参照してください。
named.local ファイルは、ネームサーバーのローカルループバックインタフェースを設定します。
; SOA rec 0.0.127.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com 1 IN PTR localhost.
named.local ファイルは、通常、次の 3 つの要素で構成されています。
1 つまたは複数の NS (ネームサーバー) レコード。主および副の DNS ネームサーバーを示す。サーバー名およびドメイン名は省略形で指定してはならない
localhost の PTR レコード
これらの資源レコードの詳細は、『Solaris ネーミングの管理』を参照してください。
サーバーの初期設定の手順は次のとおりです。
named.boot ブートファイルとその他必要なファイルを設定します。
in.named を実行します。
# /usr/sbin/in.named
コマンドラインから in.named を実行する代わりに、リブートするという方法もあります。
ブートファイルとデータファイルを設定し、in.named を実行したら、設定が正しく行われたかどうかを次の手順で確認してください。
syslog ファイルをオープンして、エラーメッセージが書き込まれていないかどうか確認します。
エラーメッセージと障害追跡の仕方については、『Solaris ネーミングの管理』を参照してください。
nslookup を実行して、ローカルドメインのホスト名を確認します。
dnsmaster% nslookup altair Server: dnsmaster.doc.com Address: 192.146.168.5 Name: altair.doc.com Address: 192.146.168.10
異常が見つからなければ、ネームサーバーはおそらく正常に機能しています。
「Can't find」 または 「can't initialize address」といったメッセージがサーバーに出た場合、あるいは 「Non-existent domain」 といったメッセージが出た場合は、サーバーがブートファイルまたはホストファイルに設定されていない可能性があります。
nslookup を実行してリモートドメイン名を検索します。
インターネットに接続されているネットワークの場合、リモートドメイン名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンにサブドメインがあれば、その名前を検索します。 たとえば、インターネット上のリモートドメイン名 internic.net を検索するには、次のように入力します。
dnsmaster% nslookup internic.net Server: dnsmaster.doc.com Address: 192.146.168. Name: internic.net Addresses: 198.41.0.9, 198.41.0.6, 198.41.0.5, 198.41.0.8
異常が見つからなければ、ネームサーバーはおそらく正常に機能しています。
上記のコマンドを実行してもリモートドメイン名が表示されない場合は、インターネットとの接続に問題があることが原因の 1 つとして考えられます。
あるいは、named.ca ファイルが正しくインストールまたは設定されていないことも考えられます。
(もう一度 nslookup を実行すると、「non-authoritative」というメッセージが出るはずですが、これは無視してかまいません。2 回目の実行では、リモートネームサーバーからではなく、キャッシュから応答が来ています。)
リモートドメインから自分のドメインのホストの名前を検索します。
インターネットに接続されているネットワークの場合、リモートドメインに行き、そこから自分のドメインのホスト名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンがあれば、そこから自分のドメインのホスト名を検索します。
たとえば、インターネット上のリモートドメインから自分のドメインにあるホスト名を検索するには、nslookup コマンドに続けて、引数を 2 つ指定します。1 つめは検索対象のホスト名、2 つめは nslookup コマンドを実行するネームサーバー名です。具体的には次のように指定します。
remotemachine9% nslookup altair remotemaster.foo.org. Server: remotemaster.foo.org Address: 123.231.12.22 Name: altair.doc.com Addresses: 111.22.3.4
異常が見つからなければ、ネームサーバーはおそらく正常に機能しています。
上記のコマンドを実行しても探しているマシンが見つからない場合は、ドメインが親ドメイン (上記の例では .com) の管理者と正しく登録されていないことが原因の 1 つとして考えられます。
サブドメインの設定方法には、次の 2 通りがあります。
「単一ゾーン」
最も簡単な方法は、サブドメインを親ドメインのゾーンに含めることです。こうすると、1 セットの DNS サーバーとデータファイルでドメインに関係なくすべてのマシンを管理できます。詳細は、「単一ゾーンのサブドメインの設定」を参照してください。
単一ゾーン方式の長所は、管理が簡素化され簡単なことです。短所は 1 セットのサーバーですべてのゾーンのドメインにあるマシンを管理しなければならないということです。マシンの数が多すぎると、サーバーの負荷が大きくなり過ぎ、パフォーマンスが低下することがあります。
「複数ゾーン」
異なるゾーンに異なるドメインを含めることができます。あるゾーンのクライアントから他のゾーンのホストに関する情報をどうやって集めるかを考えなければならないので、この方法は上の方法より複雑です。詳細は、「複数ゾーンのサブドメインの設定」を参照してください。
複数ゾーン方式の長所は、ドメインごとにその中のマシンを管理するサーバーセットを変更できるということです。つまり、サーバーの負荷を分散させ、1 セットのサーバーに負荷が集中するのを防ぐことができます。短所は、設定時の作業が複雑になることです。
複数のドメインで構成されているゾーンのデータファイルには、そのゾーンによってカバーされる各ドメインのすべてのマシンとサーバーに関わるレコードが必要です。
複数のドメインで構成されているゾーンを設定するのも、単一ドメインで構成されているゾーンを設定するのも、やることは基本的に同じです。唯一の相違は、リモートドメインのマシンを識別できるようにするために、hosts ファイルには完全指定のドメイン名を使用しなければならないということです。サーバーのローカルドメインにあるマシンであれば、hosts ファイルにマシン名しか指定されていなくても識別できます。しかし、他のドメインにあるマシンを識別するには、完全指定のドメイン名、つまり machine.domain という書式で指定しなければなりません。
hosts.rev ファイルと named.local ファイルに指定するサーバー名やマシン名は、完全指定のドメイン名を使用する必要があります。しかし、これはゾーンがいくつのドメインで構成されているかを問いません。
異なるゾーンのサブドメインを設定するのは、1 つのゾーンに複数のドメインを含めるのよりも複雑です。というのも、さまざまなゾーンにあるクライアントが、他のゾーンの DNS 情報を得る方法を指定しなければならないからです。
ネットワークを複数のドメインに分ける場合、ドメインを階層化します。必ず最上位のドメインがあって、その下に 1 つまたは複数のサブドメインがあります。サブドメインの下にサブドメイン作ることもできます。しかし、どのサブドメインにも、階層構造の中で決まった場所があります。ドメイン名は左から右に読んでいくと、階層内におけるドメインの位置を示していることがわかります。たとえば、doc.com ドメインは sales.doc.com の上にあり、west.sales.doc.com ドメインは sales.doc.com ドメインの下にあることがわかります。
DNS ゾーンはそれが含むドメインから階層を取り込みます。ネットワークのトップドメインを含むゾーンはトップゾーンになります。トップドメインの下のサブドメインを 1 つまたは複数含むゾーンは、ゾーンの階層でいえばトップゾーンの下のゾーンになります。DNS 情報をあるゾーンから別のゾーンへ移動させるということは、このゾーン階層の中を上下に移動させるということです。つまり、各ゾーンは、すぐ上のゾーンに情報を渡すにはどうするか、すぐ下のゾーンに情報を渡すにはどうするかを、専用のデータファイルに指定しておく必要があります。
複数のゾーンで構成されているネットワークの中で、DNS 情報をあるゾーンから別のゾーンへ正確に転送させるために必要なことがらを以下に示します。
hosts.rev ファイル
すぐ上のゾーンにある 1 つまたは複数のマスターサーバー名を指し示す PTR レコードが各 hosts.rev ファイルに必要です。上位ゾーンのサーバーを指し示すということを除けば、この種の PTR レコードは、ファイル内のその他の PTR レコードとまったく同じのものです。
hosts ファイルの NS レコード
すぐ上のゾーンにあるネームサーバー名を指し示すゾーン NS レコードが各 hosts ファイルに必要です。この種の NS レコードは、その最初のフィールドに、下のゾーン名が指定されていなければなりません。(ゾーンの名前は、そのゾーンの host ファイルの SOA レコードに指定されています。)
hosts ファイルの A レコード
すぐ下のゾーンにあるネームサーバーの IP アドレスを指し示す A レコードが各 hosts ファイルに必要です。この種の A レコードは、その最初のフィールドに、下のゾーン名が指定されていなければなりません。(ゾーン名は、そのゾーンの host ファイルの SOA レコードに指定されています。)
「実例 」は、2 つのゾーンを有するネットワークを示します。
インターネットに接続されているネットワークの場合、ルートドメインサーバーがルートドメインのインターネットサイト上に置かれることになります。この場合は、キャッシュファイルにそのサイトの IP アドレスを書き込むだけで済みます。「インターネット named.ca ファイル 」を参照してください。
ネットワークに接続されていないネットワークの場合、ローカルネットワーク上のルートレベルドメインに主および副のネームサーバーを設定する必要があります。これにより、ネットワーク内のすべてのドメインで一貫性のある正規のサーバーを持つことができます。さもないと、いずれのマシンも照会を処理することができません。
たとえば、private という名前の非インターネットドメインで ourroot というマシンをルートサーバーとして指定する場合を想定します。ourroot マシンの IP アドレスが 192.1.1.10 だとすると、次のような手順を踏むことになります。
ルートサーバーを指し示す named.ca ファイルを主マスターサーバー上に作成します。
次のように入力します。
ourroot.private. 999999 A 192.1.1.10
named.ca ファイルには、内部のドメインとサブドメイン用の個別の NS レコードと、サーバー用の個別の A レコードが必要です。詳細は、「非インターネットルートマスターの設定」を参照してください。
ネットワーク上のすべての DNS ネームサーバーのブートファイルに、ルートドメインのキャッシュリソースレコードを追加します。
次のように入力します (詳細は、「ブートファイル」を参照)。
cache . named.ca
ルートサーバーのブートファイルから、ルートドメインのキャッシュリソースレコードを削除します。
つまり、ourroot のブートファイルから cache .named. ca 行を削除します。
ルートサーバーのブートファイルに、ルートドメインの primary 行を追加します。
たとえば、ourroot のブートファイルに次の行を追加します。
primary . ourroot.private
設定後、インターネットに接続することにした場合は、すべてのサーバーの named.ca ファイルを最新のインターネットファイルに置き換え、それまでルートサーバーだったマシンのブートファイルをオープンし、primary . rootserver 行を cache . named.ca 行に書き換える必要があります。
この節では、この章で説明した例に基づいて、サンプルのインターネット接続ネットワークを想定し、そこで使う DNS を設定するために必要なファイルを示します。
この例で使われている IP アドレスとネットワーク番号、および本書で使われているサンプルコードは、説明に具体性を持たせるために仮に決めたものです。それらは、実際のネットワークやホストに使われていることがありますので、そのまま使うのは避けてください。
この実例の前提条件
インターネットに接続されている
2 つのネットワークが存在 (ドメインは doc.com と sales.doc.com)。DNS ゾーンも別々に管理
doc.com ドメインおよび doc.com ゾーンが sales.doc.com サブドメインおよび sales.doc.com ゾーンの上のトップゾーンである
2 つのネットワークはどちらも個別のネットワーク番号を持っている
名前/ゾーン |
番号 |
---|---|
doc.com |
123.45.6 |
sales.doc.com |
111.22.3 |
各ゾーンにマスターサーバーと副サーバーがあり、 doc.com の主サーバーが sales.doc.com の副サーバーを兼ねている
ゾーン |
ホスト名 |
役割 |
アドレス | 標準名 |
---|---|---|---|---|
doc.com |
sirius |
doc.com の主サーバ |
123.45.6.1 | dnsmaster |
doc.com |
deneb |
doc.com の副サーバ |
111.22.3.5 | dnssecond |
sales.doc.com |
altair |
sales.doc.com の主サーバ |
111.22.3.4 | dnssales |
sales.doc.com |
altair |
secondary の副サーバ |
123.45.6.1 | dnsmaster |
次に示すのは、2 つのネットワークで使われている 3 つのサーバーのブートファイルです。
; named.boot file on the dnsmastr (sirius) ; ; files required by in.named are located here directory /var/named ; here are the names of the primary files cache . named.ca primary doc.com db.doc primary 0.0.127.in-addr.arpa named.local primary 6.45.123.in-addr.arpa doc.rev ;This system is also the secondary for the sales.doc.com domain secondary sales.doc.com 111.22.3.4 db.sales secondary 3.22.111.in-addr.arpa 111.22.3.4 sales.rev
; named.boot file on the dnssales (altair) ; ; in.named is located here directory /var/named ; here are the names of the primary files cache . named.ca primary sales.doc.com db.sales primary 0.0.127.in-addr.arpa db.127.0.0 primary 3.22.111.in-addr.arpa db.192.168.8
; named.boot file on the dnsecond (deneb) directory /var/named cache . named.ca secondary doc.com 123.45.6.1 doc.com secondary 6.45.123.in-addr.arpa 123.45.6.1 doc.123.45.6
次に示すのは、2 つのネットワークで使われている 3 つのサーバーの resolv.conf ファイルです。(そのホストが in.named を稼動していない場合、そのローカルホストのアドレスをネームサーバーとして使うことはできません。)
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 0.0.0.0 nameserver 111.22.3.5
; ; /etc/resolv.conf file for dnssales (altair) ; domain sales.doc.com nameserver 111.22.3.4 nameserver 123.45.6.1
; ; /etc/resolv.conf for dnssecond ; domain doc.com nameserver 111.22.3.5 nameserver 123.45.6.1
次に示すのは、2 つのネットワーク上の 2 つの主サーバーで使われている named.local ファイルです。どちらのサーバーも同じファイルを持っています。
; SOA rec 0.0.127.in-addr.arpa. IN SOA siriusdoc.com. sysop.centauri.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com. 0.0.127.in_addr.arpa IN NS dnssecond.doc.com 1 IN PTR localhost.
次に示すのは、2 つのネットワーク上の 2 つの主サーバーで使われている db.doc ファイルと db.sales ファイルです。
; SOA rec doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses localhost IN A 127.0.0.1 sirius IN A 123.45.6.1 rigel IN A 123.45.6.112 antares IN A 123.45.6.90 polaris IN A 123.45.6.101 procyon IN A 123.45.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com. IN A 111.22.3.4 ; aliases dnsmastr IN CNAME sirius.doc.com. dnssecond.doc.com IN CNAME deneb.doc.com
; SOA rec sales.doc.com. IN SOA altair.sales.doc.com. sysop.polaris.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses altair IN A 111.22.3.4 localhost IN A 127.0.0.1 sirius.doc.com. IN A 123.45.6.1 luna IN A 192.168.8.22 phoebus IN A 192.168.8.24 deimos IN A 192.168.8.25 ganymede IN A 192.168.8.27 europa IN A 192.168.8.28 callisto IN A 192.168.8.29 ; ; aliases dnssales.sales.doc.com IN CNAME altair.sales.doc.com
次に示すのは、2 つのネットワーク上の 2 つの主サーバーで使われている hosts.rev ファイルです。
; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com. ;Pointer records for 123.45.6 1 IN PTR sirius.doc.com. 112 IN PTR rigel.doc.com. 90 IN PTR antares.doc.com. 101 IN PTR polaris.doc.com. 79 IN PTR procyon.doc.com. 69 IN PTR tauceti.doc.com.
; SOA rec 3.22.111.in-addr.arpa. IN SOA altair.sales.doc.com. sysop.polaris.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 3.22.111.in-addr.arpa. IN NS altair.sales.doc.com. ;Pointer records for 111.22.3 22 IN PTR luna 23 IN PTR deneb 24 IN PTR phoebus 25 IN PTR deimos 26 IN PTR altair 27 IN PTR ganymede 28 IN PTR europa 29 IN PTR callisto
次に示すのは、2 つのネットワーク上の 2 つの副サーバーのどちらにも格納される named.ca ファイルです。
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File