Part VI では DNS とその管理の方法について説明します。
この章ではドメイン名システム (DNS) の構造と概要を説明します。
DNS サービスの初期設定と構成に関する情報は、『Solaris ネーミングの設定と構成』を参照してください。
DNS の利用で最も一般的で重要なことは、ネットワークをグローバルなインターネットに接続することです。インターネットに接続するには、ローカルなネットワークの IP アドレスが親ドメインの管理者のところに登録されている必要があります。管理者はそれぞれの地理的条件や親ドメインのタイプによって異なります。
ドメイン名システム (DNS) は、標準 TCP/IP プロトコル群のひとつのアプリケーション層プロトコルです。これによって DNS ネームサービスを実現します。DNS ネームサービスはインターネットで使用されるネームサービスです。
ここでは基本的な DNS のコンセプトを紹介します。説明に際しては、ネットワークの管理 (特に TCP/IP) に精通していて、NIS+ や NIS といった他のネームサービスについての知識があることを前提とします。
DNS の初期設定と構成に関しては、『Solaris ネーミングの設定と構成』を参照してください。
DNS、NIS+、NIS、FNS には同じような機能があり、時として異なる構成要素を定義するのに同じ用語を使用している場合がありますが、この章では、ドメインやネームサーバーといった用語は DNS の機能に合わせて定義しています。なぜなら、DNS の機能は NIS+ や NIS のドメインやサーバーとは大きく異なるからです。
DNS はインターネット上の複雑で全世界的なコンピュータの階層をサポートしますが、それ自身の基本機能は非常に簡単なものです。すなわち、TCP/IP に準拠したネットワーク用に「名前のアドレス解決」を提供するということです。名前のアドレス解決は「マッピング」ともいい、あるコンピュータのホスト名をインデックスとして用い、その IP アドレスをデータベースから見つけだすプロセスのことです。
名前のアドレスマッピングは、ローカルなコンピュータ上で実行されているプログラムが遠隔コンピュータに接続する必要がある時に行われます。ほとんどの場合、このプログラムでは遠隔コンピュータのホスト名はわかっても、その場所を特定できないことがあります。特に遠隔マシンが自分のサイトから何マイルも離れた他の会社にある場合には場所を特定できません。プログラムは遠隔マシンのアドレスを得るために、ローカルマシン上で動作している DNS ソフトウェアに要求をに送ります。この時のローカルマシンを「DNS クライアント」と呼びます。
ローカルマシンは、「DNS ネームサーバー」にリクエストを送ります。DNS ネームサーバーは 分散 DNS データベースを保持しています。 NIS+ のホストテーブルやローカルの /etc/hosts ファイルも同様の情報、すなわち、ホスト名、IP アドレス、その他コンピュータの特定のグループに関する情報を保持していますが、DNS データベースはそれらとはあまり似ていません。 ローカルマシンは、遠隔マシンの IP アドレスを見つけたり、「解決」したりするためのリクエストの一部として自分自身のホスト名を送信しますが、ネームサーバーは、それも利用します。そして、もしリクエストしたホスト名が DNS データベースにあれば、その IP アドレスがネームサーバーによってローカルマシンに返されます。
図 27-1 に、DNS クライアントのローカルネットワーク上でクライアントとネームサーバーの間での名前のアドレスマッピングを示します。
もし、ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。このために、各ネームサーバーは、ローカル管理ドメインに対して「権限がある」とされています。
幸い、ローカルネームサーバーには、ルートドメインネームサーバーのホスト名と IP アドレスのリストがあります。そしてローカルネームサーバーは、ローカルマシンからのリクエストを「ルートドメインネームサーバー」に転送します。ルートネームサーバーは、 「DNS 階層とインターネット」で説明したように、大きな組織のドメインに対して権限があります。その階層は、上下のツリー構造で編成された UNIX のファイルシステムに似ています。
各ルートネームサーバーには、会社、大学、その他大規模な組織における最上位のドメインネームサーバーのホスト名と IP アドレスがあります。ルートネームサーバーは、ホスト名と IP アドレスがわかっているすべての最上位のネームサーバーにローカルマシンからのリクエストを送信します。リクエストされたホストの IP アドレスを最上位のネームサーバーのどれかが持っている場合、その情報がローカルマシンに返されます。最上位のサーバーがリクエストされたホストに関する情報を持っていない場合、第 2 レベルのネームサーバーにリクエストが渡されます。このようにローカルマシンからのリクエストは組織の巨大なツリー構造の下へ向かって順に渡されます。最終的にローカルマシンからのリクエストに対する情報をデータベースに持っているネームサーバーが IP アドレスを返します。
図 27-2 はローカルドメインの外側での名前のアドレス解決を示します。
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 2.6 リリース環境に含まれています。
in.named デーモンは、カリフォルニア大学バークレー校で開発されたので、Berkeley Internet Name Domain service (BIND) と呼ばれることもあります。
以下のような、3 つのタイプの DNS ネームサーバーがあります。
各ドメインには、主サーバーが 1 つとバックアップのための副サーバーが少なくとも 1 つ必要です。主サーバーと副サーバーの詳細は、「ゾーン」を参照してください。
あるマシンを DNS クライアントにするには、「リゾルバ」を実行する必要があります。 リゾルバはデーモンでもなければ単一のプログラムでもなく、アプリケーションによって使用される動的ライブラリルーチンの集合です。マシン名を知る必要があるときに、このライブラリが使用されます。リゾルバの機能はユーザーの照会を解決することです。それを行うために、リゾルバはネームサーバーに照会します。するとネームサーバーは要求された情報か、または他のサーバーに照会する旨を返します。一度リゾルバを設定すれば、そのマシンはネームサーバーに DNS サービスを要求できるようになります。
あるマシンの /etc/nsswitch.conf ファイルで hosts:dns (または hosts 行に dns を含む別のパターン) が指定されていると、リゾルバのライブラリが自動的に使用されます。もし、nsswitch.conf ファイルが dns より前に、他のネームサービスを指定した場合、最初にそのネームサービスに対してホスト情報を問い合わせ、要求されたホストの情報が見つからなかった場合にだけリゾルバのライブラリが使用されます。
たとえば、nsswitch.conf ファイル内の hosts の行で hosts:nisplus dns と指定されている場合、ホストの情報を得るために NIS+ ネームサービスが最初に検索されます。もし、NIS+ で情報が見つからなかったとき、DNS リゾルバが使用されます。NIS+ や NIS といったネームサービスではそれ自身のネットワーク内にあるホストに関する情報だけを保持しているため、結果的に hosts:nisplus dns と switch ファイルで指定することは、ローカルホストに関する情報に対しては NIS+ を使用し、インターネット上の遠隔システムに関する情報に対しては DNS を使用するように指定することになります。
DNS クライアントには以下のような 2 つの種類があります。
クライアント専用
クライアント専用 DNS は in.named を実行せず、代わりにリゾルバを実行します。リゾルバはドメインに対するネームサーバーのリストを保持しているため、そこに問い合わせが転送されます。
クライアント兼サーバー
クライアントマシンのリゾルバによって転送されてきた問い合わせを解決するために in.named で提供されるサービスを使用します。
Solaris 2.6 リリース環境には、リゾルバを構成している動的ライブラリルーチンが含まれています。『Solaris ネーミングの設定と構成』で、ホストを DNS クライアントとして設定する方法が説明されています。
全世界の DNS 管理ドメインの集合全体は「 DNS 名前空間」と呼ばれる階層構造を形成しています。ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。
DNS ドメインは、UNIX のファイルシステムと同様、木の根に似た下に向きの枝分かれで構成されています。各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。「ドメイン」と「サブドメイン」は相対的な関係を示します。階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。
たとえば、 図 27-3 において com は Acme、 Ajax、AAA の各ドメインの親ドメインです。あるいは、これらのドメインは com ドメインのサブドメインということもできます。このように考えると、Ajax ドメインは4つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。
あるドメインには、1 つの親 (あるいは最上位) ドメインと、(もしあれば) その下のサブドメインが含まれます。ドメインの名前付けは最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。 図 27-3 の Mktg.Corp.Ajax.Com. がその例です。
大規模な会社であれば、多くのドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。 図 27-4 に、ある会社に存在するドメインの階層構造の例を示します。この会社の最上位のドメイン、すなわちルートドメインは ajax.com で、sales.ajax.com、 test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。
DNS クライアントは、そのドメインをサポートするサーバーだけにサービスをリクエストします。もし、クライアントの必要としている情報がそのドメインサーバーにない場合、リクエストは親サーバーに転送されます。親サーバーは、1 つ上の階層のドメインサーバーです。リクエストが最上位のサーバーに達した場合、最上位のサーバーはリクエストされたドメインが有効かどうか調べます。それが有効でない場合、サーバーは 「not found」というメッセージをクライアントに返します。リクエストされたドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。
図 27-4 に示したドメインの階層は、概念的には世界規模のインターネット上でサポートされる巨大な DNS 名前空間の枝葉のようなものです。
インターネットの DNS 名前空間は 図 27-5 で示すように階層状に組織されます。それは、ピリオド (.) で表されるルートディレクトリと最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。 com ドメイン ( 図 27-3) はインターネットに存在する最上位の組織ドメインの 1 つです。
現在、組織的な階層の名前空間は、 表 27-1 に示した最上位のドメインに分けられます。将来、これ以外にも最上位の組織ドメインが追加される可能性があります。
表 27-1 インターネットの組織ドメイン
ドメイン |
目的 |
---|---|
com |
営利団体 |
edu |
教育機関 |
gov |
行政機関 |
mil |
軍事組織 |
net |
大手のネットワークサポートセンター |
org |
非営利団体、その他 |
int |
国際組織 |
地理的な階層においては、各国に対して 2、3 文字の識別子が割り当てられ、それが、各国に対する公式名として用いられます。 たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。
インターネットのルートドメイン、すなわち最上位のドメイン (組織的および地理的) は、様々なインターネット運営体によって管理されています。規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。
DNS ドメインはドメイン名を持つ必要があります。インターネットに接続しないで、ネームサービスとして DNS を使用したいのであれば、ドメインやサブドメインに任意の名前を付けることができます。しかし、インターネットに参加するのであれば、そのドメイン名はインターネット運営体に登録する必要があります。
インターネットに接続するために必要な条件は以下のとおりです。
上記のことを行うには、以下のような 2 つの方法があります。
適当なインターネット運営体またはその代理団体と直接連絡をとる方法。アメリカ合衆国では、現在 InterNIC 社がネットワークアドレスとドメインの登録を取り扱っています。
インターネットサービスプロバイダ (ISP) と契約する方法。ISP は、コンサルティングから実際の接続まで広範なサービスを提供しています。
ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。たとえば、 図 27-4 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。したがって、そのインターネットドメイン名は ajax.com となります。
図 27-6 は、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 サービスは、「in.named と DNS ネームサーバー」で最初に説明したネームサーバーの集合で管理されます。ネームサーバーは、単一のドメイン、複数のドメイン、複数のドメインとその下のサブドメインの一部または全部を管理できます。あるネームサーバーによって制御される名前空間の一部は、「ゾーン」と呼ばれます。したがって、ネームサーバーはゾーンに対して権限があるといわれます。ネームサーバーの責任者は、ゾーン管理者とも呼ばれます。
ネームサーバーのデータベース内のデータは、「ゾーンファイル」と呼ばれます。ゾーンファイルの 1 つには IP アドレスとホスト名が格納されています。 ftp または telnet のようなユーティリティでホスト名を用いて遠隔ホストに接続しようとすると、DNS は名前のアドレスマッピングを実行し、ゾーンファイルの中でホスト名を探して、IP アドレスに変換します。
たとえば、 図 27-7 で示した 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.200.21.165 であるとします。in-addr.arpa ゾーンファイルでは、そのアドレスは 165.21.200.192.in-addr.arpa. と書かれます。ここで最後のドットは in-addr.arpa ドメインのルートを示しています。
DNS サーバーには複数の機能があります。
「ゾーンマスターサーバー」
マスターネームサーバーは、ゾーンに対応するすべてのデータを保持しています。マスターサーバーは一般に、権限があるネームサーバー (「マスターサーバー」を参照) と呼ばれます。
マスターサーバーには 2 つのタイプがあります。
「ゾーン主マスターサーバー」
各ゾーンには、そのゾーンの主マスターサーバ (「主マスターサーバー」を参照) と呼ばれるサーバーが 1 つあります。
「ゾーン副マスターサーバー」
ゾーンには、1 つ以上の副マスターサーバーがあります。副マスターサーバーは、DNS データをゾーンの主マスターサーバー (「主マスターサーバー」を参照) から入手します。
「キャッシュオンリーサーバー」
サーバーは、DNS データのキャッシュを保持するという意味で、すべてキャッシュサーバーです。キャッシュオンリーサーバーは in-addr.arpa. ドメイン (「キャッシュサーバーとキャッシュオンリーサーバー」を参照) だけに対してのマスターサーバーです。
「ルートドメインサーバー」
ルートドメインサーバーは、ユーザーの DNS ドメインの階層の最上位に対して権限があるサーバーです。もしユーザーのネットワークがインターネットに接続されているなら、ルートドメインサーバーはインターネット上にあります。もしネットワークがインターネットに接続されていないなら、ルートドメインサーバーを設定する必要があります (「ルートドメインネームサーバー」を参照)。
個々の異なるサーバーの機能は、同一のマシン上でも実行可能です。たとえば、あるマシンを、あるゾーンの主マスターサーバーにし、同時に別のゾーンの副マスターサーバーにできます。 このマニュアルでは、主サーバー、副サーバー、キャッシュオンリーサーバーというのは特定のマシンの呼び名ではなく、マシンがあるゾーンに対して果たしている役割のことを指しています。
マスターネームサーバーは、ゾーンに対応するすべてのデータを保持しています。マスターサーバーは一般に、権限があるネームサーバーと呼ばれます。任意のゾーンに対応するデータは 2 つ以上の権威があるサーバーで使用可能になっている必要があります。 ここで、1 つのネームサーバーは主マスターサーバーとし、少なくとも 1 つ以上は副マスターサーバーとする必要があります。副マスターサーバーは、主マスターサーバーが使用できないときや負荷過剰のときのバックアップとして機能します。
サーバーは複数のゾーンに対するサーバーとして機能できます。すなわち、あるゾーンに対しては主マスターで、別のゾーンに対しては副マスターとなります。
主マスターサーバーは、自分用のデータのマスターコピーを in.named の起動時にディスクから読み込む DNS ネームサーバーです。ゾーンの主マスターサーバーは、そのゾーンに対する変更を行なった場所にあります。主マスターサーバーは、そのゾーンに関する DNS 情報の情報源です。また、主マスターサーバーはそのゾーン内の副サーバーやゾーン外のサーバーに権限を任せることもあります。
副マスターサーバーにはそのゾーン用のデータのコピーがあります。主サーバーはそのデータを副サーバーに送り、権限を任せます。クライアントは、DNS 情報を副サーバーに照会できます。副サーバーを使用することによって、負荷が複数のマシンに分散され、応答時間を短縮してネットワークのオーバーヘッドを減らすことができます。また、副サーバーは、主サーバーが使用できないときに代わりの機能を果たします。
副サーバーは in.named を起動するとき、ゾーンに関するすべての情報を主サーバーにリクエストします。副サーバーはデータベースを更新する必要があるかどうかを調べるために主サーバーを定期的にチェックします。最新のゾーンデータベースを主サーバーから副サーバーに送信するプロセスを「ゾーン転送」と呼びます。したがって、副サーバー上のデータファイルは変更しません。ゾーンの主サーバーのデータサーバーを変更します。そして、副サーバーのファイルは主サーバーから変更されます。
すべてのネームサーバーは「キャッシュサーバー」です。ネームサーバーは受け取ったデータをそれが期限切れになるまでキャッシュします。 期限切れのプロセスは、データに結びついている生存期間 (time-to-live = TTL) フィールドで制御されます。
さらに、どんなゾーンに対しても権限がない「キャッシュオンリーサーバー」を設定することもできます。キャッシュオンリーサーバーは、 in-addr.arpa. ドメイン以外のゾーンだけに対してのマスターサーバーです。 キャッシュオンリーサーバーは、権限があるネームサーバーが処理するのと同様の照会を扱いますが、権威データ自体は保持しません。
キャッシュオンリーサーバーは、権限があるサーバーより少ないメモリーで動作しますが、もし主サーバーまたは副サーバーが使用できない場合、キャッシュオンリーサーバーだけでは機能しません。
DNS 名前空間には、ルートドメインに対して権限がある「ルートドメインネームサーバー」が 1 つ以上必要です。
ネットワークがインターネットに接続されている場合、ルートドメインサーバーはルートドメインであるインターネットのサイトにあります。この場合、「インターネットルートドメインサーバー」で説明しているように、ルートドメインサーバーがあるサイトのインターネット IP アドレスをキャッシュファイルに入れてください。
ネットワークがインターネットに接続されていない場合、 「非インターネットルートドメインサーバー」で説明しているように、ローカルネットワーク上のルートレベルのドメイン内に主ネームサーバーと副ネームサーバーを設定する必要があります。これによってローカルネットワーク内のすべてのドメインは、参照すべき権限があるサーバーを持つことになります。この設定がされていないと、マシンは要求された照会を解決できません。
ルートドメインネームサーバーを識別する情報はキャッシュファイルに格納されています。このマニュアルでも、またほとんどの Solaris のサイトでも、このキャッシュファイルを named.ca (このファイルのどこでも共通の別名は root.cache、named.root、db.cache) と呼びます。 各サーバーのブートファイルには、ルートドメインネームサーバーの情報を保持しているファイルを識別するレコードがあります。
ネットワークがインターネットに接続されている場合、DNS ネームサーバーのブートファイルでは、共通キャッシュファイル (一般に named.ca と呼ばれる) を指定して、ルートドメインネームサーバーを識別する必要があります。このファイルのテンプレートは、以下のいずれかを通して、InterNIC から入手できます。
匿名 FTP
FTP のサイトは、ftp.rs.internic.net、ファイル名は、/domain/named.root
Gopher
Gopher のサイトは、rs.internic.net で、ファイルは、named.root。このファイルは「InterNIC Registration Services」 メニューの「InterNIC Registration Archives」 サブメニューにある
このマニュアルに記載の方法で DNS のファイルに名前を付けるのであれば、上記の方法で入手したファイルは、/var/named/named.ca とする必要があります。
ネットワークがインターネットに接続されていない場合、ルートドメインネームサーバーとして機能するように 1 つ以上のサーバーを設定する必要があります。ネットワーク上のすべての DNS ネームサーバーのブートファイルで共通のキャッシュファイル (一般的には named.ca) を指示する必要があります。 これで、ルートドメインネームサーバーが識別されます。次に、ルートドメインネームサーバーを識別するキャッシュファイルを作成します。
1 台のマシンを複数のマシンの主ドメインネームサーバーとすることができますので、ルートドメインネームサーバーを作成する最も簡単な方法は、最上位のドメインにサーバーを持ち、それを論理的な (.) ドメインのサーバーにすることです。
たとえば、ネットワークに solo というドメイン名を与えたとします。DNS マスターネームサーバーは dnsmaster.solo. (最後にドットを付ける) となります。この場合、dnsmaster を (.) ドメインのルートマスターサーバーとしたことになります。
ネットワークに最上位のドメインが複数ある場合、ルートドメインサーバー名は最上位のすべてのドメインの主ネームサーバーである必要があります。たとえば、ネットワークが、solo と private という名前の非階層の 2 つのドメインに分かれているとすると、同じサーバーが両方のルートマスターサーバーである必要があります。上の例では、dnsmaster.solo. が、solo と private の両方のドメインのルートドメインマスターとなります。
DNS には 2 つの基本的なサービスがあります。1 つは、「名前のアドレス解決」で 説明しているように 、名前からアドレス (またはその逆のアドレスから名前) のマッピングを行うサービスで、もう 1 つは、インターネット上でメールを配信する sendmail や POP といったメール配信エージェントを助けるサービスです。
インターネット上でメールを配信するのに、DNS は「メール交換レコード」(MX レコード) を用います。ほとんどの組織は、その組織内にあるホストに宛てられたインターネットから来るメールを直接配信することを許していません。そのかわりに、1台のセントラルメールホスト (またはメールホストの集合) を用いて、入ってくるメールメッセージを途中で止めて宛先に振り分けます。
メール交換レコードで、ドメイン内の各マシンにサービスを提供しているメールホストが識別されるため、メール交換レコードには遠隔組織の DNS ドメイン名と、その IP アドレスまたは対応するメールホストのホスト名のいずれかが列挙されています。
DNS のネームサーバーには、 in.named デーモンに加えて、 named.boot と呼ばれるブートファイル、 resolv.conf という名前のリゾルバファイル、4 つのタイプのゾーンデータファイルがあります。
内部的に矛盾がなければ、ゾーンデータファイルはどんな名前にもできます。このため、異なるサイトで作業をしようとする場合や DNS 関連のマニュアルや本を参照する場合に、混乱するかもしれません。 たとえば、Sun Microsystems, Inc のマニュアルやほとんどの Solaris のサイトのファイル名は、 『DNS and BIND』(Paul Albitz & Cricket Liu 著 浅羽登志也/上水流由香 監訳、アスキー出版局、1995年) で使用されている名前とは異なりますし、その両方の命名法は、『Name Server Operations Guide for BIND』(カリフォルニア州立大学刊、パブリックドメイン) での命名法とも若干異なります。
さらに、このマニュアルや他の DNS の文書では、そのファイルの主要な目的を表すために汎用的な名前が用いられ、レコードの例ではそのファイルに対して例として特定の名前が用いられています。たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能と役割を記述するために hosts が総称名として用いられ、db.doc と db.sales.doc という名前が、例として用いられています。
参考として、表 27-2 では上で述べた 3 つのマニュアルにおける BIND のファイル名を比較します。
表 27-2 BIND ファイル名 例
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() ステートメントによって識別されるファイル |
ブートファイル (/etc/named.boot) で、サーバーは主サーバー、副サーバー、キャッシュオンリーネームサーバーのいずれかに確定されます。また、サーバーが権限を持つゾーンと初期データを読み込むデータファイルが指定されます。
ブートファイルは、in.named デーモンがサーバーの起動スクリプト /etc/init.d/inetsvc によって起動されるときに、in.named デーモンによって読み込まれます。ブートファイルは、指定されたドメインに対して in.named を他のサーバーまたはローカルデータファイルのいずれかに指定します。
named.ca ファイルによって、ルートサーバー名が確立され、そのアドレスが列挙されます。ネットワークがインターネットに接続されているなら、named.ca には、インターネットのネームサーバーが表示されます。接続されていなければ、ローカルネットワークのルートドメインネームサーバーが表示されます。in.named デーモンは、サーバーの 1 つに接続できるまで、サーバーのリストを一巡します。そして、そのサーバーから現在のルートサーバーのリストを入手します。デーモンは、このリストを named.ca の更新のために用います。
hosts ファイルには、ローカルゾーン内のマシンに関するすべてのデータが含まれています。 このファイル名は、ブートファイル内で指定します。/etc/hosts との混同を避けるために、hosts 以外の名前を付けます。たとえば、これらのファイルに db.domain パターンを使用して名前を付けることができます。この命名方法により、 doc.com と sales.doc.com ドメインのホストファイルは db.doc と db.sales になります。
hosts.rev ファイルで、逆 (アドレスから名前) マッピングを行うための特別な in-addr.arpa. ドメインのゾーンを指定します。このファイル名は、ブートファイル内で指定します。
named.local で、ローカルループバックインタフェースのアドレスまたはローカルホストをネットワークアドレス 127.0.0.1 とともに指定します。このファイル名はブートファイルで指定します。他のファイルと同様、このマニュアルで使われていない名前を付けることもできます。
インクルードファイルは、DNS データファイルの中の $INCLUDE() 文で指定された任意のファイルです。$INCLUDE ファイルは、異なるタイプのデータを便宜的に複数のファイルに分けるのに使うことができます。
たとえば、データファイルに次のような行が含まれているとします。
$INCLUDE /etc/named/data/mailboxes
この行によって、/etc/named/data/mailboxes ファイルがその時点で読み込まれます。この例では、/etc/named/data/mailboxes が、$INCLUDE ファイルです。$INCLUDE ファイルは必要に応じて、必要な数だけ使用します。必要がなければ使う必要はありません。
DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。 各 DNS データファイルには、必ずリソースレコードが含まれる必要があります。ここでは、DNS データファイルと各ファイルに含まれるべきリソースレコードについて説明します。
標準リソースレコード書式では、データファイルの各行は、「リソースレコード」(RR) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。
name ttl class record-type record-specific-data
フィールドの順は常に同じですが、最初の 2 行はオプション (カッコ付きで示す) です。また、最後は record-type フィールドによって変化します。
最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。
ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが相対名に付加されます。
2 番目のフィールドは、オプションの有効期限フィールドです。このフィールドで、データを破棄する前にデータベース内にデータをキャッシュしておく時間 (秒)、すなわちサーバーに新しい情報を次回リクエストするまでの時間を指定します。 このフィールドを空白のままにすると、ttl には、Start-Of-Authority (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 フィールドの中身は、特定のリソースレコードのタイプで異なります。
ネームフィールドやデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。しかし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。
次に挙げる文字には特別な意味があります。
表 27-3 特別な意味を持つリソースレコード文字
文字 |
定義 |
---|---|
. |
ネームフィールドで、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 コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。このコマンドを使用しても、あるゾーンのデータを別々のファイルに入れるだけです。たとえば、mailbox のデータはこの機能を使ってホストデータとは別に保存されます。
$INCLUDE の文とファイルは必要に応じて必要な数だけ使用できます。
$ORIGIN コマンドによって、データファイル内の起点を変更できます。この行は 1 列目から始まり、ドメイン名が続きます。これによって、相対ドメイン名 (たとえば、完全指定されていないドメイン名) の現在の起点を指定の名前に変更します。これは、1 つのデータファイルに複数のドメインを入れるのに便利です。
1 つのデータファイルに複数のゾーンを入れるために $ORIGIN() を使うことはできません。
データファイルでの $ORIGIN コマンドは、必要に応じて使用します。 もし、$ORIGIN() 文がない場合、DNS データファイルのデフォルトの起点は named.boot ファイルの primary または secondary の行の 2 番目のフィールドにあるドメイン名です。
最も一般的に使用されるリソースレコードのタイプを 表 27-4 に列挙します。通常、表 27-4 に並んだ順で入力しますが、必須というわけではありません。
表 27-4 一般的に利用されるリソースレコードのタイプ
タイプ |
説明 |
---|---|
SOA |
権限の開始 |
NS |
ネームサーバー |
A |
インターネットアドレス (名前からアドレス) |
PTR |
ポインタ (アドレスから名前) |
CNAME |
正規名 (ニックネーム) |
TXT |
テキスト情報 |
WKS |
既知サービス |
HINFO |
ホスト情報 |
MX |
メール交換 |
例 27-1 に 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 つだけ指定してください。 例 27-2 に 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 )
例 27-3 に、ネームサーバー (NS) リソースレコードの構文を示します。
domainname [optional TTL] class NS name-server-name
ネームサーバーレコードには、対象としているドメインを受け持つサーバーの名前を指定します。name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。もし、name フィールドが指定されない場合、そのデフォルトは最後に指定された名前になります。そのドメインの主マスターサーバーと副マスターサーバーのそれぞれに 1 つの NS レコードが必要です。例 27-4 に NS リソースレコードの例を示します。
;domainname [TTL] class NS nameserver doc.com 90000 IN NS sirius.doc.com.
例 27-5 に、アドレス (A) リソースレコードの構文を示します。
machinename [optional TTL] class A address
アドレス (A) レコードでは、対象としているマシンのアドレスを指定します。name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。各マシンのアドレスに 1 つの A レコードが必要です。ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む別々のエントリがネットワークインタフェースに必要です。
;machinename [TTL] class A address sirius IN A 123.45.6.1
例 27-7 に、ホスト情報 (HINFO) リソースレコードの構文を示します。
[optional name] [optional TTL] class HINFO hardware OS
ホスト情報 (HINFO) リソースレコードでは、ホスト固有のデータを指定します。ハードウェアとこのホストで動作しているオペレーティングシステムを指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。各ホストに1 つの HINFO レコードが必要です。例 27-8 に HINFO リソースレコードの例を示します。
;[name] [TTL] class HINFO hardware OS IN HINFO Sparc-10 UNIX
HINFO フィールドにはネットワーク上のマシンについての情報があるので、多くのサイトで、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。
例 27-9 に、既知サービス (WKS) リソースレコードの構文を示します。
[Optional name] [ TTL] class WKS address protocol-list-of-services
既知サービス (WKS) レコードには、指定されたアドレスの特定のプロトコルでサポートされるよく知られたサービスが記述されます。サービスのリストとポート番号はサービスデータベースで指定されたサービスのリストから得られます。各プロトコルの各アドレスに 1 つの WKS レコードが必要です。 例 27-10 に 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 レコードはオプションです。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。
例 27-11 に、正規名 (CNAME) リソースレコードの構文を示します。
nickname [optional TTL] class CNAME canonical-name
正規名 (CNAME) リソースレコードでは、正規名に対するニックネームまたは別名を指定します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームの作成と他のリソースレコードでの使用はしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。 また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 27-12に CNAME リソースレコードの例を示します。
;nickname [TTL] class CNAME canonical-name mailhost IN CNAME antares.doc.com
例 27-13 に、ポインター (PTR) リソースレコードの構文を示します。
special-name [optional TTL] class PTR-real-name
特別名でドメイン内の他の場所を指すことが、ポインタレコードによって可能になります。例では、PTR は、アドレス (特別名) の実名への変換のために、主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときは、ドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。 PTR の名前付けは、ゾーンに対して一意である必要があります。PTR レコードによって特別なドメインであるin-addr.arpa.ドメインに対する逆ポインタが設定 (例 27-14) されます。
;special name [TTL] class PTR-real-name 1 IN PTR sirius.doc.com.
例 27-15 に、メール交換 (MX) リソースレコードの構文を示します。
name [optional TTL ] class MX preference-value mailer-exchanger
メール交換リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。対象としている名前に対して複数の MX リソースレコードがあるかもしれません。 例 27-16 では、 Seismo.CSS.GOV (完全指定のドメイン名) は、 Munnari.OZ.AU にメールを配信するメールゲートウェイです。ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。 Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポートメディアを使用している場合もあります。優先値フィールドで、メールプログラムが従うべき順を指定します。単一のマシンに複数の方法でメールが配信される場合に指定します。値が 0 (ゼロ) は最優先であることを意味します。同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値は同じであることも、同じでないこともあります。
メールをルーティングするために、MX レコードでワイルドカードであるアスタリスク ( * ) を名前に使うこともできます。あるドメイン宛のメールはリレー経由で配信されることを単に示すサーバーがネットワーク上にはよくあります。 例 27-16 では、 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.
Solaris リリース 2.6 では、コンパイル版の Berkeley Internet Name Domain (BIND) バージョン 4.9.4、パッチレベル 1 を提供します。Solaris 2.6 リリースでは、コンパイル版の BIND を提供しています。このソフトウェアのコンパイル時には、たくさんのサイトでの様々なニーズに対応するためにオプションの設定や選択が行われました。しかし、もしこのコンパイル版の BIND がニーズに合わない場合、公に入手可能なソースコードを用いて、再コンパイルし、自分用のオリジナルのバージョンの BIND を作成することもできます。
Solaris 2.6 リリースで供給される BIND バージョンのコンパイルでは、以下の選択が行われました。
「RFC1535」
「逆参照」
「Bogus ネームロギング」
「デフォルトのドメイン名」
DNS ドメイン名が /etc/resolv.conf 内または LOCALDOMAIN
環境変数で設定されていない場合、 libresolv は、デフォルトのドメイン名を NIS または NIS+ のドメイン名から導き出します。ただし、それは /etc/nsswitch.conf ファイルが hosts 行の最初の要素として nisplus または nis を含んでいる場合です。
「ユーティリティスクリプト」
「テストプログラム」
BIND のテストプログラムである dig、dnsquery、host は、今回の Solaris リリースには含まれていません。これらのテストプログラムの目的は、nslookup と nstest の目的と同様です。
この章では、DNS の管理方法を説明します。 詳しくは、Cricket Liu、Paul Albitz 著『DNS and Bind』(O'Reilly, 1992) と『Name Server Operations Guide for BIND』, University of California, Berkeley をお読みください。
DNS 関連のファイルで作業する際、ドメイン名の終わりにつけるドットに関しては以下に述べるルールに従ってください。
hosts、hosts.rev、named.ca、 named.local の各データファイル内のドメイン名には sales.doc.com.のように終わりにドットを付ける
named.boot または resolv.conf ファイルのドメイン名には sales.doc.com のように終わりにドットを付けない
マスター DNS サーバー内の DNS データファイルのひとつに対して、ホストの追加および削除、またはそれ以外の何らかの変更、あるいは DNS データファイルの修正を行なったときには、以下のことも行なってください。
副サーバーがそのデータを変更するように、SOA リソースレコードのシリアル番号を変更します (「SOA のシリアル番号の変更」を参照)。
データファイルを再度読み込み、内部データベースを更新するためにマスターサーバーの in.named に情報を与えます (「in.named に DNS データを強制的に再読み込みさせる」を参照)。
すべての DNS データベースファイルには権限の開始 (SOA) リソースレコードがあります。DNS データベースのデータを変更したときはいつでも、SOA シリアル番号を 1 増加させる必要があります。
たとえば、データファイルの SOA のシリアル番号が現在 101 で、ファイルのデータに変更を加えたなら、シリアル番号を 101 から 102 に変更する必要があります。SOA のシリアル番号を変更しないと、ドメインの副サーバーは、新しい情報でデータベースファイルのコピーを更新しません。その結果主サーバーと副サーバーは同期しなくなります。
一般的な SOA レコードの例である hosts ファイルは以下のとおりです。
; 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.boot を再び読み込み、データベースを再度読み込むには、以下のとおり入力します。
# kill -HUP `cat /etc/named.pid`
これを行うと以前のキャッシュはすべて削除され、キャッシュの処理が再スタートされます。
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 123.45.6.112
主サーバーの hosts ファイルに rigel のためのオプションのレコードを追加します。
オプションのレコードには以下のものがあります。
エイリアス (CNAME)
メール交換 (MX)
よく知られたサービス (WKS)
ホスト情報 (HINFO)
hosts.rev ファイルに rigel のための PTR レコードを追加します。
主サーバーの hosts ファイルと hosts.rev ファイルの SOA シリアル番号を増やします。
サーバーのデータを再ロードします。
サーバーをリブートするか、または以下のとおり入力します。
# kill -HUP `cat /etc/named.pid`
これらの手順は、『Solaris ネーミングの設定と構成』で詳しく説明されています。
DNS ドメインからマシンを取り除く場合は次のように実行します。
削除するマシンの nsswitch.conf ファイルの hosts の行から dns を削除します。
マシンの /etc/resolv.conf ファイルを削除します。
主サーバーの hosts ファイルと hosts.rev ファイルからそのマシンのレコードを削除します。
CNAME レコードがそのマシンにあるなら、その CNAME のレコードも hosts ファイルから削除される必要があります。
削除されるマシンによってサポートされていたサービスの代替を設定します。
マシンが主サーバー、メールホスト、その他必要なプロセスまたはサービスのホストである場合、そのマシンが行なっていたサービスを他のマシンで実行できるように設定する必要があります。
ネットワークに主サーバーや副サーバーを追加できます。DNS サーバーを追加するには、以下のとおりにしてください。
DNS クライアントとしてサーバーを設定します。
詳細は、「マシンの追加」を参照してください。
サーバーのブートファイルを設定します。
サーバーの named.ca ファイルを設定します。
サーバーの hosts ファイルを設定します。
サーバーの hosts.rev ファイルを設定します。
サーバーの named.local ファイルを設定します。
サーバーを初期化します。
サーバーをテストします。
以上の手順については、『Solaris ネーミングの設定と構成』に詳しい説明があります。
ネットワークは大きくなっていくので、ネットワークを複数の DNS サブドメインに分割すると便利です (DNS のドメインの階層と構造については、「DNS 名前空間について」を参照)。
ネットワークを親ドメインとひとつ以上のサブドメインに分割すると、負担が複数のドメインに分散して、各 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 つ以上のサブドメインに分割する前に考慮しておくべきポイントをここで述べます。
「サブドメインの数」
作成するサブドメインが多ければ、それだけ初期設定の作業が増え、運用時の親ドメインでの管理者の調整作業も増えます。多くのサブドメインがあれば、親ドメインのサーバーのために委任される作業もその分増加します。一方で、ドメインの数が少ないということは各ドメインが大きいということを意味し、ドメインが大きければ、それをサポートするためにサーバーのスピードやメモリーが余計必要だということです。
「ネットワークの分割方法」
ネットワークはどのようにでも複数のドメインに分割できます。最も一般的な方法が 3 つあります。まず、組織の構成によるもので、各部署 (営業、研究開発、製造、など) に別々のサブドメインを持つ方法です。次に、地理的なもので、各サイトに別々のサブドメインを持つ方法です。最後に、ネットワークの構造によるもので、大きなネットワーク構成要素ごとに別々のドメインを持つ方法です。ドメインの構造が、統一されていて、論理的で、明確であれば、管理も利用もより簡単になります。
「将来に対する考慮」
もっとも問題が多いのは、時間の経過とともに、新しいサイトや部が増えて、サブドメインが無計画に追加されて大きくなったドメインです。可能な限り、将来のドメインの拡大を見越してドメインの階層を設計してください。安定性も考慮に入れてください。最も安定しているものを基礎として、サブドメインが分けられているのがベストです。たとえば、地理的なサイトは比較的安定しているけれども、部や課が頻繁に再編成されるなら、サブドメインは組織よりも地理的な位置に基づいて決定すべきです。一方、組織は比較的安定しているが、サイトが頻繁に追加されたり、変更されたりする場合は、サブドメインは組織に基づいて決定してください。
「広域ネットワーク (WAN) とのリンク」
ネットワークがモデムまたは専用回線で接続された複数のサイトに広がっている場合、広域ネットワーク (WAN) のリンクにドメインが広がっていないなら、パフォーマンスと信頼性は高くなります。WAN のリンクは連続的なネットワーク接続より遅く、失敗に終わる傾向があります。サーバーが、WAN のリンク経由だけで接続できるマシンをサポートしなければならないときは、より遅いリンクを経由するトラフィックファネリングが増加することになります。この場合、もしひとつのサイトで停電や何か他の問題が起こった場合には、相手のサイトのマシンにも影響を及ぼしてしまうかもしれません。(同様のパフォーマンスと信頼性の配慮は 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 ファイルを各マシンにインストールする必要があります。これらのファイルについては、『Solaris ネーミングの設定と構成』を参照してください。
正しく設定されたブートファイルと DNS データファイルをサブドメインの主マスターサーバーにインストールします。
各サーバーに以下のファイルをインストールします (詳細は、『Solaris ネーミングの設定と構成』を参照)。
/etc/named.boot.
/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 を副マスターサーバーとして指定するとします。すると、以下に示すレコードを aldebaran の主マスターサーバーのホストファイルに追加することになります。
manf.doc.com 99999 IN NS rigel.manf.doc.com 99999 IN NS aldebaran.manf.doc.com
新しいサブドメインのサーバーの A レコードを、親ドメインのホストファイルに追加します。
引き続き上の例で考えると、以下に示すレコードを doc.com の主マスターサーバーのホストファイルに追加することになります。
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 を実行する代わりに、リブートもできます。詳細は、『Solaris ネーミングの設定と構成』を参照してください。
DNS の問題解決とエラーメッセージに関しては、付録 A 「問題と解決方法」
と付録 B 「エラーメッセージ」 を参照してください。