この章ではドメイン名システム (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+ のホストテーブル、ipnodes やローカルの /etc/hosts ファイル、/etc/inet/ipnodes ファイルも同様の情報、すなわち、ホスト名、ipnodes 名、IPv4、IPv6 のアドレス、その他コンピュータの特定のグループに関する情報を保持していますが、DNS データベースはそれらとはあまり似ていません。ローカルマシンは、遠隔マシンの IP アドレスを見つけたり、解決したりするためのリクエストの一部として自分自身のホスト名を送信しますが、ネームサーバーは、それも利用します。そして、もしリクエストしたホスト名が DNS データベースにあれば、その IP アドレスがネームサーバーによってローカルマシンに返されます。
図 28-1 に、DNS クライアントのローカルネットワーク上でクライアントとネームサーバーの間での名前のアドレスマッピングを示します。
もし、ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。このために、各ネームサーバーは、ローカル管理ドメインに対して権限があるとされています。
幸い、ローカルネームサーバーには、ルートドメインネームサーバーのホスト名と IP アドレスのリストがあります。そしてローカルネームサーバーは、ローカルマシンからのリクエストを「ルートドメインネームサーバー」に転送します。ルートネームサーバーは、「DNS 階層とインターネット」で説明したように、大きな組織のドメインに対して権限があります。その階層は、上下のツリー構造で編成された UNIX のファイルシステムに似ています。
各ルートネームサーバーには、会社、大学、その他大規模な組織における最上位のドメインネームサーバーのホスト名と IP アドレスがあります。ルートネームサーバーは、ホスト名と IP アドレスがわかっているすべての最上位のネームサーバーにローカルマシンからのリクエストを送信します。リクエストされたホストの IP アドレスを最上位のネームサーバーのどれかが持っている場合、その情報がローカルマシンに返されます。最上位のサーバーがリクエストされたホストに関する情報を持っていない場合、第 2 レベルのネームサーバーにリクエストが渡されます。このようにローカルマシンからのリクエストは組織の巨大なツリー構造の下へ向かって順に渡されます。最終的にローカルマシンからのリクエストに対する情報をデータベースに持っているネームサーバーが IP アドレスを返します。
図 28-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 8 リリース環境に含まれています。
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 8 リリース環境には、リゾルバを構成している動的ライブラリルーチンが含まれています。『Solaris ネーミングの設定と構成』で、ホストを DNS クライアントとして設定する方法が説明されています。
全世界の DNS 管理ドメインの集合全体は「 DNS 名前空間」と呼ばれる階層構造を形成しています。ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。
DNS ドメインは、UNIX のファイルシステムと同様、木の根に似た下に向きの枝分かれで構成されています。各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。「ドメイン」と「サブドメイン」は相対的な関係を示します。階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。
たとえば、図 28-3 において com は Acme、Ajax、AAA の各ドメインの親ドメインです。あるいは、これらのドメインは com ドメインのサブドメインということもできます。このように考えると、Ajax ドメインは4つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。
あるドメインには、1 つの親 (あるいは最上位) ドメインと、(もしあれば) その下のサブドメインが含まれます。ドメインの名前付けは最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。図 28-3 の Mktg.Corp.Ajax.Com. がその例です。
大規模な会社であれば、多くのドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。図 28-4 に、ある会社に存在するドメインの階層構造の例を示します。この会社の最上位のドメイン、すなわちルートドメインは ajax.com で、sales.ajax.com、test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。
DNS クライアントは、そのドメインをサポートするサーバーだけにサービスをリクエストします。もし、クライアントの必要としている情報がそのドメインサーバーにない場合、リクエストは親サーバーに転送されます。親サーバーは、1 つ上の階層のドメインサーバーです。リクエストが最上位のサーバーに達した場合、最上位のサーバーはリクエストされたドメインが有効かどうか調べます。それが有効でない場合、サーバーは「not found」というメッセージをクライアントに返します。リクエストされたドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。
図 28-4 に示したドメインの階層は、概念的には世界規模のインターネット上でサポートされる巨大な DNS 名前空間の枝葉のようなものです。
インターネットの DNS 名前空間は 図 28-5 で示すように階層状に組織されます。それは、ピリオド (.) で表されるルートディレクトリと最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。com ドメイン (図 28-3) はインターネットに存在する最上位の組織ドメインの 1 つです。
現在、組織的な階層の名前空間は、表 28-1 に示した最上位のドメインに分けられます。将来、これ以外にも最上位の組織ドメインが追加される可能性があります。
表 28-1 インターネットの組織ドメイン
ドメイン |
目的 |
---|---|
com |
営利団体 |
edu |
教育機関 |
gov |
行政機関 |
mil |
軍事組織 |
net |
大手のネットワークサポートセンター |
org |
非営利団体、その他 |
int |
国際組織 |
地理的な階層においては、各国に対して 2、3 文字の識別子が割り当てられ、それが、各国に対する公式名として用いられます。たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。
インターネットのルートドメイン、すなわち最上位のドメイン (組織的および地理的) は、様々なインターネット運営体によって管理されています。規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。
DNS ドメインはドメイン名を持つ必要があります。インターネットに接続しないで、ネームサービスとして DNS を使用したいのであれば、ドメインやサブドメインに任意の名前を付けることができます。しかし、インターネットに参加するのであれば、そのドメイン名はインターネット運営体に登録する必要があります。
インターネットに接続するために必要な条件は以下のとおりです。
上記のことを行うには、以下のような 2 つの方法があります。
適当なインターネット運営体またはその代理団体と直接連絡をとる方法。アメリカ合衆国では、現在 InterNIC 社がネットワークアドレスとドメインの登録を取り扱っています。
インターネットサービスプロバイダ (ISP) と契約する方法。ISP は、コンサルティングから実際の接続まで広範なサービスを提供しています。
ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。たとえば、図 28-4 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。したがって、そのインターネットドメイン名は ajax.com となります。
図 28-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 アドレスに変換します。
たとえば、図 28-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.conf と呼ばれるブートファイル、resolv.conf という名前のリゾルバファイル、4 つのタイプのゾーンデータファイルがあります。
内部的に矛盾がなければ、ゾーンデータファイルはどんな名前にもできます。このため、異なるサイトで作業をしようとする場合や DNS 関連のマニュアルや本を参照する場合に、混乱するかもしれません。たとえば、Sun のマニュアルやほとんどの Solaris のサイトのファイル名は、『DNS and BIND』(Paul Albitz & Cricket Liu 著 浅羽登志也/上水流由香 監訳、アスキー出版局、1995年) で使用されている名前とは異なりますし、その両方の命名法は、『Name Server Operations Guide for BIND』(カリフォルニア州立大学刊、パブリックドメイン) での命名法とも若干異なります。
さらに、このマニュアルや他の DNS の文書では、そのファイルの主要な目的を表すために汎用的な名前が用いられ、レコードの例ではそのファイルに対して例として特定の名前が用いられています。たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能と役割を記述するために hosts が総称名として用いられ、db.doc と db.sales.doc という名前が、例として用いられています。
参考として、表 28-2 では上で述べた 3 つのマニュアルにおける BIND のファイル名を比較します。
表 28-2 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 |
逆変換 (アドレスから名前への変換) が可能な特殊ドメイン in-addr.arpa. 内のゾーンを指定する |
named.local |
総称名: db.cache 例: db.127.0.0 |
named.local |
ローカルループバックインタフェース (local host) 用のアドレスを指定する |
$INCLUDE ファイル |
$INCLUDE ファイル |
$INCLUDE ファイル |
データファイル内の $INCLUDE() ステートメントによって識別されるファイル |
BIND 8.1 は、新しい構成ファイル /etc/named.conf を追加し、/etc/named.conf ファイルと置き換えます。/etc/named.conf ファイルは、サーバーを、主、副、またはキャッシュ専用ネームサーバーとして確立します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルを読み取って初期データを取得するかを指定します。
/etc/named.conf ファイルには、以下を実現するステートメントが含まれています。
NIS+ ホストが読み取り権/書き込み権を持つ IP アドレスのコレクションを定義するアクセス制御リスト (ACL) によるセキュリティ
ログ仕様
構成ファイルは、デーモンがサーバーの起動スクリプト /etc/init.d/inetsvc によって起動されるとき、in.named によって読み取られます。構成ファイルは、in.named を他のサーバーまたは指定されたドメインのローカルデータファイルに導きます。
named.conf ファイルには、ステートメントおよびコメントが含まれています。ステートメントはセミコロンで終わります。一部のステートメントは、ステートメントのブロックを含むことができます。ブロックの中の各ステートメントもセミコロンで終わります。
named.conf ファイルは、以下のステートメントをサポートします。
表 28-3acl | アクセス制御に使用する名前付き IP アドレス一致リストを定義。このアドレス一致リストは、1 つ以上の IP アドレス (小数点表記) または IP 接頭辞 (小数点表記の後にスラッシュとネットマスクのビット数をつけたもの) を指定する。acl ステートメントによって名前付き IP アドレス一致リストを定義しなければ、他の場所で名前付き IP 一致リストを使用することはできまない。前方参照は不可 |
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; }; }; |
スーパーユーザーになって、Korn シェルスクリプト /usr/sbin/named-bootconf を実行して BIND 4.9.x の named.boot ファイルを BIND 8.1.x の named.conf ファイルに変換します。named-bootconf(1M) を参照してください。
Solaris 8 では、named.boot ファイルは無視されます。
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) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。
namettl 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 フィールドの中身は、特定のリソースレコードのタイプで異なります。
ネームフィールドやデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。しかし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。
次に挙げる文字には特別な意味があります。
表 28-4 特別な意味を持つリソースレコード文字
文字 |
定義 |
---|---|
. |
ネームフィールドで、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.conf ファイルの primary または secondary の行の 2 番目のフィールドにあるドメイン名です。
最も一般的に使用されるリソースレコードのタイプを 表 28-5 に列挙します。通常、表 28-5 に並んだ順で入力しますが、必須というわけではありません。
表 28-5 一般的に利用されるリソースレコードのタイプ
タイプ |
説明 |
---|---|
SOA |
権限の開始 |
NS |
ネームサーバー |
A |
インターネットアドレス (名前からアドレス) |
PTR |
ポインタ (アドレスから名前) |
CNAME |
正規名 (ニックネーム) |
TXT |
テキスト情報 |
WKS |
既知サービス |
HINFO |
ホスト情報 |
MX |
メール交換 |
例 28-2 に 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 つだけ指定してください。例 28-3 に 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 ) |
例 28-4 に、ネームサーバー (NS) リソースレコードの構文を示します。
domainname [optional TTL] class NS name-server-name |
ネームサーバーレコードには、対象としているドメインを受け持つサーバーの名前を指定します。name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。もし、name フィールドが指定されない場合、そのデフォルトは最後に指定された名前になります。そのドメインの主マスターサーバーと副マスターサーバーのそれぞれに 1 つの NS レコードが必要です。例 28-5 に NS リソースレコードの例を示します。
;domainname [TTL] class NS nameserver doc.com 90000 IN NS sirius.doc.com. |
例 28-6 に、アドレス (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 |
例 28-8 に、ホスト情報 (HINFO) リソースレコードの構文を示します。
[optional name] [optional TTL] class HINFO hardware OS |
ホスト情報 (HINFO) リソースレコードでは、ホスト固有のデータを指定します。ハードウェアとこのホストで動作しているオペレーティング環境を指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。各ホストに1 つの HINFO レコードが必要です。例 28-9 に HINFO リソースレコードの例を示します。
;[name] [TTL] class HINFO hardware OS IN HINFO Sparc-10 UNIX |
HINFO フィールドにはネットワーク上のマシンについての情報があるので、多くのサイトで、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。
例 28-10 に、既知サービス (WKS) リソースレコードの構文を示します。
[Optional name] [TTL] class WKS address protocol-list-of-services |
既知サービス (WKS) レコードには、指定されたアドレスの特定のプロトコルでサポートされるよく知られたサービスが記述されます。サービスのリストとポート番号はサービスデータベースで指定されたサービスのリストから得られます。各プロトコルの各アドレスに 1 つの WKS レコードが必要です。例 28-11 に 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 レコードはオプションです。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。
例 28-12 に、正規名 (CNAME) リソースレコードの構文を示します。
nickname [optional TTL] class CNAME canonical-name |
正規名 (CNAME) リソースレコードでは、正規名に対するニックネームまたは別名を指定します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームの作成と他のリソースレコードでの使用はしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 28-13 に CNAME リソースレコードの例を示します。
;nickname [TTL] class CNAME canonical-name mailhost IN CNAME antares.doc.com |
例 28-14 に、ポインター (PTR) リソースレコードの構文を示します。
special-name [optional TTL] class PTR-real-name |
特別名でドメイン内の他の場所を指すことが、ポインタレコードによって可能になります。例では、PTR は、アドレス (特別名) の実名への変換のために、主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときは、ドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。PTR の名前付けは、ゾーンに対して一意である必要があります。PTR レコードによって特別なドメインである in-addr.arpa.ドメインに対する逆ポインタが設定 (例 28-15) されます。
;special name [TTL] class PTR-real-name 1 IN PTR sirius.doc.com. |
例 28-16 に、メール交換 (MX) リソースレコードの構文を示します。
name [optional TTL] class MX preference-value mailer-exchanger |
メール交換リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。対象としている名前に対して複数の MX リソースレコードがあるかもしれません。例 28-17 では、Seismo.CSS.GOV (完全指定のドメイン名) は、Munnari.OZ.AU にメールを配信するメールゲートウェイです。ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポートメディアを使用している場合もあります。優先値フィールドで、メールプログラムが従うべき順を指定します。単一のマシンに複数の方法でメールが配信される場合に指定します。値が 0 (ゼロ) は最優先であることを意味します。同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値は同じであることも、同じでないこともあります。
メールをルーティングするために、MX レコードでワイルドカードであるアスタリスク ( *) を名前に使うこともできます。あるドメイン宛のメールはリレー経由で配信されることを単に示すサーバーがネットワーク上にはよくあります。例 28-17 では、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 リリース 8 では、コンパイル版の Berkeley Internet Name Domain (BIND) 8.1.2 を提供します。Solaris 8 リリースでは、コンパイル版の BIND を提供しています。このソフトウェアのコンパイル時には、たくさんのサイトでの様々なニーズに対応するためにオプションの設定や選択が行われました。しかし、もしこのコンパイル版の BIND がニーズに合わない場合、公に入手可能なソースコードを用いて、再コンパイルし、自分用のオリジナルのバージョンの BIND を作成することもできます。
Solaris 7 以降のリリースで提供される BIND バージョンのコンパイルでは、以下の選択が行われました。
「RFC1535」
「逆参照」
「Bogus ネームロギング」
「デフォルトのドメイン名」
DNS ドメイン名が /etc/resolv.conf 内または LOCALDOMAIN
環境変数で設定されていない場合、libresolv は、デフォルトのドメイン名を NIS または NIS+ のドメイン名から導き出します。ただし、それは /etc/nsswitch.conf ファイルが hosts 行の最初の要素として nisplus または nis を含んでいる場合です。
「ユーティリティスクリプト」
「テストプログラム」
BIND のテストプログラムである dig、dnsquery、host は、今回の Solaris リリースには含まれていません。これらのテストプログラムの目的は、nslookup と nstest の目的と同様です。