ここでは、Solaris オペレーティング環境における DNS ネームサービスの設定、構成、管理、障害追跡について説明します。
この章ではドメインネームシステム (DNS) の構造と概要を説明します。
DNS の利用で最も一般的で重要なことは、ネットワークをグローバルなインターネットに接続することです。インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。
この章の内容は次のとおりです。
ドメインネームシステム (DNS) は、標準 TCP/IP プロトコル群のひとつのアプリケーション層プロトコルです。このプロトコルによって DNS ネームサービスが実現します。DNS ネームサービスはインターネットで使用されるネームサービスです。
ここでは、DNS の基本的な概念について説明します。説明に際しては、ネットワークの管理 (特に TCP/IP) に精通していて、NIS+ や NIS といった他のネームサービスについての知識があることを前提とします。
DNS の初期設定と構成については、第 4 章「DNS の管理 (手順)」を参照してください。
DNS、NIS+、NIS、FNS には同じような機能があり、時として異なる構成要素を定義するのに同じ用語を使用している場合がありますが、この章では、ドメインやネームサーバーといった用語は DNS の機能に合わせて定義しています。なぜなら、DNS の機能は NIS+ や NIS のドメインやサーバーとは大きく異なるからです。
DNS はインターネット上の複雑で全世界的なコンピュータの階層をサポートしますが、それ自身の基本機能は非常に簡単なものです。すなわち、TCP/IP に準拠したネットワークに「名前のアドレス解決」を提供するということです。名前のアドレス解決は「マッピング」ともいい、あるコンピュータのホスト名をインデックスとして用い、その IP アドレスをデータベースから見つけだすプロセスのことです。
名前のアドレスマッピングは、ローカルマシンで実行されているプログラムが遠隔コンピュータにアクセスする必要があるときに行われます。ほとんどの場合、このプログラムでは遠隔コンピュータのホスト名はわかっても、その場所を特定できません。特に遠隔マシンが自分のサイトから何マイルも離れた他の会社にある場合には場所を特定できません。プログラムは遠隔マシンのアドレスを得るために、ローカルマシン上で動作している DNS ソフトウェアに要求を送ります。このときのローカルマシンを「DNS クライアント」と呼びます。
ローカルマシンは、「DNS ネームサーバー」に要求を送ります。DNS ネームサーバーは 分散型 DNS データベースを保持しています。NIS+ の host または ipnodes テーブル、あるいはローカルの /etc/hosts ファイル、/etc/inet/ipnodes ファイルも同様の情報、すなわち、ホスト名、ipnodes 名、IPv4、IPv6 のアドレス、その他コンピュータの特定のグループに関する情報を保持していますが、DNS データベースのファイルはそれらと異なる部分が多くあります。ネームサーバーはローカルマシンが遠隔マシンの IP アドレスを検索または解決するための要求の一部として、送信する自分自身のホスト名を使用しますが、ネームサーバーは、そのホスト名も利用します。そして、要求したホスト名が DNS データベースにあれば、その IP アドレスがネームサーバーによってローカルマシンに返されます。
次の図に、DNS クライアントのローカルネットワーク上で行われるクライアントとネームサーバーの間での名前のアドレスマッピングを示します。
ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。このように、各ネームサーバーは、ローカル管理ドメインに対して権限があるとされています。
幸い、ローカルネームサーバーでは、ルートドメインネームサーバーのホスト名と IP アドレスのリストを保持しています。ローカルネームサーバーは、ローカルマシンからの要求を「ルートドメインネームサーバー」に転送します。ルートネームサーバーは、「DNS 階層とインターネット」で詳しく説明しているように、大きな組織のドメインに対して権限があります。その階層は、上下逆のツリー構造で編成された UNIX のファイルシステムに似ています。
各ルートネームサーバーでは、会社、大学、またはその他大規模な組織における最上位のドメインネームサーバーのホスト名と IP アドレスを管理しています。ルートネームサーバーは、ホスト名と IP アドレスがわかっているすべての最上位のネームサーバーにローカルマシンからの要求を送信します。要求されたホストの IP アドレスを最上位のネームサーバーのどれかが持っている場合、その情報がローカルマシンに返されます。最上位のサーバーが要求されたホストに関する情報を持っていない場合、情報がわかっている第 2 レベルのネームサーバーに要求が渡されます。このようにローカルマシンからの要求は組織の巨大なツリー構造の下へ向かって順に渡されます。最終的に、ローカルマシンからの要求に関する情報がデータベースに格納されているネームサーバーが IP アドレスを返します。
次の図に、ローカルドメインの外側での名前のアドレス解決を示します。
DNS から見ると「管理ドメイン」は 1 つの単位として管理されるマシン群を構成しています。このドメインに関する情報は、ドメインに対して権限を持つ 2 つ以上のネームサーバーによって管理されます。DNS ドメインはマシンを論理的にグループ分けしたものですが、小規模のビジネスにおいて全マシンが Ethernet に接続されている場合のように、ドメインのグループがマシンの物理的グループと対応している場合もあります。同様に、ローカルの DNS ドメインには、大学の大規模なネットワークのすべてのマシンが入っていることがあります。これらのマシンは、コンピュータサイエンスの学科や管理部門に属しています。
たとえば、Ajax という会社がサンフランシスコとシアトルの 2 つのサイト持っているとします。そして、Retail.Sales.Ajax.com. ドメインがシアトルにあり、Wholesale.Sales.Ajax.com. がサンフランシスコにあるとします。また、Sales.Ajax.com. ドメインが 2 つの市に分かれているとします。
各管理ドメインは、固有のサブドメイン名を持たなければなりません。さらに、ネットワークをインターネットに接続するのであれば、そのネットワークの属する管理ドメインはすでに登録されたものでなければなりません。ドメイン名とドメインの登録の詳細については、「インターネットへの参加」の節を参照してください。
すでに説明したように、管理ドメイン内のネームサーバーは、DNS データベースを保持しています。また、このネームサーバーは in.named デーモンを実行して DNS サービスを実装します。in.named は、パブリックドメインの TCP/IP プログラムであり、Solaris オペレーティング環境に含まれています。
in.named デーモンは、カリフォルニア大学バークレー校で開発されたので、Berkeley Internet Name Domain service (BIND) と呼ばれることもあります。
各ドメインには、マスターサーバーが 1 つと、バックアップ用のスレーブサーバーが 1 つ以上必要です。マスターサーバーとスレーブサーバーの詳細については、「DNS の実装」を参照してください。
in.named デーモンを正しく機能させるには、1 つの構成ファイルと 4 つのデータファイルが必要です。
マスターサーバーの成ファイルは、/etc/named.conf. です。この構成ファイルには、ドメイン名と、ホスト情報を含むファイル名が記述されています。named.conf ファイルの詳細については、「named.conf ファイル」を参照してください。
内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。名前の付け方への柔軟性が高いために、他のサイトで作業をしたり、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 といった名前を使っています。
必要なデータファイルは次のとおりです。
/var/named/named.ca。named.ca ファイルの詳細については、「named.ca ファイル」を参照してください。内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。
/var/named/hosts。hosts ファイルの詳細については、「hosts ファイル」を参照してください。
hosts という名前はファイルの役割や内容を表す総称名です。ただし、この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にします。最も一般的な名前の例は、db.domainname です。たとえば、doc.com ドメインの hosts ファイルの名前は db.doc となります。
ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts ファイルの名前は db.doc、もう一方の名前は db.sales とします。
/var/named/hosts.rev。hosts.rev ファイルの詳細については、「hosts.rev ファイル」を参照してください。
hosts.rev という名前は、ファイルの役割や内容を表す総称名です。ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts.rev ファイルを置き、各ゾーンの hosts.rev ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つを doc.rev、もう 1 つを sales.rev という名前にするとよいでしょう。
/var/named/named.local。named.local ファイルの詳細については、「named.local ファイル」を参照してください。内部で一貫性が取れていれば、このファイルには任意の名前を付けることができます。
インクルードファイルは、DNS データファイルの中の $INCLUDE() 文で指定された任意のファイルです。$INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。「$INCLUDE ファイル」を参照してください。
参考のため、次の表では上で述べた BIND ファイル名を比較します。
表 3-1 ファイル名
Solaris |
O'Reilly その他 |
カリフォルニア州立大学バークレイ校 |
ファイルの内容と役割 |
---|---|---|---|
/etc/named.conf (全て同じファイル名) |
BIND 8.1 では新たに named.conf ファイルを追加して、従来の named.boot ファイルと置きかえる。この構成ファイルにはセキュリティ、スタートアップオプション、ロギングが追加されている。このファイルによって、稼動中のサーバーの種類を指定して、すべてのゾーンまたはサーバーではなく、ゾーンごとまたはサーバーごとにオプションを選択的に適用する。ドメイン名とデータファイル名が記述されている |
||
/etc/resolv.conf (全て同じファイル名) |
各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す |
||
named.ca |
db.cache db.root |
root.cache |
ルートサーバー名とそのアドレスがリストされている |
総称名: hosts 例:db.docdb.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 |
ローカルループバックインタフェース (ローカルホスト) 用のアドレスを指定する |
$INCLUDE ファイル (全てで同じ規則) |
データファイル内の $INCLUDE() 文によって指定されるファイル |
「ドメイン名」とは、ローカルネットワークの中で DNS 管理ファイルを共有する複数のシステムを 1 つのグループとして扱って、そのグループに付けた名前のことです。ドメイン名は、ネットワーク情報サービスデータベースが正常に動作するために必要です。
DNS がデフォルトで使用するドメイン名は resolv.conf ファイルに指定されています。
resolv.conf ファイルがない場合、あるいは resolve.conf ファイルにデフォルトのドメイン名が指定されていない場合で、しかも、エンタープライズレベルで使っているネームサービスが NIS+ または NIS のどちらかである場合は、Sun が実装する DNS はそれらのサービスからデフォルトのドメイン名を取得します。
resolv.conf ファイルがない場合、あるいは resolv.conf ファイルにドメイン名が指定されていない場合で、しかも、NIS+ と NIS のどちらも使っていない場合は、そのドメインを指定するすべてのマシンに resolv.conf ファイルを追加するか、LOCALDOMAIN
環境変数を設定しなければなりません。
各種 DNS 関連ファイルを使用する場合、ドメイン名の末尾のドットには次のような規則があります。
hosts、hosts.rev、named.ca、named.local の各データファイルの中では、ファイル名の末尾にドットを付けます。たとえば、sales.doc.com は、これらのファイルの中では有効です。
named.boot ファイルまたは resolv.conf ファイルの中では、ドメイン名の末尾にドットを付けません。たとえば、sales.doc.com は、これらのファイルの中では有効です。
あるマシンを DNS クライアントにするには、「リゾルバ」を実行する必要があります。リゾルバはデーモンでも単一のプログラムでもなく、アプリケーションによって使用される動的ライブラリルーチンの集合です。マシン名を知る必要があるときに、このライブラリが使用されます。リゾルバの機能はユーザーの照会を解決することです。このために、リゾルバはネームサーバーに照会します。するとネームサーバーは要求された情報か、または他のサーバーに照会する旨を返します。一度リゾルバを設定すれば、そのマシンはネームサーバーに DNS サービスを要求できるようになります。
DNS ネームサーバーは、いくつかのファイルを使用して、そのデータベースを読み込みます。リゾルバのレベルでは、必要な情報を取得できるサーバーのアドレスを登録するファイル (/etc/resolv.conf) が必要です。リゾルバは resolv.conf ファイルを読み取り、ローカルドメインの名前とネームサーバーの位置を見つけます。リゾルバはローカルドメイン名を設定し、リゾルバルーチンに指示して、登録されたネームサーバーに情報を照会させます。通常、ネットワーク上の各 DNS クライアントシステムの /etc ディレクトリには、resolv.conf ファイルがあります。クライアントに resolv.conf ファイルがない場合は、デフォルトにより IP アドレス 127.0.0.1 にあるサーバーが使用されます。
リゾルバがホストのアドレス (またはアドレスに対応する名前) を探さなければならないときには、照会パッケージを構築し、/etc/resolv.conf に登録されたネームサーバーにこれを送信します。サーバーは、その照会にローカルに応答するか、または他のサーバーのサービスを使ってリゾルバに答えを返します。
あるマシンの /etc/nsswitch.conf ファイルで hosts:dns (または hosts 行に dns を含む別のパターン) が指定されていると、リゾルバのライブラリが自動的に使用されます。nsswitch.conf ファイルが dns より前に、他のネームサービスを指定した場合、最初にそのネームサービスに対してホスト情報を問い合わせ、要求されたホストの情報が見つからなかった場合にだけリゾルバのライブラリが使用されます。
たとえば、nsswitch.conf ファイル内の hosts の行で hosts:nisplus dns と指定されている場合、ホストの情報を得るために NIS+ ネームサービスが最初に検索されます。NIS+ で情報が見つからない場合は、DNS リゾルバが使用されます。NIS+ や NIS といったネームサービスではそれ自身のネットワーク内にあるホストに関する情報だけを保持しているため、スイッチファイルに hosts:nisplus dns 行を指定すると、ローカルホストの情報に対しては NIS+ が使用され、インターネット上の遠隔ホストの情報に対しては DNS が使用されることになります。
DNS クライアントには、次の 2 種類があります。
クライアント専用
クライアント専用の DNS クライアントは in.named を実行せず、代わりにリゾルバを参照します。リゾルバはドメインに対するネームサーバーのリストを保持しているので、リゾルバに問い合わせが転送されます。
クライアント兼サーバー
クライアント兼サーバーの DNS クライアントは、クライアントマシンのリゾルバによって転送されてきた問い合わせを解決するために in.named で提供されるサービスを使用します。
resolv.conf ファイルの機能については、resolv.conf(4) のマニュアルページを参照してください。
resolv.conf ファイルの設定方法については、「resolv.conf ファイルの設定」を参照してください。
BIND 8.1 では、新たに構成ファイル /etc/named.conf を追加して、/etc/named.boot ファイルと置き換えました。/etc/named.conf ファイルは、マスター、スレーブ、キャッシュ専用のネームサーバーを確立します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。
/etc/named.conf ファイルには、次の機能を実装するための文が含まれます。
アクセス制御リスト(ACL) によるセキュリティ。このリストには、NIS+ ホストが読み取り権と書き込み権を持っている IP アドレスの集まりが定義されている
ロギング動作の指定
この構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、 in.named によって読み取られます。そして、in.named が他のサーバーや、指定されたドメインのローカルデータファイルに対して実行されるようにします。
named.conf ファイルは、いくつかの文とコメントで構成されています。文はセミコロンで終わります。一部の文には、文のブロックを記述することができます。ブロック内の各文もセミコロンで終わります。
表 3-2 named.conf で使用する文acl |
アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。アドレスの一致リストは、1 つ以上の IP アドレス (ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。名前を付けたIP アドレスの一致リストは、他の場所で使用する前に acl 文で定義されている必要がある。前方参照は不可 |
include |
include 文がある箇所にインクルードファイルを挿入する。include を使用することで、より管理しやすいまとまりに構成情報を分割することができる |
key |
特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。server 文を参照 |
logging |
サーバーが記録するログの種類とログメッセージの送り先を指定する |
options |
グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する |
server |
遠隔ネームサーバーに関して、指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用する |
zone |
ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用する |
options { directory "/var/named"; datasize 2098; forward only; forwarders { 99.11.33.44; }; recursion no; transfers-in 10; transfers-per-ns 2; allow-transfer { 127.0.1.1/24; }; }; logging { category queries { default_syslog; }; }; include "/var/named/abcZones.conf" // マスターファイルの名前 zone "cities.zn" { type master; file "db.cities.zn"; }; zone "0.0.127.in-addr.arpa" { type master; file "db.127.cities.zn"; }; zone "168.192.in-addr.arpa" { type master; file "db.cities.zn.rev"; }; zone "sales.doc.com" { type slave; file "slave/db.sales.doc"; masters { 192.168.1.151; }; }; zone "168.192.in-addr.arpa" { type slave; file "slave/db.sales.doc.rev"; masters { 192.168.1.151; }; }; |
大規模な会社であれば、多くのドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。次の図に、ある会社に存在するドメインの階層構造の例を示します。この会社の最上位のドメイン、すなわちルートドメインは ajax.com で、その下に sales.ajax.com、test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。
DNS クライアントは、そのドメインをサポートしているサーバーだけにサービスを要求します。クライアントの必要としている情報がそのドメインサーバーにない場合、要求は親サーバーに転送されます。親サーバーは、1 つ上の階層のドメインサーバーです。要求が最上位のサーバーに達した場合、最上位のサーバーはクライアントのドメインが有効かどうか調べます。ドメインが有効でない場合、サーバーは「not found」というメッセージをクライアントに返します。ドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。
次の図に示したドメインの階層は、グローバルなインターネット上でサポートされる巨大な DNS 名前空間の「枝葉」のようなものです。
それは、ピリオド (.) で表されるルートディレクトリと、最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。次の図の com ドメインは、インターネットに存在する最上位の組織ドメインの 1 つです。
現在、組織的な階層の名前空間は、次の表に示した最上位のドメインに分けられます。将来、これ以外にも最上位の組織ドメインが追加される可能性があります。
表 3-3 インターネットの組織ドメイン
ドメイン |
目的 |
---|---|
com |
営利団体 |
edu |
教育機関 |
gov |
行政機関 |
mil |
軍事組織 |
net |
ネットワークサポートセンター |
org |
非営利団体 |
int |
国際組織 |
地理的な階層においては、各国に対して 2、3 文字の識別子が割り当てられ、それが、各国に対する公式名として用いられます。たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。
インターネットのルートドメイン、すなわち最上位のドメイン (組織的および地理的) は、様々なインターネット運営体によって管理されています。規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。
DNS ドメインはドメイン名を持つ必要があります。インターネットに接続しないで、ネームサービスとして DNS を使用する場合は、ドメインやサブドメインに任意の名前を付けることができます。ただし、インターネットに参加する場合は、そのドメイン名をインターネット運営体に登録する必要があります。
インターネットに参加する場合は、次の手順に従います。
上記のことを行うには、次の 2 つの方法があります。
適切なインターネット運営体またはその代理団体と直接連絡をとる方法
インターネットサービスプロバイダ (ISP) と契約する方法。ISP は、コンサルティングから実際の接続まで広範なサービスを提供している
ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。たとえば、図 3-5 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。したがって、そのインターネットドメイン名は ajax.com となります。
次の図に、ajax.com ドメインがインターネット上の DNS 名前空間のどこに位置しているのかを示します。
ajax.com のサブドメインには、次のような名前があります。
sales.ajax.com test.ajax.com manf.ajax.com |
DNS ではドメイン名を大文字にすることは可能ですが、必須ではありません。次に、マシン名とドメイン名の例を挙げます。
boss.manf.ajax.com quota.sales.ajax.com |
インターネットでのドメインの管理は、ドメイン内のホスト名に対する権限を各ドメインに保証し、各ドメインがそれより下位のレベルに権限を委任することによって行われます。したがって、com ドメインはそのドメイン内のホスト名に対して権限があります。また com ドメインは、ajax.com ドメインに対して編成の権限を与え、そのドメイン内の名前に対する権限を委任します。それを受けて ajax.com はドメイン内のホストに名前を割り当て、sales.ajax.com、test.ajax.com、manf.ajax.com の各ドメインの編成を承認します。
ドメイン名にローカルドメインから DNS のルートドメイン (.) までのすべての DNS のドメインが含まれているとき、そのドメイン名は「完全指定されている」といいます。概念的には、完全指定ドメイン名は、UNIX ファイルの絶対パス名と同様に、ルートへのパスを示しています。しかし、完全指定ドメイン名を読む場合、左から右に進むにしたがって最下位から最上位となります。したがって、完全指定ドメイン名は次のような構文になっています。
ajax ドメインとそのサブドメインの完全指定ドメイン名は、次のとおりです。
ajax.com. sales.ajax.com. test.ajax.com. manf.ajax.com. |
ここで、各名前の一番右に付けられたドット (.) に注意してください。
ドメインの DNS サービスは、ネームサーバーの集合で管理されます。ネームサーバーは、単一のドメインまたは複数のドメイン、あるいは複数のドメインとその下のサブドメインの一部または全部を管理できます。あるネームサーバーによって管理される名前空間の一部は、「ゾーン」と呼ばれます。したがって、ネームサーバーはゾーンに対して権限があるといわれます。ネームサーバーの責任者は、「ゾーン管理者」とも呼ばれます。
ネームサーバーのデータベース内のデータは、「ゾーンファイル」と呼ばれます。ゾーンファイルの 1 つには、IP アドレスとホスト名が格納されています。ftp または telnet のようなユーティリティでホスト名を用いて遠隔ホストに接続しようとすると、DNS は名前のアドレスマッピングを実行し、ゾーンファイルの中でホスト名を探して、IP アドレスに変換します。
たとえば、上の図で示した Ajax ドメインは、最上位のドメイン (Ajax) 、4 つのサブドメイン、そして 5 つのサブサブドメインから構成されます。このドメインは、4 つのゾーンに分けられます。そして、Ajax ネームサーバーは、Ajax 、Sales 、Retail 、Wholesale の各ドメインからなるゾーンを管理します。Manf と QA の両ドメインは別のゾーンで、自分自身のネームサーバーからサービスを受けます。Corp ネームサーバーは Corp、Actg、Finance、Mktg ドメインからなるゾーンを管理します。
DNS データベースには、マシンのホスト名を見つけだすキーとして IP アドレスを用いるゾーンファイルもあります。このファイルで IP アドレスのホスト名解決が可能になります。このプロセスを、「逆解決」または、より一般的には「逆マッピング」と呼びます。逆マッピングは基本的にはメッセージを送ってきたマシンの識別情報を確認したり、ローカルホスト上での遠隔操作を許可したりするために使用されます。
in-addr.arpa ドメインは、DNS 名前空間において概念的な存在であり、認証 (許可) のためにドメインでなく IP アドレスを用います。このドメインは、ゾーンの一部ですが、これによってアドレスから名前のマッピングが可能になります。
DNS ドメイン名は、一番左が最下位のサブドメイン、一番右がルートとして読まれるので、in-addr.arpa ドメインでも、IP アドレスは最下位のレベルからルートになるように理解されます。すなわち、IP アドレスは逆転します。たとえば、あるホストの IP アドレスが 192.168.21.165 であるとします。in-addr.arpa ゾーンファイルでは、そのアドレスは 165.21.200.168.in-addr.arpa. と記述されます。ここで最後のドットは、in-addr.arpa ドメインのルートを示しています。
この章では、DNS (Domain Name System) の管理方法について説明します。
この章の内容は次のとおりです。
ここでは、doc.com ドメインのサーバーで使用する簡単な resolv.conf(4) ファイルの例を示します。
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 192.168.0.0 nameserver 192.168.0.1 |
このファイルの最初の行では、ドメイン名を次の書式で指定します。
domain domainname |
ここで、domainname は インターネット管理組織(このドキュメントの執筆時点では InterNIC。日本では JPNIC) に登録されている名前です。
ドメイン名の末尾にスペースまたはタブを使うことはできません。ドメイン名の最後の文字を入力したら、必ずキャリッジリターンで強制改行してください。
2 行目には、サーバー自体を次の書式で指定します。
nameserver 192.168.0.0 |
それ以降の行では、スレーブ DNS ネームサーバーまたはキャッシュ専用ネームサーバー の IP アドレスを 1 つまたは 2 つ指定します。リゾルバはこれらの行を照会して該当するアドレスを識別します。各行の書式は次のとおりです。
nameserver IP_address |
IP_address には、スレーブ DNS ネームサーバーまたはキャッシュ専用ネームサーバー の IP アドレスを指定します。リゾルバは、必要な情報が見つかるまで、ここに指定されている順番どおりにネームサーバーを探していきます。
DNS 用のネットワークを構成する場合は、クライアントとサーバーを設定する必要があります。
DNS サーバーを設定する前に、クライアントを設定します。
/etc/resolv.conf ファイルを作成します。
次に、doc.com ドメインのクライアント (非サーバー) マシン用の簡単な resolv.conf ファイルの例を示します。
; Sample resolv.conf file for the machine polaris domain doc.com ; try local name server nameserver 10.0.0.1 ; if local name server down, try these servers nameserver 192.168.16.6 nameserver 192.168.16.7 ; sort the addresses returned by gethostbyname(3c) sortlist 130.155.160.0/255.255.240.0 130.155.0.0 |
/etc/resolv.conf ファイルの最初の行では、ドメイン名を次の書式で指定します。
domain domainname |
ここで、domainname は インターネット管理組織(このドキュメントの執筆時点では InterNIC。日本では JPNIC) に登録されている名前です。
ドメイン名の末尾にスペースまたはタブを使うことはできません。ドメイン名の最後の文字を入力したら、必ずキャリッジリターンで強制改行してください。
2 行目では、ループバックネームサーバーを次の書式で指定します。
nameserver 10.0.0.1 |
それ以降の行では、DNS マスターネームサーバー、DNS スレーブネームサーバー、またはキャッシュ専用ネームサーバー の IP アドレスを最大 3 つまで指定します。4 つ以上指定することはできません。各行の書式は次のとおりです。
nameserver IP_address |
IP_address には、マスターDNS ネームサーバーまたはスレーブ DNS ネームサーバーの IP アドレスを指定します。リゾルバは、必要な情報が見つかるまで、ここに指定されている順番どおりにネームサーバーを探していきます。
/etc/resolv.conf ファイルの 5 行目では、アドレス sortlist を次の書式で指定します。
sortlist addresslist |
addresslist は、gethostbyname(3c) によって戻されるアドレスのソート順序を示します。上記の列では、gethostbyname は、IP アドレス 130.155.0.0 より先に 1 組のネットマスク 130.155.160.0/ 255.255.240.0 を戻します。
/etc/nsswitch.conf ファイルを変更します。
「NIS」。エンタープライズレベルで主として使っているネームサービスが NIS で、設定に問題がない場合、DNS はすでに使用可能になっています。
「ファイルベース」。エンタープライズレベルで主として使っているネームサービスが /etc ファイルベース、または NIS+ の場合は、次の手順に従います。
スーパーユーザーになります。
/etc/nsswitch.conf ファイルを開きます。
DNS は、ホスト情報のソースとして、「唯一の」ソースとしても「追加の」ソースとしても使用できます。/etc/nsswitch.conf の hosts 行を次のいずれかのように変更して、DNS をホスト情報のソースとすることを指定します。
hosts: files dns |
または
hosts: nis dns [NOTFOUND=return] files |
または
hosts: dns nis [NOTFOUND=return] files |
NIS クライアントの場合は、上記の指定をしないでください。この指定をすると、名前を見つけることができない場合に 2 度 DNS から検索することになります。
ホスト情報のソースとして DNS を指定します。
ファイルを保存してリブートします。
スーパーユーザーになります。
サーバーを DNS クライアントとして設定します (サーバーの resolv.conf ファイルの設定も含む)。詳細については、「DNS クライアントの設定」を参照してください。
起動ファイルを設定します。詳細については、「起動ファイルの例」を参照してください。
データファイルを設定します。次の 4 つのデータファイルを設定する必要があります。
named.ca
hosts
hosts.rev
named.local
サーバーの初期設定を行います。詳細については、「サーバーの初期設定」を参照してください。
サーバーをテストします。詳細については、「インストール結果の確認」を参照してください。
DNS の最も一般的な役割は、ローカルなネットワークをインターネットに接続することです。インターネットに接続するためには、親ドメインの管理者にネットワークの IP アドレスを登録してもらう必要があります。管理者は、ネットワークの地理的な位置と親ドメインの種類によって異なります。ドメイン管理者にネットワークを登録してもらう方法については、本書では説明をしていません。
マスターサーバーには、次の 2 つの種類があります。
「ゾーンマスターサーバー」。各ゾーンには、そのゾーンの「マスター」マスターサーバーが 1 つあります。ゾーンの「マスター」マスターサーバーは、そのゾーンの「正規」サーバーです。
「ゾーンスレーブサーバー」。 ゾーンには、1 つ以上の「スレーブ」マスターサーバーがあります。「スレーブ」マスターサーバーは、その DNS データをゾーンのマスターサーバーから入手します。
サーバーをある特定のゾーンのマスターサーバーに指定する場合は、そのサーバーの named.boot ファイルに 3 つのマスターレコードを作成します。
ゾーンの「マスター」レコードを作成します。
このレコードは、そのサーバーをマスターサーバーとして使用するゾーンを指定し、正規の hosts ファイルの場所を示すものです。この「マスター」レコードは、次の 3 つのフィールドで構成されます。
第 1 フィールド - サーバーを「マスター」サーバーとして指定する
第 2 フィールド - 「マスター」サーバーが機能するゾーンを指定する
次に示す起動ファイルの行は、あるサーバーを doc.com ゾーンで「マスター」サーバーとして使い、正規の hosts ファイルとして db.doc を使うことを示すものです。
master doc.com db.doc |
このレコードは、そのサーバーを逆アドレスマッピング (つまり、doc.com の逆アドレスドメイン) の「マスター」サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「マスター」レコードは、次の 3 つのフィールドで構成されます。第 1 フィールドではサーバーを「マスター」サーバーとして指定します。第 2 フィールドでは対象のゾーンを指定します。第 3 フィールドでは hosts.rev ファイルを指定します。
あるゾーンにおける逆アドレスドメインは、そのゾーンにおける IP アドレスを逆にならべ、最後に in-addr.arpa を配したものです。たとえば、doc.com ゾーンの IP アドレスが 10.0.0. だとすると、逆アドレスドメインは 0.0.10.in-addr.arpa になります。
次に示す起動ファイルの行は、そのサーバーを doc.com ゾーンの逆アドレスドメインで「マスター」サーバーとして使い、正規の hosts ファイルとして doc.rev を使うことを示すものです。
master 0.0.10.in-addr.arpa doc.rev |
ローカルループバックインタフェースまたはホストの逆アドレス関連の「マスター」レコードを作成します。
このレコードは、そのサーバーをループバックホストの「マスター」サーバーとして使うことを指定し、正規の hosts ファイルの場所を示すものです。この「マスター」レコードは、3 つのフィールドで構成されます。第 1 フィールドではサーバーを「マスター」サーバーとして指定します。第 2 フィールドではループバックホストの逆アドレスを指定します。第 3 フィールドでは hosts ファイルを指定します。
ループバックホストは常に、0.0.10.in-addr.arpa といった書式で識別されます。
次に示す起動ファイルの行は、そのサーバーをループバックホストの逆アドレスドメインで「マスター」サーバーとして使い、正規の hosts ファイルとして named.local を使うことを示すものです。
master 0.0.10.in-addr.arpa named.local |
「スレーブ」サーバーは、ゾーンに関するデータのコピーを保持しています。 マスターサーバーはそのデータをスレーブサーバーに送り、権限を任せます。クライアントは、DNS 情報をスレーブサーバーに照会できます。スレーブサーバーを使用することによって、負荷が複数のマシンに分散され応答時間を短縮してネットワークのオーバーヘッドを減らすことができます。また、スレーブサーバーは、マスターサーバーが使用できないときに代わりの機能を果たします。
スレーブサーバーは、in.named の起動時に所定のゾーンに関するすべてのデータをマスターサーバーに要求します。以降、スレーブサーバーはデータベースを更新する必要があるかどうかを調べるためにマスターサーバーを定期的にチェックします。最新のゾーンデータベースをマスターサーバーからスレーブサーバーに送信するプロセスを「ゾーン転送」と呼びます。このため、スレーブサーバー上のデータファイルを変更するのではなく、ゾーンのマスターサーバー上のデータファイルを変更します。その後、スレーブサーバーのファイルがマスターサーバーから更新されます。
サーバーを所定のゾーンのスレーブサーバーに指定する場合は、そのサーバーの named.boot ファイルに「スレーブ」レコードを作成します。別々のレコードで、サーバーをそのゾーン、逆アドレスドメイン、およびループバックホストのスレーブサーバーとして指定できます。
この「スレーブ」レコードは、次の3 つのフィールドで構成されます。
第 1 フィールド - サーバーを「スレーブ」サーバーとして指定する
第 2 フィールド - 対象のゾーンを指定する
第 3 フィールド - そのゾーンのマスターサーバーの IP アドレスを指定する。スレーブサーバーはマスターサーバーから正規データを取得する。
「スレーブ」レコードでは、必須フィールドに続けて 1 つまたは複数の任意指定のフィールドを設けることができます。任意指定のフィールドには次の種類があります。
「スレーブサーバー」
マスターサーバーの IP アドレスに続けて、他のスレーブサーバーの IP アドレスを指定できます。この指定により、スレーブサーバーが情報を入手できるソースが増えます。一方、状況によっては、スレーブサーバーの IP アドレスを指定することで、パフォーマンスが低下することも考えられます (IP アドレスがマルチホームマスターサーバーの別のネットワークアドレスである場合を除く)。
「バックアップファイル」
マスターサーバー (および任意指定のスレーブサーバー) の IP アドレスに続けて、バックアップ用 hosts ファイルの名前を指定できます。バックアップファイル名を指定すると、スレーブサーバーはそのバックアップファイルからデータをロードし、続いてマスターサーバー (および任意指定のスレーブサーバー) をチェックしてバックアップファイルのデータが最新のものであるかどうかを確認します。その結果、最新ではないことが分かった場合は、マスターサーバーから受け取った情報に基づいてバックアップファイルのデータが更新されます。
次に示す起動ファイルの行は、あるサーバーを doc.com ゾーンとその逆アドレスドメインのスレーブサーバーとして使うことを示します。さらに、そのスレーブサーバーが IP アドレス 172.16.0.1 のマスターサーバーから正規データを受け取り、サーバー 172.16.0.2 をゾーンデータのスレーブ情報源として使い、最初に doc.com.bakup ファイルからデータをロードすることを示します。
slave doc.com 129.146.168.119 192.146.168.38 doc.com.bakup slave 4.0.32.128.in-addr.arpa 129.146.168.119 |
この章で紹介するさまざまなサンプルファイルの中で、上記のサンプル起動ファイル行はサーバー dnsslave (IP アドレス 192.146.168.38 の sirius マシンのエイリアス) の起動ファイルに対応しています。
1 台のサーバーは、1 つまたは複数のゾーンのマスターサーバーとして機能でき、さらに 1 つまたは複数のゾーンのスレーブサーバーとしても機能できます。起動ファイル内のエントリの組み合わせによって、サーバーがマスターサーバーになるかスレーブサーバーになるかが決まります。
DNS データのキャッシュを保持するという意味では、すべてのサーバーがキャッシュサーバーであるといえます。キャッシュ専用 (スタブ) サーバーは、in-addr.arpa. ドメイン以外のどのゾーンのマスターサーバーでもないサーバーです。
キャッシュ専用サーバーは正規データは一切保持しません。キャッシュ専用サーバーは照会を行い、in.named ファイルにリストされているホストを照会して必要な情報を探します。つまり、キャッシュ専用サーバーは、正規のネームサーバーと同様の照会を行いますが、正規データそのものは一切保持しません。
次に、キャッシュ専用サーバーの起動ファイルの例を示します。
; ; Sample named.boot file for caching-only name server ; ; type domain source file or host ; directory /var/named cache . named.ca master 0.0.127.in-addr.arpa named.local |
サーバーをキャッシュ専用サーバーとして指定するための行は特に必要ありません。起動ファイル内に slave または master など、権限に関する行がないということが、キャッシュ専用サーバーであると判断する根拠になります。
ただし、以下が必要です。
起動ファイルの directory 行
起動ファイルの master 0.0.127.in-addr.arpa 行
ブートファイルの cache. named.ca 行
この節では、マスターネームサービスとして NIS または NIS+ を使用する場合に、/etc/passwd、/etc/shadow、/etc/group の各ファイルで使用される +/- 構文との互換性を確保する方法について説明します。
スーパーユーザーになります。
/etc/nsswitch.conf ファイルをオープンします。
passwd と groups の各ソースを compat に変更します。
NIS を使う場合は次のように入力します。
passwd: compat group: compat |
NIS+ を使う場合は次のように入力します。
passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus |
これにより Solaris 1.x リリースと同じ構文を使用できます。ファイル内の +/- エントリに従って、/etc ファイルと NIS マップ (または NIS+ テーブル) を検索します。
-+ または -+ netgroup を /etc/passwd、/etc/shadow、/etc/group の各ファイルに追加します。
-+ または -+ netgroup のエントリを /etc/shadow および /etc/passwd に追加できないと、ローカルファイルに登録されていないユーザーは以後ログインできなくなります。
ファイルを保存して、システムをリブートします。
ライブラリ関数には nsswitch.conf ファイルが変更されてもスイッチ情報を読み直さないものがあります。そのため、マシンをリブートして、nscd とこれらのライブラリ関数が最新スイッチの情報を持つようにする必要があります。
サーバーの初期設定を行う場合は、次の手順に従います。
スーパーユーザーになります。
前出の節の説明に従って、named.conf 構成ファイルとその他必要なファイルをインストールします。
in.named を実行します。
#/usr/sbin/in.named
コマンド行から in.named を実行する代わりに、リブートするという方法もあります。
起動ファイルとデータファイルを設定し、in.named を実行したら、インストールが正しく行われたかどうかを確認してください。
スーパーユーザーになります。
syslog ファイルをオープンして、エラーメッセージが書き込まれていないかどうか確認します。
一般的な DNS エラーメッセージと障害追跡情報については、第 6 章「DNS の障害追跡 (参照情報)」を参照してください。
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」といったメッセージが表示された場合は、サーバーが起動ファイルまたはホストファイルに正しく設定されていない可能性があります。
インターネットに接続されているネットワークの場合、遠隔ドメイン名を検索します。インターネットに接続されていないネットワークの場合は、他のゾーンにサブドメインがあれば、その名前を検索します。
たとえば、インターネット上の遠隔ドメイン名 internic.net を検索するには、次のように入力します。
dnsmaster% nslookup internic.net
Server: dnsmaster.doc.com Address: 192.168.168. Name: internic.net Addresses: 192.168.0.9, 192.168.0.6, 192.168.0.5, 192.168.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: 192.168.0.1 Name: altair.doc.com Addresses: 192.168.1.2 |
正常に実行できれば、ネームサーバーはおそらく正常に機能しています。
上記のコマンドを実行しても探しているマシンが見つからない場合は、ドメインが親ドメイン (上記の例では .com) の管理元に正しく登録されていないことが原因の 1 つとして考えられます。
ネットワークにマスターサーバーやスレーブサーバーを追加できます。
スーパーユーザーになります。
DNS クライアントとしてサーバーを設定します。「クライアントの追加」を参照してください。
次のファイルを設定します。
詳細については、「DNS サーバーの設定」を参照してください。
DNS マスターサーバー内の DNS データファイルの 1 つに対して、ホストの追加および削除、またはそれ以外の何らかの変更、あるいは DNS データファイルの修正を行なったときには、以下も行なってください。
スレーブサーバーがそのデータを変更するように、SOA リソースレコードのシリアル番号を変更します (「SOA のシリアル番号を変更する方法」を参照)。
データファイルを再度読み込んで内部データベースを更新するようにマスターサーバーの in.named に情報を与えます (「in.named に DNS データを強制的に再度読み込ませる」 を参照)。
すべての DNS データベースファイルには権限の開始 (SOA) リソースレコードがあります。DNS データベースのデータを変更したときは必ず、SOA シリアル番号を 1 増加させる必要があります。
たとえば、データファイルの SOA のシリアル番号が現在 101 で、ファイルのデータに変更を加えた場合は、シリアル番号を 101 から 102 に変更する必要があります。SOA のシリアル番号を変更しないと、ドメインのスレーブサーバーは、新しい情報でデータベースファイルのコピーを更新しません。その結果、マスターサーバーとスレーブサーバーが同期しなくなります。
hosts ファイル例の一般的な SOA レコードは、以下のとおりです。
; sample hosts file @ IN SOA nismaster.doc.com. root.nismaster.doc.com. ( 109 ; Serial 10800 ; Refresh 1800 ; Retry 3600000 ; Expire 86400 ) ; Minimum |
したがって、hosts ファイルを変更すると、シリアル番号は 109 から 110 に変更して、次にファイルを変更した場合、110 から 111 に変更します。
in.named が無事起動すると、デーモンはそのプロセス ID を /etc/named.pid ファイルに書き込みます。in.named で named.conf を再び読み込み、データベースを再度読み込ませる場合は、次の手順に従います。
この操作によって以前のキャッシュはすべて削除され、キャッシュの処理が再スタートします。
inetd から in.named を実行しないでください。これを行うとネームサーバーは繰り返し再起動され、キャッシュを持つ意味がなくなります。
クライアントを追加または削除するときは必ず、DNS マスターサーバーに格納されたデータファイルを変更してください。スレーブサーバーのファイルを変更または編集しないでください。スレーブサーバーは、SOA のシリアル番号の変化に基づいて、マスターサーバーから自動的に更新されます。
DNS ドメインにクライアントを追加するには、新しいマシンを DNS クライアントとして設定してから、新しいマシンのレコードを該当する hosts と hosts.rev の各ファイルに追加します。
たとえば、rigel というホストを doc.com ドメインに追加する場合は、次の手順に従います。
スーパーユーザーになります。
/etc/resolv.conf ファイルを rigel 上に作成します。
rigel の /etc/nsswitch.conf ファイルの hosts の行に dns を追加します。
「DNS とインターネットでのアクセス」を参照してください。
マスターサーバーの hosts ファイルに、rigel 用のアドレス (A) レコードを追加します。
rigel IN A 192.168.112 |
マスターサーバーの hosts ファイルに、rigel 用の任意指定のレコードを追加します。
任意指定のレコードには、次のものがあります。
エイリアス (CNAME)
メール交換 (MX)
既知サービス (WKS)
ホスト情報 (HINFO)
hosts.rev ファイルに rigel 用の PTR レコードを追加します。
マスターサーバーの hosts ファイルと hosts.rev ファイルの SOA シリアル番号を増やします。
サーバーのデータを再度読み込みます。
サーバーをリブートするか、次のように入力します。
# kill -HUP `cat /etc/named.pid`
DNS ドメインからクライアントを取り除く場合は、次の手順に従います。
スーパーユーザーになります。
削除するマシンの nsswitch.conf ファイルの hosts の行から dns を削除します。
マシンの /etc/resolv.conf ファイルを削除します。
マスターサーバーの hosts ファイルと hosts.rev ファイルからそのマシンのレコードを削除します。
そのマシンを示す CNAME レコードがある場合は、その CNAME レコードも hosts ファイルから削除する必要があります。
削除されるマシンによってサポートされていたサービスの代替を設定します。
マシンがマスターサーバー、メールホスト、その他必要なプロセスまたはサービスのホストである場合、そのマシンが行なっていたサービスを他のマシンで実行できるように設定する必要があります。
作業 |
説明 |
参照先 |
|
---|---|---|---|
マシンで IPv6 を使用できるようにする |
/etc/nsswitch.conf ファイルを変更して、NIS+ クライアントで IPv6 を使用できるようにする | 以下を参照 |
スーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集します。
新しい ipnodes ソースを追加して、ネームサービス (LDAP など) を指定します。
ipnodes: ldap [NOTFOUND=return] files |
ipnodes は、デフォルトでは files です。IPv4 から IPv6 への変更中すべてのネームサービスが IPv6 のアドレスを認識できるわけではないので、 デフォルトの files を使用してください。デフォルトを使用しない場合は、アドレスの解決中に不必要な遅延が生じることがあります。
ファイルを保存して、マシンをリブートします。
nscd デーモンはこの情報をキャッシュに保存して起動時にこの情報を読み取るため、 ここでマシンをリブートする必要があります。
ネットワークは大きくなっていくので、ネットワークを複数の DNS サブドメインに分割すると便利です (DNS のドメインの階層と構造については、「DNS 名前空間の階層」を参照)。
ネットワークを親ドメインと 1 つ以上のサブドメインに分割すると、負担が複数のドメインに分散して、各 DNS サーバーの負荷は減ります。この方法で、ネットワークのパフォーマンスを改善できます。たとえば、ネットワークに 900 台のマシンがあり、すべてがひとつのドメインにあるとします。この場合、1 台のマスターサーバー、1 台以上のスレーブサーバーとキャッシュ専用サーバーからなる DNS のサーバーの集合では、900 台のマシンをサポートしなければなりません。このネットワークを各ドメインが 300 台ずつの 1 つの親ドメインと 2 つのサブドメインに分割すると、マスターサーバーとスレーブサーバーの組は 3 つとなり、それぞれ 300 台だけを担当することになります。
ネットワークを物理的または組織的な構成に合うように複数のドメインに分割することによって、DNS ドメイン名はどこに対象とするマシンがあるか、電子メールのアドレスが組織のどこにあたるのかを指し示すことになります。たとえば、rigel@alameda.doc.com は、マシン rigel が Alameda というサイトにあることを意味し、電子メールのアドレス barnum@sales.doc.com は、ユーザー barnum が営業 (sales) 部署の者であることを意味します。
ネットワークを複数のドメインに分けると、すべてをひとつのドメインに置く場合よりも設定作業が増えます。また、ドメインを互いにつなぐ委託データを保持しなければなりません。一方で、複数のドメインを持つと各ドメインの保守をそれぞれの管理者またはチームに分散させることができます。
次に、ネットワークを 1 つの親ドメインと 1 つ以上のサブドメインに分割するにあたって考慮すべき点をいくつかあげます。
「サブドメインの数」。作成するサブドメインが多ければ、それだけ初期設定の作業が増え、運用時の親ドメインでの管理者の調整作業も増えます。多くのサブドメインがあれば、親ドメインのサーバーのために委任される作業もその分増加します。一方で、ドメインの数が少ないということは各ドメインが大きいということを意味し、ドメインが大きければそれをサポートするためにサーバーのスピードやメモリーが余計必要になります。
「ネットワークの分割方法」。ネットワークはどのようにでも複数のドメインに分割できます。最も一般的な方法が 3 つあります。まず、組織の構成によるもので、各部署 (営業、研究開発、製造など) に別々のサブドメインを持つ方法です。次に、地理的なもので、各サイトに別々のサブドメインを持つ方法です。最後に、ネットワークの構造によるもので、大きなネットワーク構成要素ごとに別々のサブドメインを持つ方法です。もっとも重要なのは、ドメインの構造が統一されていて論理的かつ自明であれば、管理も利用もより簡単になるということです。
「将来に対する考慮」。もっとも問題が多いのは、新しいサイトや部が増えるに従って、時間の経過とともにサブドメインが無計画に追加されて大きくなったドメインです。可能な限り、将来のドメインの拡大を見越してドメインの階層を設計してください。安定性も考慮に入れてください。最も安定しているものを基礎として、サブドメインを分けるようお勧めします。たとえば、地理的なサイトは比較的安定しているけれども、部や課が頻繁に再編成されるなら、サブドメインは組織よりも地理的な位置に基づいて決定する方が良いでしょう。一方、組織は比較的安定しているがサイトが頻繁に追加されたり変更されたりする場合は、サブドメインは組織の階層に基づいて決定する方が良いでしょう。
「広域ネットワーク (WAN) とのリンク」。ネットワークがモデムまたは専用回線で接続された複数のサイトに広がっている場合、広域ネットワーク (WAN) のリンクにドメインが広がっていないなら、パフォーマンスと信頼性は高くなります。多くの場合、WAN のリンクは連続的なネットワーク接続より遅く失敗に終わる傾向があります。サーバーが、WAN のリンク経由だけで接続できるマシンをサポートしなければならないときは、より遅いリンクを経由するトラフィックファネリングが増加することになります。この場合、もし 1 つのサイトで停電や何か他の問題が起こった場合には他のサイトのマシンにも影響が及ぶ可能性があります。(同様のパフォーマンスと信頼性の配慮は DNS ゾーンについても必要です。一般的な方法として、ゾーンを WAN のリンクに広げないようにすることをお勧めします。)
「NIS+ 互換性」。エンタープライズレベルのネームサービスが NIS+ である場合は、DNS と NIS+ のドメイン構造とサブドメイン構造が一致すると管理がより簡単になります。
「サブドメイン名」。可能な限り、サブドメインに名前を付けるのに一貫したポリシーを確立してそれを守るのが理想的です。ドメイン名が一貫していれば、ユーザーは簡単に記憶し正しく指定できます。ドメイン名はすべての DNS データファイルで重要な要素であること、サブドメインを変更すると古いドメイン名があるすべてのファイルを修正する必要があることに注意してください。したがって、安定していて変更の必要がないと思われるサブドメイン名を選択するようにしてください。サブドメイン名として manufacturing のように完全指定することもできますし、manf のように短縮して指定することもできます。しかし、あるサブドメインが短縮形で指定され他が完全指定された場合、利用者は混乱します。短縮形を使用するのであれば、名前を識別するのに十分な文字数にしてください。短かすぎる名前は利用や記憶が困難だからです。最上位のインターネットのドメイン名として使用されている名前をサブドメイン名として使わないで下さい。すなわち、org、net、com、gov、edu と、2 文字の国のコード jp、uk、ca、it 等は、すでに使用されているのでサブドメイン名として使うことはできません。
ほとんどの場合、新しいサブドメインは、新しいネットワークやマシンを接続するか、既にあるドメインを分ける場合に作成されます。どちらの場合も、プロセスはよく似ています。
新しいサブドメインを設計した後、次の手順に従って設定します。
新しいサブドメイン内のすべてのマシンが DNS クライアントとして正しく設定されていることを確認してください。
既存のドメインから新しいサブドメインを分ける場合、ほとんどのマシンは DNS クライアントの設定が既にされているはずです。新しいサブドメインを最初から構築する場合、あるいは既存のネットワークに新しいマシンを追加する場合は、正しく設定された resolv.conf ファイルと nsswitch.conf ファイルを各マシンにインストールする必要があります。
正しく設定された起動ファイルと DNS データファイルをサブドメインのマスターサーバーにインストールします。
/etc/named.conf.
/var/named/named.ca.
/var/named/hosts.
/var/named/hosts.rev.
/var/named/named.local.
サーバーのホストファイルには、サブドメイン内のマシンごとにアドレス (A) レコードと、場合によっては CNAME レコードが必要です。また、サーバーの hosts.rev ファイルには、サブドメイン内のマシンごとにポインタ (PTR) レコードが必要です。任意指定の HINFO と WKS レコードも追加できます。
既存のドメインを分割する場合は、新しいサブドメインのマシン用のレコードを親ドメインのマスターサーバーの hosts ファイルと hosts.rev ファイルから削除してください。
そのためには、現在新しいサブドメイン内にあるマシン用の A レコードを古いドメインサーバーのホストファイルから削除します。また、同じマシンの PTR レコードを古いドメインサーバーの hosts.rev ファイルから削除します。移動するマシン用の任意指定の HINFO レコードと WKS レコードも、削除する必要があります。
既存のドメインを分割する場合は、新しいサブドメイン名を、親ドメインのマスターサーバーのホストファイル内の CNAME レコードに追加します。
たとえば、aldebaran というマシンをファックスサーバーとして使っているとします。また親ドメインのサーバーのホストファイル内の CNAME レコードが次のとおりであるとします。
faxserver IN CNAME aldebaran |
新しい faxserver の CNAME レコードを、aldebaran のために、新しいサブドメインのマスターサーバーにあるホストファイル内に作成するとともに、下記のように aldebaran のサブドメインが含まれるように、親ドメインのホストファイル内の CNAME レコードも変更する必要があります。
faxserver IN CNAME aldebaran.manf.doc.com |
新しいサブドメインのサーバーの NS レコードを、親ドメインのホストファイルに追加します。
たとえば、親ドメインは doc.com で、manf.doc.com という新しいサブドメインを作成しているとします。また、このとき rigel というマシンを manf のマスターサーバーとして指定し、aldebaran をスレーブサーバーとして指定するとします。この場合、次のレコードを doc.com のマスターサーバーの hosts ファイルに追加することになります。
manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com |
新しいサブドメインのサーバー用の A レコードを、親ドメインの hosts ファイルに追加します。
引き続き上の例で考えると、次のレコードを doc.com のマスターサーバーの hosts ファイルに追加することになります。
rigel.manf.doc.com 99999 IN A 1.22.333.121 aldebaran.manf.doc.com 99999 IN A 1.22.333.136 |
サブドメインのサーバー上の named を起動します。
# /usr/sbin/in.named
コマンド行から in.named を実行する代わりに、リブートします。「in.named と DNS ネームサーバー」を参照してください。
Solaris オペレーティング環境では、コンパイル版の Berkeley Internet Name Domain (BIND) 8.2.4 を提供します。コンパイルにあたっては、より多くのサイトのニーズを満たすように各種オプションを設定しました。このコンパイル済みの BIND が要件に合わない場合は、公開されているソースコードから独自にコンパイルすることができます。
Solaris オペレーティング環境で提供される BIND バージョンのコンパイルでは、以下の選択が行われました。
「デフォルトのドメイン名」。DNS ドメイン名が /etc/resolv.conf 内または LOCALDOMAIN
環境変数で設定されていない場合、libresolv は、デフォルトのドメイン名を NIS または NIS+ のドメイン名から引用します。
「ユーティリティスクリプト」。BIND のユーティリティスクリプトは、今回の Solaris リリースには含まれていません。
「テストプログラム」。BIND のテストプログラムである dig、dnsquery、host は、今回の Solaris リリースには含まれていません。これらのテストプログラムの目的は、nslookup と nstest の目的と同様であるためです。
スーパーユーザーになります。
Korn シェルスクリプト /usr/sbin/named-bootconf を実行し、BIND 4.9.x の named.boot ファイルを BIND 8.2.4 の named.conf ファイルに変換します。
Solaris 9 では named.boot ファイルは無視されます。
nsswitch.conf ファイルは、クライアントの DNS 転送とインターネットへのアクセスを管理します。NIS クライアントには、転送機能が含まれています。NIS+ クライアントにはこの機能がありません。次の手順を参照してください。
この NIS 実装では、該当するサーバー上に /etc/resolve.conf ファイルが存在する場合は、ypstart が -d オプションで「自動的に」 ypserv デーモンを起動して DNS に要求を転送します。DNS への転送を停止する場合は、 /usr/lib/netsvc/yp/ypstart スクリプトを編集して、-d オプションを ypserv コマンドから削除してください。その後マシンをリブートする必要があります。
スーパーユーザーになります。
hosts.byname マップと hosts.byaddr マップに YP_INTERDOMAIN キーを設定します。Makefile の次の行 (ファイルの先頭の行) を次のように変更してください。
#B=-b B= |
上記の行を次のように変更します。
B=-b #B= |
これで、マップの作成時に makedbm が -b フラグを使って起動されるようになるため、YP_INTERDOMAIN が ndbm ファイルに挿入されます。
マップを作成し直します。
# /usr/ccs/bin/make hosts
有効な名前のサーバーを指定している /etc/resolv.conf ファイルが NIS サーバーに存在することを確認します。
各サーバーを ypstop コマンドで停止します。
# /usr/lib/netsvc/yp/ypstop
各サーバーを ypstart コマンドで再起動します。
# /usr/lib/netsvc/yp/ypstart
Solaris 2 以降が実行されていない NIS サーバーを使用している場合は、ホストマップに YP_INTERDOMAIN キーが存在することを確認してください。また、マスターサーバーとスレーブサーバーが「異なる」バージョンの Solaris を実行している場合は、問題が発生することがあります。 次の表に、このような問題を回避するためのコマンドがまとめてあります。「4.0.3+」という表記は、「SunOS のリリース 4.0.3 以降」であることを意味します。makedbm -b コマンドは、Makefile の「-B」変数への参照です。
スレーブサーバー |
マスターサーバー |
||
---|---|---|---|
|
4.0.3+ |
Solaris NIS |
|
4.0.3+ |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr -b |
マスターサーバー: ypserv -d スレーブサーバー: ypxfr -b |
Solaris NIS |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: makedbm -b スレーブサーバー: ypxfr |
マスターサーバー: ypserv -d スレーブサーバー:ypxfr が存在する resolve.conf または ypxfr -b |
Solaris オペレーティング環境には、リゾルバを構成している動的ライブラリルーチンが含まれています。
この章の内容は次のとおりです。
この節では、この章で説明する例を基にして、サンプルのインターネット接続ネットワークを想定し、そこで使う 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 |
各ゾーンにマスターサーバーとスレーブサーバーが 1 台ずつあり、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 |
sales.doc.com のスレーブサーバー |
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 master files cache . named.ca master doc.com db.doc master 0.0.127.in-addr.arpa named.local master 6.45.123.in-addr.arpa doc.rev ;This system is also the slave for the sales.doc.com domain slave sales.doc.com 111.22.3.4 db.sales slave 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 master files cache . named.ca master sales.doc.com db.sales master 0.0.127.in-addr.arpa db.127.0.0 master 3.22.111.in-addr.arpa db.192.168.8 |
; named.boot file on the dnsecond (deneb) directory /var/named cache . named.ca slave doc.com 123.45.6.1 doc.com slave 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. N 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 ファイルです。どちらのサーバーも同じ 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. 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 |
DNS デーモン in.named が使用するすべてのデータファイルは、標準リソースレコード書式で記述されます。標準リソースレコード書式では、ファイルの各行は、リソースレコード (RR) と呼ばれるレコードです。各 DNS データファイルには決められたリソースレコードが必要です。
最も一般的に使用されるリソースレコードのタイプを 表 5-7 に列挙します。 通常、表 5-7 に並んだ順で入力しますが、この順序は必須ではありません。
表 5-3 一般的に使用されるリソースレコードのタイプ
形式 |
説明 |
---|---|
SOA |
権限の開始 |
NS |
ネームサーバー |
A |
IPv4 インターネットアドレス (名前からアドレス) |
AAAA |
IPv6 インターネットアドレス (名前からアドレス) |
PTR |
ポインタ (アドレスから名前) |
CNAME |
正規名 (ニックネーム) |
TXT |
テキスト情報 |
MX |
メール交換 |
これ以降に示すサンプルファイルでは、@ は現在のゾーンまたは現在の起点を示します。セミコロン (;) で始まる行はコメントです。
最も簡単な方法は、サブドメインを親ドメインのゾーンに含めることです。こうすると、1 セットの DNS サーバーとデータファイルでドメインに関係なくすべてのマシンを管理できます。
単一ゾーン方式の長所は、管理が簡素化され簡単なことです。短所は 1 セットのサーバーですべてのゾーンのドメインにあるマシンを管理しなければならないということです。マシンの数が多すぎると、サーバーの負荷が大きくなり過ぎ、パフォーマンスが低下することがあります。
複数のドメインで構成されているゾーンのデータファイルには、そのゾーンに含まれる各ドメインのすべてのマシンとサーバーに関わるレコードが必要です。
複数のドメインで構成されているゾーンを設定するのも、単一ドメインで構成されているゾーンを設定するのも、必要な作業は基本的に同じです。唯一の相違は、遠隔ドメインのマシンを識別できるようにするために、hosts ファイルには完全指定のドメイン名を使用しなければならないということです。サーバーのローカルドメインにあるマシンであれば、hosts ファイルにマシン名しか指定されていなくても識別できます。しかし、他のドメインにあるマシンを識別するには、完全指定のドメイン名、つまり machine.domain という書式で指定しなければなりません。
hosts.rev ファイルと named.local ファイルに指定するサーバー名やマシン名にも、完全指定のドメイン名を使用する必要があります。ただし、これはゾーンがいくつのドメインで構成されているかには関係ありません。
複数ゾーン方式の長所は、ドメインごとにその中のマシンを管理するサーバーセットを変更できるということです。つまり、サーバーの負荷を分散させ、1 セットのサーバーに負荷が集中するのを防ぐことができます。短所は、設定時の作業がより複雑になることです。
異なるゾーンのサブドメインを設定するのは、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 つのゾーンを持つネットワークが示してあります。
全世界の DNS 管理ドメインの集合全体は「DNS 名前空間」と呼ばれる階層構造を形成しています。ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。
DNS ドメインは、UNIXTM のファイルシステムと同様、木の根に似た下に向きの枝分かれで構成されています。各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。「ドメイン」と「サブドメイン」は相対的な関係を示します。階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。
たとえば、図 5-1 において com は Acme、Ajax、AAA の各ドメインの親ドメインです。あるいは、これらのドメインは com ドメインのサブドメインということもできます。このように考えると、Ajax ドメインは 4 つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。
あるドメインには、1 つの親 (または最上位) ドメインと、(存在する場合) その下のサブドメインが含まれます。ドメインの名前は、最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。
DNS は、「名前のアドレス解決」で説明しているように、名前からアドレス (またはその逆のアドレスから名前) のマッピングを行う他に、インターネット上でメールを配信する sendmail や POP といったメール配信エージェントの役にも立っています。
インターネット上でメールを配信するのに、DNS は「メール交換レコード」(MX レコード) を用います。ほとんどの組織は、その組織内にあるホストに宛てられたインターネットから来るメールを直接配信することを許可しません。そのかわりに、1台の中央メールホスト (またはメールホストの集合) を使用して、入ってくるメールメッセージを途中で止めて宛先に振り分けます。
メール交換レコードで、ドメイン内の各マシンにサービスを提供しているメールホストが識別されるため、メール交換レコードには遠隔組織の DNS ドメイン名と、その IP アドレスまたは対応するメールホストのホスト名のいずれかが列挙されています。
DNS のネームサーバーには、in.named デーモンに加えて、named.conf という起動ファイル、resolv.conf というリゾルバファイル、4 種類のゾーンデータファイルがあります。
内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。このため、異なるサイトで作業をしようとする場合や 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.doc といった名前を使っています。
参考のため、次の表で上で述べた 3 種類の BIND ファイル名を比較します。
表 5-4 BIND ファイル名の例
Solaris |
O'Reilly その他 |
カリフォルニア州立大学バークレイ校 |
ファイルの内容と役割 |
---|---|---|---|
/etc/named.conf |
/etc/named.conf |
/etc/named.conf |
構成ファイルは、それが実行されるサーバーのタイプ、および「マスター」、「スレーブ」、または「スタブ」として機能するゾーンを指定する。また、セキュリティ、ロギング、およびゾーンに適用されるオプションの細かい細分性を定義する |
/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 |
逆マッピング (アドレスから名前) jを行うための特殊なドメイン in-addr.arpa. のゾーンを指定する |
named.local |
総称名: db.cache 例:db.127.0.0 |
named.local |
ローカルループバックインタフェースまたはローカルホスト用のアドレスを指定する |
$INCLUDE ファイル |
$INCLUDE ファイル |
$INCLUDE ファイル |
データファイル内の $INCLUDE() 文によって識別されるファイル |
このマニュアル内の例やコード例で使われている IP アドレスとネットワーク番号は、説明に具体性を持たせるために仮に決めたものです。これらの情報は、実際のネットワークやホストに使われていることがありますので、そのまま使うのは避けてください。
BIND 8.2.4 構成ファイル /etc/named.conf は、サーバーをマスターサーバー、スレーブサーバー、またはキャッシュ専用サーバーとして設定します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。
/etc/named.conf ファイルには、次の機能を実装する文が含まれています。
アクセス制御リスト(ACL) によるセキュリティ。ACL には、NIS+ ホストが読み取り/書き込み権を持つ IP アドレスの集まりが定義されている。
ログ仕様
構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、 in.named によって読み取られます。構成ファイルにより、他のサーバー (マスター、スレーブまたはキャッシュ専用サーバー) として設定されるか、あるいは初期データを取得する構成ファイルが示されます。
named.conf ファイルは、いくつかの文とコメントで構成されています。文はセミコロンで終わります。一部の文は、文のブロックを含むことができます。ブロックの中の各文もセミコロンで終わります。
named.conf ファイルは、以下の文をサポートします。
表 5-5 named.conf 文acl | アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。アドレスの一致リストは、1 つ以上の IP アドレス (ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。名前を付けたIP アドレスの一致リストは、他の場所で使用する前に acl 文で定義されている必要がある。前方参照は不可 |
include | include 文がある箇所にインクルードファイルを挿入する。include を使用することで、管理しやすいまとまりに構成情報を分割することができる |
key | 特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。server 文を参照 |
logging | サーバーが記録するログ情報と、ログメッセージの送り先を指定する |
options | グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する |
server | 遠隔ネームサーバーに関して、指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用する |
zone | ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用する |
options { directory "/var/named"; datasize 2098; forward only; forwarders { 99.11.33.44; }; recursion no; transfers-in 10; transfers-per-ns 2; allow-transfer { 127.0.1.1/24; }; }; logging { category queries { default_syslog; }; }; include "/var/named/abcZones.conf" // これはマスターファイルの名前です zone "cities.zn" { type master; file "db.cities.zn"; }; zone "0.0.127.in-addr.arpa." { type master; file "db.127.cities.zn"; }; zone "168.192.in-addr.arpa" { type master; file "db.cities.zn.rev"; }; zone "sales.doc.com" { type slave; file "slave/db.sales.doc"; masters { 192.168.1.151; }; }; zone "168.192.in-addr.arpa" { type slave; file "slave/db.sales.doc.rev"; masters { 192.168.1.151; }; }; |
named.ca ファイルによって、ルートサーバー名が確立され、そのアドレスが列挙されます。ネットワークがインターネットに接続されている場合は、named.ca には、インターネットのネームサーバーが表示されます。接続されていなければ、ローカルネットワークのルートドメインネームサーバーが表示されます。in.named デーモンは、サーバーの 1 つに接続できるまで、サーバーのリストを一巡します。そして、そのサーバーから現在のルートサーバーのリストを入手します。デーモンは、このリストを 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 です。 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. 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 の他に、ourmaster と ourslave という 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 ourmaster.private. 1.1.192.in-addr.arpa IN NS ourmaster.private. ourprivate.private. IN A 192.1.1.1 ; private. IN NS ourslave.private. 1.1.192.in-addr.arpa IN NS ourslave.private. ourslave.private. IN A 192.1.1.2 |
hosts ファイルには、ローカルゾーン内のマシンに関するすべてのデータが含まれています。このファイル名は、起動ファイル内で指定します。/etc/hosts との混同を避けるために、hosts 以外の名前を付けます。たとえば、これらのファイルに db.domain パターンを使用して名前を付けることができます。この命名方法により、doc.com と sales.doc.com ドメインのホストファイルは db.doc と db.sales になります。
hosts ファイルには、ゾーン内にある各マシンの全データが収められています。ゾーンが複数のドメインにまたがっている場合は、そのゾーンを構成する全ドメインの全マシンがそのゾーンのホストファイルに列挙されます。「hosts ファイルの設定 」を参照してください。
hosts という名前はファイルの役割や内容を表す総称名です。この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にすることをお勧めします。 ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つを db.doc、もう 1 つを sales.db.doc という名前にするとよいでしょう。
各ゾーンには個別の、一意の名前を持つ hosts ファイルが必要です。複数のゾーンが存在する場合は、各ゾーンの hosts ファイルには他のゾーンのマスター (マスター、スレーブ) サーバーに関する情報も含める必要があります。詳細については、例 5-16 を参照してください。
; ; 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 192.168.6.1 rigel IN A 192.168.6.112 antares IN A 192.168.6.90 polaris IN A 192.168.6.101 procyon IN A 192.168.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 つの要素で構成されています。
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する
A (アドレス) レコード。ゾーン内の各ホストに必要
CNAME (正規名) レコード。ゾーン内の各ホストのエイリアスに必要
1 つまたは複数の MX (メール交換) レコード
hosts.rev ファイルで、逆 (アドレスから名前) マッピングを行うための特別な in-addr.arpa. ドメインのゾーンを指定します。このファイル名は、起動ファイル内で指定します。
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 ファイルは、次の要素で構成されています。
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する。サーバー名は完全指定する必要がある
PTR レコード。ゾーン内の各ホストに 1 つ必要。マシン名は完全指定する必要がある
(これらのリソースレコードの詳細については、「リソースレコードのタイプ」を参照してください。)
named.local では、ローカルループバックインタフェースのアドレスまたはローカルホストをネットワークアドレス 127.0.0.1 で指定します。このファイル名は、起動ファイル内で指定します。他のファイルと同様、このマニュアルで使われていない名前を付けることもできます。
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 ネームサーバーを識別する。サーバー名およびドメイン名は完全指定する必要がある
1 つの PTR レコード。localhost に必要
インクルードファイルは、DNS データファイル内の $INCLUDE() 文で指定されているファイルのことです。$INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。
たとえば、データファイルに次のような行が含まれているとします。
$INCLUDE /etc/named/data/mailboxes |
この行によって、/etc/named/data/mailboxes ファイルがその時点で読み込まれます。この例では、/etc/named/data/mailboxes が、$INCLUDE ファイルです。$INCLUDE ファイルは必要に応じて、必要な数だけ使用します。必要がなければ使う必要はありません。
DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。各 DNS データファイルは、必ずリソースレコードを含む必要があります。ここでは、DNS データファイルと各ファイルに含む必要があるリソースレコードについて説明します。
標準リソースレコード書式では、データファイルの各行は、「リソースレコード」(RR) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。
namettlclassrecord-typerecord-specific-data |
フィールドの順は常に同じですが、最初の 2 行はオプション (カッコ付きで示す) です。また、最後は record-type フィールドによって変化します。
最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。
ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが付加されます。
2 番目のフィールドは、任意指定の有効期限フィールドです。このフィールドでは、データを破棄する前にデータベース内にデータをキャッシュしておく時間 (秒)、すなわちサーバーに新しい情報を次回要求するまでの時間を指定します。このフィールドを空白のままにすると、ttl には、権限の開始 (SOA) リソースレコードで指定された最小時間がデフォルトとして用いられます。
ttl の設定値があまりにも小さいと、サーバーはデータ更新のための要求を頻繁に繰り返します。逆に、ttl の設定値があまりにも大きいと、情報の変更がタイムリーに反映されなくなります。
ほとんどの場合、ttl の値は、初期値として 1 日 (86400) から 1 週間 (604800) の間に設定するとよいでしょう。そのあとで、実際の情報の変更の頻度にあわせて ttl の値を適切な値に変更してください。また、ほとんど変化することがないデータと関連してい るということで ttl の値を大きく設定していた場合、そのデータが変更されるとわかった時点で、ttl の値を、データの変更が行われるまで小さな値 (3600 - 86400) にし、その後またもとの大きな値に戻すこともできます。
同じ名前、クラス、タイプを持つすべての RR では、ttl は同じ値に設定してください。
3 番目のフィールドは、レコードのクラスです。現在のところ、1 つのクラスだけがあります。それは、TCP/IP プロトコルのファミリーであることを示す IN です。
4 番目のフィールドでは、リソースレコードのタイプを記述します。RR にはたくさんのタイプがあります。最も一般的に使用されるタイプは、「リソースレコードのタイプ」に説明されています。
record-specific-data フィールドの内容は、そのリソースレコードのタイプによって異なります。
ネームフィールドとデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。ただし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。
次に挙げる文字には特別な意味があります。
表 5-6 特殊なリソースレコード文字
文字 |
定義 |
---|---|
. |
ネームフィールドで、1 つのドットだけが指定された場合は現在のドメインを指す |
@ |
ネームフィールドで、1 つの @だけが指定された場合は現在の起点を示す |
.. |
2 つのドットがネームフィールドに指定された場合は NULL ドメイン名を表す |
\ X |
X は数字 (0 - 9) 以外の任意の文字で、\ を付けることによって文字に特別な意味を持たせないようにする。たとえば、\. を指定して、ラベルにドット文字を入れることができる。 |
\ DDD |
各 D は一桁の数字で、\ を付けることによって DDD で表される 10 進数に対応する 8 進数を表現する。結果的に得られる 8 進数は、テキストとみなされ、そのテキストに特別な意味があるかどうかはチェックされない |
() |
データが 1 行に収まらないとき、データをグループ化するのにカッコを使用する。結果的に、カッコの間では行の終わりが認識されない |
; |
セミコロンでコメントが開始する。その行でセミコロン以降は無視される |
* |
アスタリスクはワイルドカードを表す |
ほとんどのリソースレコードには、現在の起点があり、名前の最後にドット (.) が付いていなければ、現在の起点が名前に追加されます。この機能は、マシン名などのデータに現在のドメイン名を追加する際には便利ですが、追加したくない場合には、問題を引き起こすかもしれません。データファイルを作成しているドメイン内に名前がない場合は、ピリオドで終わる完全指定名を使用してください。
データファイルで制御エントリの行だけは標準 RR 書式に従わない行です。制御エントリには、$INCLUDE() と $ORIGIN() の 2 つのタイプがあります。
インクルード行は 1 列目の $INCLUDE で始まり、その後にファイル名 ($INCLUDE ファイル) が続きます。次の例に示すように、この機能は異なるタイプのデータを複数のファイルに分けるのに特に便利です。
$INCLUDE /etc/named/data/mailboxes |
この行は、/etc/named/data/mailboxes ファイルを読み込む要求として解釈されます。$INCLUDE コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。このコマンドを使用しても、あるゾーンのデータが別々のファイルに格納されるだけです。たとえば、メールボックスのデータはこの機能を使ってホストデータとは別に保存できます。
$INCLUDE の文とファイルは必要に応じて必要な数だけ使用できます。
$ORIGIN コマンドによって、データファイル内の起点を変更できます。この行は 1 列目から始まり、ドメイン名が続きます。これによって、相対ドメイン名 (たとえば、完全指定されていないドメイン名) の現在の起点を指定の名前に変更します。これは、1 つのデータファイルに複数のドメインを入れるのに便利です。
1 つのデータファイルに複数のゾーンを入れるために $ORIGIN() を使うことはできません。
$ORIGIN コマンドは、必要に応じて必要な数だけデータファイルで使用できます。$ORIGIN() 文がない場合、DNS データファイルのデフォルトの起点は、named.conf ファイルの master または slave の各行の 2 番目のフィールドに指定されているドメイン名となります。
最も一般的に使用されるリソースレコードのタイプを 表 5-7 に列挙します。 通常、表 5-7 に並んだ順で入力しますが、この順序は必須ではありません。
表 5-7 一般的に使用されるリソースレコードのタイプ
形式 |
説明 |
---|---|
SOA |
権限の開始 |
NS |
ネームサーバー |
A |
インターネットアドレス (名前からアドレス) |
PTR |
ポインタ (アドレスから名前) |
CNAME |
正規名 (ニックネーム) |
TXT |
テキスト情報 |
WKS |
既知サービス |
HINFO |
ホスト情報 |
MX |
メール交換 |
例 5-19 に権限の開始 (SOA) リソースレコードの構文を示します。
name class SOA origin person-in-charge ( serial number refresh retry expire ttl) |
SOA レコードは、ゾーンの開始を示します。次の SOA レコードでそのゾーンは終了します。以下に、SOA レコードの各フィールドについて説明します。
ゾーン名を指定するフィールドです。ゾーン名の後にはドットを付ける必要があります。たとえば : doc.com. は正しいですが、doc.com は誤りです。
アドレスクラスのフィールドです。たとえば IN はインターネットを示し、最も一般的に用いられるクラスです。
このリソースレコードのタイプを示します。
このデータファイルが存在するホスト名のフィールドです。ホスト名の後にはドットを付ける必要があります。たとえば、dnsmaster.doc.com. は正しいですが、dnsmaster.doc.com は誤りです。
ネームサーバーの責任者のメールアドレスのフィールドです。たとえば、kjd.nismaster.doc.com. です。この名前も終わりにドットを付ける必要があります。
データファイルのバージョン番号のフィールドです。データを変更するたびにこの番号を増やしてください。スレーブサーバーは serial フィールドを使って、最後にマスターサーバーからデータファイルをコピーしてから変更があったかどうかを検出します。
更新が必要かどうかを調べるためにスレーブネームサーバーがマスターネームサーバーをチェックする頻度を秒単位で指定します。たとえば、7200 は 2 時間を意味します。
リフレッシュのためのチェックに失敗した後、スレーブサーバーが再試行する時間を秒単位で指定します。
リフレッシュが頻繁に行われない場合に、データの期限が切れる前に、スレーブネームサーバーがそのデータを使用する上限の時間を秒単位で指定します。
リソースレコードの time-to-live フィールドで使用されるデフォルトの秒数を指定します。このデフォルト値はリソースレコードで他に ttl が指定されていないときに適用されます。
SOA レコードは、各ゾーンに 1 つだけ指定してください。例 5-20に、SOA リソースレコードの例を示します。
;name class SOA origin person-in-charge doc.com. IN SOA dnsmaster.doc.com. root.nismaster.doc.com. ( 101 ;Serial 7200 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum ) |
例 5-21 に、ネームサーバー (NS) リソースレコードの構文を示します。
domainname [optional TTL] class NS name-server-name |
ネームサーバーレコードは、対象としているドメインを受け持つサーバーの名前を示します。name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。name フィールドを指定しない場合は、デフォルトで、最後に指定された名前になります。NS レコードは、そのドメインのマスターサーバーとスレーブサーバーにそれぞれ 1 つずつ必要です。例 5-22 に、NS リソースレコードの例を示します。
;domainname [TTL] class NS nameserver doc.com 90000 IN NS sirius.doc.com. |
例 5-23 に、アドレス (A) リソースレコードの構文を示します。
machinename [optional TTL] class A address |
A レコードは、対象としているマシンのアドレスを示します。name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。A レコードは、マシンの各アドレスに 1 つ必要です。つまり、ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む個々のエントリが各ネットワークインタフェースに割り当てられます。
;machinename [TTL] class A address sirius IN A 123.45.6.1 |
例 5-25 に、ホスト情報 (HINFO) リソースレコードの構文を示します。
[optional name] [optional TTL] class HINFO hardware OS |
HINFO には、ホスト固有のデータが含まれ、ハードウェアとこのホストで動作しているオペレーティング環境を指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。HINFO レコードは、各ホストに 1 つ必要です。例 5-26に、HINFO リソースレコードの例を示します。
;[name] [TTL] class HINFO hardware OS IN HINFO Sparc-10 UNIX |
HINFO フィールドにはネットワーク上のマシンについての情報が含まれているので、多くのサイトでは、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。
例 5-27 に、既知サービス (WKS) リソースレコードの構文を示します。
[Optional name] [TTL] class WKS address protocol-list-of-services |
WKS レコードは、指定されたアドレスの特定のプロトコルでサポートされているよく知られたサービスを示します。サービスのリストとポート番号は、services データベースで指定されたサービスのリストから得られます。WKS レコードは、各アドレスの各プロトコルに 1 つだけ存在している必要があります。例 5-28 に、WKS リソースレコードの例を示します。
;[name] [TTL] class WKS address protocol-list-of-services altair IN WKS 123.45.6.1 TCP ( smtp discard rpc sftp uucp-path systat daytime netstat qotd nntp doc.com ) |
WKS レコードは任意指定です。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。
例 5-29 に、正規名 (CNAME) リソースレコードの構文を示します。
nickname [optional TTL] class CNAME canonical-name |
CNAME は、正規名のニックネームまたはエイリアスを示します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームを作成して他のリソースレコードで使用することはしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 5-30に、CNAME リソースレコードの例を示します。
;nickname [TTL] class CNAME canonical-name mailhost IN CNAME antares.doc.com |
例 5-31に、PTR リソースレコードの構文を示します。
special-name [optional TTL] class PTR-real-name |
ポインタレコードを使用すると、特殊な名前でドメイン内の他の場所を指すことができます。次の例では、アドレス (特殊な名前) を実名に変換するために、PTR は主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときはドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。PTR の名前は、ゾーンに対して一意である必要があります。例 5-32の PTR レコードでは、特殊なドメイン in-addr.arpa. に対して逆ポインタを設定します。
;special name [TTL] class PTR-real-name 1 IN PTR sirius.doc.com. |
例 5-33 に、メール交換 MX リソースレコードの構文を示します。
name [optional TTL] class MX preference-value mailer-exchanger |
MX リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。対象としている名前に対して複数の MX リソースレコードが作成される場合もあります。例 5-34では、Seismo.CSS.GOV (完全指定のドメイン名) は、Munnari.OZ.AU にメールを配信するメールゲートウェイです。ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポート媒体を使用している場合もあります。preference-value フィールドでは、メールプログラムが従う順序を指定します。このフィールドは、単一のマシンにメールを配信する方法が複数ある場合に指定します。値が 0 (ゼロ) は最優先であることを意味します。同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値 (preference-value) は同じであることも、同じでないこともあります。
メールを配信するために、MX レコードでワイルドカードであるアスタリスク ( *) を名前に使うこともできます。あるドメイン宛のメールがすべてリレー経由で配信されるサーバーがネットワーク上にはよくあります。例 5-34では、foo.com ドメイン内のホスト宛のメールはすべて RELAY.CS.NET を経由して送られます。これを指定するには、ワイルドカードを用いて MX リソースレコードを作成し、*.foo.com のメール交換が RELAY.CS.NET. により行われることを指定します。アスタリスクは foo.com のどのホストまたはサブドメインにも一致します。ただし、foo.com 自体には一致しません。
;name [TTL] class MX preference mailer-exchanger Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV. foo.com. IN MX 10 RELAY.CS.NET. *.foo.com. IN MX 20 RELAY.CS.NET. |
この章では、DNS に関する一般的な問題とその解決方法について説明します。
「症状」
DNS クライアントは、IP アドレスかホスト名でマシンを見つけられますが、サーバーは IP アドレスでしか見つけることができません。
「考えられる原因と対策」
サーバーの nsswitch.conf ファイルの hosts 行から DNS を省略したために発生する可能性があります。たとえば、不完全な hosts 行は、hosts: files のようになります。
DNS の使用時は、各マシンの nsswitch.conf ファイルの hosts レコード内に dns を入れる必要があります。たとえば、次のようにします。
hosts: dns nisplus files |
または
hosts: nisplus dns files |
「症状」
マシンやサーバーを追加または削除しても、変更が認識されないか反映されません。あるいは、変更が認識されたり認識されなかったりします。
「考えられる原因」
考えられる最初の原因は、変更を加えた後にマスターサーバー上の SOA のシリアル番号を増やし忘れたことです。新しいSOA 番号がないので、スレーブサーバーはそのデータをマスターサーバーのデータと一致させるためのデータ更新を行いません。このため、古い未変更のデータファイルを使用しています。
この他に考えられる原因は、マスターサーバー上の 1 つ以上のデータファイルの SOA のシリアル番号が、スレーブサーバー上の対応するシリアル番号よりも小さい値に設定されたことです。この状態はたとえば、マスターサーバー上のファイルを削除してから、ある種の入力ファイルを使って最初から作成し直した場合に発生します。
考えられる 3 番目の原因は、マスターサーバーのデータファイルに変更を加えた後で、HUP 信号をマスターサーバーに送信し忘れたことです。
「診断と対策」
まず、変更したデータファイルの SOA のシリアル番号とスレーブサーバー上の対応するファイルをチェックします。
マスターサーバーのファイルの SOA シリアル番号がスレーブサーバーのファイルのシリアル番号と同じかそれ以下の場合は、マスターサーバーのファイルのシリアル番号を増やしてスレーブサーバーのファイルの番号よりも大きくなるようにします。たとえば、両方のファイルの SOA のシリアル番号が 37 の場合は、マスターサーバーのファイルの番号を 38 に変更します。次回、スレーブサーバーがマスターサーバーをチェックすると、新しいデータがロードされます。マスターサーバーに、スレーブサーバーへのデータ転送を即座に強制するユーティリティがあります。このユーティリティがある場合には、マスターサーバーのチェックを待たずにスレーブサーバーを更新できます。
最新の named nnnn restarted または、named nnn reloading nameserver エントリに対する syslog 出力を確認します。そのエントリのタイムスタンプが、ファイルへの変更を終了した時間よりも前の場合には、サーバーをリブートするか、「in.named に DNS データを強制的に再度読み込ませる」で説明しているように、新しいデータの読み取りを強制します。
「症状」
クライアントは完全指定名は検索できますが、短縮名は検索できません。
「考えられる原因と対策」
クライアントの /etc/resolv.conf ファイルで、ドメイン名の最後にスペースがないかをチェックします。スペースやタブはドメイン名の最後では使用できません。
ゾーンのドメイン名の付いたデータは、ゾーンのマスターサーバーからゾーンのスレーブサーバーに正しく転送されますが、逆ドメインデータは転送されません。つまり、スレーブサーバーの host.rev ファイルがマスターサーバーから正しく更新されていません。
「考えられる原因」
スレーブサーバーの起動ファイルの構文エラー
「診断と対策」
スレーブサーバーの起動ファイルをチェックします。マスターサーバーの IP アドレスが、ホストデータの場合と同じように、逆ゾーンエントリに対してリストされていることを確認してください。
スレーブサーバーがそのマスターサーバーから更新を得られないときは、「master unreachable」というメッセージがログに記録されます。問題が修正されない場合、スレーブサーバーはゾーンを期限切れにして、クライアントからの要求への応答を停止します。この状況が発生すると、「server failed」というメッセージが表示されます。
「症状」
syslog に「Masters for slave zone domain unreachable」というメッセージが表示される
ユーザーに「*** domain Can't find name:server failed」というメッセージが表示される
問題がスレーブサーバーにある場合、一部のユーザーはマスターサーバーから DNS 情報を獲得できるため問題なく操作できます。
「考えられる原因」
これらの問題に対して考えられる主な原因は 2 つあります。1 つはネットワーク障害であり、もう 1 つはスレーブサーバーの起動ファイル内に指定したマスターサーバーの IP アドレスが間違っていることです。
「診断と対策」
スレーブサーバーの構成ファイルに、マスターサーバーの IP アドレスが正しく設定されているかどうか確認します。次の行をチェックしてください。
zone "someone" { type slave; file "somefile": master [IPaddress; }; }; |
hosts ファイルで指定したマスターサーバーの IP アドレスが実際の IP アドレスと一致することを確認してください。IP アドレスが間違っている場合は、それを修正してからスレーブサーバーをリブートします。
マスターサーバーの IP アドレスが正しい場合は、そのアドレスを ping して、マスターサーバーが正しく起動しているかどうかを確認します。たとえば、マスターサーバーを IP アドレス 192.168.0.1 で ping する場合は、次のように入力します。
% ping 192.168.0.1 -n 10
マスターサーバーが ping に応答しない場合は、マスターサーバーが正しく起動しているかどうかを確認します。
マスターサーバーが正しく起動している場合は、ps を使用して、マスターサーバーが named を実行しているかどうかを確認します。named を実行していない場合は、リブートします。
マスターサーバーが named を正しく実行している場合は、ネットワークに障害が発生している可能性があります。
「症状」
「考えられる原因」
ユーザーが作業しているマシンの PTR レコードがマスターサーバーの hosts.rev ファイルにありません。
hosts.rev ファイル内のサブドメインがないか、不正な委任が行われています。
「診断と対策」
該当するhosts.rev ファイルをチェックして、ユーザーのマシン用の PTR レコードが存在することを確認します。たとえば、192.168.0.1 の IP アドレスを持つマシン altair.doc.com で作業をしている場合は、doc.com マスターサーバーの doc.rev ファイルに次のようなエントリを追加する必要があります。
46 IN PTR altair.doc.com. |
レコードがない場合は、hosts.rev ファイルに追加してからサーバーをリブートするか、「in.named に DNS データを強制的に再度読み込ませる」の指示に従ってデータをロードし直します。
hosts.rev ファイルの NS エントリをチェックおよび修正してから、サーバーをリブートするか、「in.named に DNS データを強制的に再度読み込ませる」の指示に従ってデータをロードし直します。
「症状」
次のような表現が含まれるコンソールまたは syslog のエラーメッセージは、たいてい DNS データや起動ファイルの構文エラーによるものです。
関連ファイルにスペルや構文のエラーがないかどうか チェックしてください。
一般的な構文エラーは、ドメイン名で後ろに付けるドットの誤用 (禁じられている場合に使い、必要な場合に使わないなど) が原因で発生します。「DNS サーバーの設定」を参照してください。