test

Solaris ネーミングの管理

第 28 章 DNS の紹介

この章ではドメイン名システム (DNS) の構造と概要を説明します。

DNS サービスの初期設定と構成に関する情報は、『Solaris ネーミングの設定と構成』を参照してください。

注 -

DNS の利用で最も一般的で重要なことは、ネットワークをグローバルなインターネットに接続することです。インターネットに接続するには、ローカルなネットワークの IP アドレスが親ドメインの管理者のところに登録されている必要があります。管理者はそれぞれの地理的条件や親ドメインのタイプによって異なります。

DNS の基礎

ドメイン名システム (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 クライアントのローカルネットワーク上でクライアントとネームサーバーの間での名前のアドレスマッピングを示します。

図 28-1 名前のアドレス解決

Graphic

もし、ホスト名がネームサーバーの DNS データベースになければ、そのマシンは権限の外側にある、すなわち、DNS の用語でいう「ローカル管理ドメイン」の外側にあることを意味します。このために、各ネームサーバーは、ローカル管理ドメインに対して権限があるとされています。

幸い、ローカルネームサーバーには、ルートドメインネームサーバーのホスト名と IP アドレスのリストがあります。そしてローカルネームサーバーは、ローカルマシンからのリクエストを「ルートドメインネームサーバー」に転送します。ルートネームサーバーは、「DNS 階層とインターネット」で説明したように、大きな組織のドメインに対して権限があります。その階層は、上下のツリー構造で編成された UNIX のファイルシステムに似ています。

各ルートネームサーバーには、会社、大学、その他大規模な組織における最上位のドメインネームサーバーのホスト名と IP アドレスがあります。ルートネームサーバーは、ホスト名と IP アドレスがわかっているすべての最上位のネームサーバーにローカルマシンからのリクエストを送信します。リクエストされたホストの IP アドレスを最上位のネームサーバーのどれかが持っている場合、その情報がローカルマシンに返されます。最上位のサーバーがリクエストされたホストに関する情報を持っていない場合、第 2 レベルのネームサーバーにリクエストが渡されます。このようにローカルマシンからのリクエストは組織の巨大なツリー構造の下へ向かって順に渡されます。最終的にローカルマシンからのリクエストに対する情報をデータベースに持っているネームサーバーが IP アドレスを返します。

図 28-2 はローカルドメインの外側での名前のアドレス解決を示します。

図 28-2 遠隔ホストに対する名前のアドレス解決

Graphic

DNS 管理ドメイン

DNS から見ると「管理ドメイン」は 1 つの単位として管理されるマシン群を構成しています。このドメインに関する情報は、ドメインに対して権限を持つ 2 つ以上のネームサーバーで管理されます。DNS のドメインはマシンを論理的にグループ分けしたものですが、小規模のビジネスにおいて全マシンが Ethernet に接続された場合のように、マシンの物理的グループと対応している場合もあります。しかし、ローカル DNS ドメインには大学の大規模なネットワークのすべてのマシンが含まれることもあります。大学のネットワークにはコンピュータ学科や管理部門に属する多くのコンピュータがあります。

たとえば、Ajax という会社がサンフランシスコとシアトルの 2 つのサイト持っているとします。そして、シアトルのドメインが Retail.Sales.Ajax.com. で、Wholesale.Sales.Ajax.com. ドメインはサンフランシスコにあるとします。また、Sales.Ajax.com. ドメインが 2 つの市に分かれているとします。

各管理ドメインは、固有のサブドメイン名を持たなければなりません。さらに、ネットワークをインターネットに接続するのであれば、そのネットワークの属する管理ドメインはすでに登録されたものでなければなりません。ドメイン名とドメインの登録に関する詳細は 「インターネットへの参加」の節を参照してください。

in.named と DNS ネームサーバー

すでに説明したように、管理ドメイン内のネームサーバーは、DNS データベースを保持しています。また、ネームサーバーでは in.named デーモンが動作しています。このデーモンで DNS サービスが実装されます。そのサービスの中でも重要なのが名前のアドレスマッピングです。in.named はパブリックドメインの TCP/IP プログラムで Solaris 8 リリース環境に含まれています。

注 -

in.named デーモンは、カリフォルニア大学バークレー校で開発されたので、Berkeley Internet Name Domain service (BIND) と呼ばれることもあります。

以下のような、3 つのタイプの DNS ネームサーバーがあります。

各ドメインには、主サーバーが 1 つとバックアップのための副サーバーが少なくとも 1 つ必要です。主サーバーと副サーバーの詳細は、「ゾーン」を参照してください。

DNS クライアントとリゾルバ

あるマシンを 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 つの種類があります。

Solaris 8 リリース環境には、リゾルバを構成している動的ライブラリルーチンが含まれています。『Solaris ネーミングの設定と構成』で、ホストを DNS クライアントとして設定する方法が説明されています。

DNS 名前空間について

全世界の DNS 管理ドメインの集合全体は「 DNS 名前空間」と呼ばれる階層構造を形成しています。ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。

DNS 名前空間の階層

DNS ドメインは、UNIX のファイルシステムと同様、木の根に似た下に向きの枝分かれで構成されています。各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。「ドメイン」と「サブドメイン」は相対的な関係を示します。階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。

図 28-3 ドメインとサブドメイン

Graphic

たとえば、図 28-3 において com は Acme、Ajax、AAA の各ドメインの親ドメインです。あるいは、これらのドメインは com ドメインのサブドメインということもできます。このように考えると、Ajax ドメインは４つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。

あるドメインには、1 つの親 (あるいは最上位) ドメインと、(もしあれば) その下のサブドメインが含まれます。ドメインの名前付けは最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。図 28-3 の Mktg.Corp.Ajax.Com. がその例です。

ローカルドメイン内の DNS 階層

大規模な会社であれば、多くのドメインをサポートしており、ローカルな名前空間が構成されていることでしょう。図 28-4 に、ある会社に存在するドメインの階層構造の例を示します。この会社の最上位のドメイン、すなわちルートドメインは ajax.com で、sales.ajax.com、test.ajax.com、manf.ajax.com の 3 つのサブドメインがあります。

図 28-4 ある組織での DNS ドメインの階層

Graphic

DNS クライアントは、そのドメインをサポートするサーバーだけにサービスをリクエストします。もし、クライアントの必要としている情報がそのドメインサーバーにない場合、リクエストは親サーバーに転送されます。親サーバーは、1 つ上の階層のドメインサーバーです。リクエストが最上位のサーバーに達した場合、最上位のサーバーはリクエストされたドメインが有効かどうか調べます。それが有効でない場合、サーバーは「not found」というメッセージをクライアントに返します。リクエストされたドメインが有効な場合、最上位のサーバーはそのドメインをサポートしているサーバーに要求を転送します。

DNS 階層とインターネット

図 28-4 に示したドメインの階層は、概念的には世界規模のインターネット上でサポートされる巨大な DNS 名前空間の枝葉のようなものです。

インターネットの DNS 名前空間は 図 28-5 で示すように階層状に組織されます。それは、ピリオド (.) で表されるルートディレクトリと最上位のドメインの階層 2 つ (組織的なものと地理的なもの) で構成されます。com ドメイン (図 28-3) はインターネットに存在する最上位の組織ドメインの 1 つです。

図 28-5 インターネットのドメインの階層

Graphic

現在、組織的な階層の名前空間は、表 28-1 に示した最上位のドメインに分けられます。将来、これ以外にも最上位の組織ドメインが追加される可能性があります。

表 28-1 インターネットの組織ドメイン

ドメイン 

目的 

com

営利団体 

edu

教育機関 

gov

行政機関 

mil

軍事組織 

net

大手のネットワークサポートセンター 

org

非営利団体、その他 

int

国際組織 

地理的な階層においては、各国に対して 2、3 文字の識別子が割り当てられ、それが、各国に対する公式名として用いられます。たとえば、イギリス国内のドメインは、uk という最上位のドメインのサブドメインになります。日本国内のドメインは、jp のサブドメインで、他の国に関しても同様です。

インターネットへの参加

インターネットのルートドメイン、すなわち最上位のドメイン (組織的および地理的) は、様々なインターネット運営体によって管理されています。規模にかかわらずネットワークを有する人は、そのネットワークのドメイン名を組織的な階層か地理的な階層に登録することによってインターネットに参加できます。

DNS ドメインはドメイン名を持つ必要があります。インターネットに接続しないで、ネームサービスとして DNS を使用したいのであれば、ドメインやサブドメインに任意の名前を付けることができます。しかし、インターネットに参加するのであれば、そのドメイン名はインターネット運営体に登録する必要があります。

インターネットに接続するために必要な条件は以下のとおりです。

上記のことを行うには、以下のような 2 つの方法があります。

ドメイン名

ドメイン名は、DNS 名前空間全体でのドメインの位置を表します。それは UNIX のファイルシステムでパス名がファイルの位置を表しているのと同じです。ローカルドメインが登録されると、そのドメイン名は所属するインターネットの階層の名前に追加されます。たとえば、図 28-4 で示した Ajax ドメインはインターネットの階層である com の一部として登録されました。したがって、そのインターネットドメイン名は ajax.com となります。

図 28-6 は、ajax.com ドメインがインターネット上の DNS 名前空間のどこに位置しているのかを示しています。

図 28-6 DNS 名前空間における Ajax ドメインの位置

Graphic

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 ファイルの絶対パス名と同様に、ルートへのパスを示しています。しかし、完全指定ドメイン名を読む場合、左から右に行くにしたがって最下位から最上位となります。したがって、完全指定ドメイン名は次のような構文になっています。

Graphic

ajax ドメインとそのサブドメインの完全指定ドメイン名は次のとおりです。


ajax.com.
sales.ajax.com
test.ajax.com.
manf.ajax.com

ここで、一番右に付けられたドット (.) に注意してください。

ゾーン

あるドメインの DNS サービスは、「in.named と DNS ネームサーバー」で最初に説明したネームサーバーの集合で管理されます。ネームサーバーは、単一のドメイン、複数のドメイン、複数のドメインとその下のサブドメインの一部または全部を管理できます。あるネームサーバーによって制御される名前空間の一部は、「ゾーン」と呼ばれます。したがって、ネームサーバーはゾーンに対して権限があるといわれます。ネームサーバーの責任者は、ゾーン管理者とも呼ばれます。

ネームサーバーのデータベース内のデータは、「ゾーンファイル」と呼ばれます。ゾーンファイルの 1 つには IP アドレスとホスト名が格納されています。ftp または telnet のようなユーティリティでホスト名を用いて遠隔ホストに接続しようとすると、DNS は名前のアドレスマッピングを実行し、ゾーンファイルの中でホスト名を探して、IP アドレスに変換します。

図 28-7 ドメインとゾーン

Graphic

たとえば、図 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 ドメイン

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 サーバー

DNS サーバーには複数の機能があります。

個々の異なるサーバーの機能は、同一のマシン上でも実行可能です。たとえば、あるマシンを、あるゾーンの主マスターサーバーにし、同時に別のゾーンの副マスターサーバーにできます。このマニュアルでは、主サーバー、副サーバー、キャッシュオンリーサーバーというのは特定のマシンの呼び名ではなく、マシンがあるゾーンに対して果たしている役割のことを指しています。

マスターサーバー

マスターネームサーバーは、ゾーンに対応するすべてのデータを保持しています。マスターサーバーは一般に、権限があるネームサーバーと呼ばれます。任意のゾーンに対応するデータは 2 つ以上の権威があるサーバーで使用可能になっている必要があります。ここで、1 つのネームサーバーは主マスターサーバーとし、少なくとも 1 つ以上は副マスターサーバーとする必要があります。副マスターサーバーは、主マスターサーバーが使用できないときや負荷過剰のときのバックアップとして機能します。

サーバーは複数のゾーンに対するサーバーとして機能できます。すなわち、あるゾーンに対しては主マスターで、別のゾーンに対しては副マスターとなります。

主マスターサーバー

主マスターサーバーは、自分用のデータのマスターコピーを in.named の起動時にディスクから読み込む DNS ネームサーバーです。ゾーンの主マスターサーバーは、そのゾーンに対する変更を行なった場所にあります。主マスターサーバーは、そのゾーンに関する DNS 情報の情報源です。また、主マスターサーバーはそのゾーン内の副サーバーやゾーン外のサーバーに権限を任せることもあります。

副マスターサーバー

副マスターサーバーにはそのゾーン用のデータのコピーがあります。主サーバーはそのデータを副サーバーに送り、権限を任せます。クライアントは、DNS 情報を副サーバーに照会できます。副サーバーを使用することによって、負荷が複数のマシンに分散され、応答時間を短縮してネットワークのオーバーヘッドを減らすことができます。また、副サーバーは、主サーバーが使用できないときに代わりの機能を果たします。

副サーバーは in.named を起動するとき、ゾーンに関するすべての情報を主サーバーにリクエストします。副サーバーはデータベースを更新する必要があるかどうかを調べるために主サーバーを定期的にチェックします。最新のゾーンデータベースを主サーバーから副サーバーに送信するプロセスを「ゾーン転送」と呼びます。したがって、副サーバー上のデータファイルは変更しません。ゾーンの主サーバーのデータサーバーを変更します。そして、副サーバーのファイルは主サーバーから変更されます。

キャッシュサーバーとキャッシュオンリーサーバー

すべてのネームサーバーは「キャッシュサーバー」です。ネームサーバーは受け取ったデータをそれが期限切れになるまでキャッシュに書き込みます。期限切れのプロセスは、データに結びついている生存期間 (time-to-live = TTL) フィールドで制御されます。

さらに、どんなゾーンに対しても権限がない「キャッシュオンリーサーバー」を設定することもできます。キャッシュオンリーサーバーは、in-addr.arpa. ドメイン以外のゾーンだけに対してのマスターサーバーです。キャッシュオンリーサーバーは、権限があるネームサーバーが処理するのと同様の照会を扱いますが、権威データ自体は保持しません。

キャッシュオンリーサーバーは、権限があるサーバーより少ないメモリーで動作しますが、もし主サーバーまたは副サーバーが使用できない場合、キャッシュオンリーサーバーだけでは機能しません。

ルートドメインネームサーバー

DNS 名前空間には、ルートドメインに対して権限がある「ルートドメインネームサーバー」が 1 つ以上必要です。

ルートドメインネームサーバーを識別する情報はキャッシュファイルに格納されています。このマニュアルでも、またほとんどの Solaris のサイトでも、このキャッシュファイルを named.ca (このファイルのどこでも共通の別名は root.cache、named.root、db.cache) と呼びます。各サーバーのブートファイルには、ルートドメインネームサーバーの情報を保持しているファイルを識別するレコードがあります。

インターネットルートドメインサーバー

ネットワークがインターネットに接続されている場合、DNS ネームサーバーのブートファイルでは、共通キャッシュファイル (一般に named.ca と呼ばれる) を指定して、ルートドメインネームサーバーを識別する必要があります。このファイルのテンプレートは、以下のいずれかを通して、InterNIC から入手できます。

このマニュアルに記載の方法で DNS のファイルに名前を付けるのであれば、上記の方法で入手したファイルは、/var/named/named.ca とする必要があります。

非インターネットルートドメインサーバー

ネットワークがインターネットに接続されていない場合、ルートドメインネームサーバーとして機能するように 1 つ以上のサーバーを設定する必要があります。ネットワーク上のすべての DNS ネームサーバーのブートファイルで共通のキャッシュファイル (一般的には named.ca) を指示する必要があります。これで、ルートドメインネームサーバーが識別されます。次に、ルートドメインネームサーバーを識別するキャッシュファイルを作成します。

1 台のマシンを複数のマシンの主ドメインネームサーバーとすることができますので、ルートドメインネームサーバーを作成する最も簡単な方法は、最上位のドメインにサーバーを持ち、それを論理的な (.) ドメインのサーバーにすることです。

たとえば、ネットワークに solo というドメイン名を与えたとします。DNS マスターネームサーバーは dnsmaster.solo. (最後にドットを付ける) となります。この場合、dnsmaster を (.) ドメインのルートマスターサーバーとしたことになります。

ネットワークに最上位のドメインが複数ある場合、ルートドメインサーバー名は最上位のすべてのドメインの主ネームサーバーである必要があります。たとえば、ネットワークが、solo と private という名前の非階層の 2 つのドメインに分かれているとすると、同じサーバーが両方のルートマスターサーバーである必要があります。上の例では、dnsmaster.solo. が、solo と private の両方のドメインのルートドメインマスターとなります。

DNS のメールデリバリへの影響について

DNS には 2 つの基本的なサービスがあります。1 つは、「名前のアドレス解決」で 説明しているように 、名前からアドレス (またはその逆のアドレスから名前) のマッピングを行うサービスで、もう 1 つは、インターネット上でメールを配信する sendmail や POP といったメール配信エージェントを助けるサービスです。

インターネット上でメールを配信するのに、DNS は「メール交換レコード」(MX レコード) を用います。ほとんどの組織は、その組織内にあるホストに宛てられたインターネットから来るメールを直接配信することを許していません。そのかわりに、１台のセントラルメールホスト (またはメールホストの集合) を用いて、入ってくるメールメッセージを途中で止めて宛先に振り分けます。

メール交換レコードで、ドメイン内の各マシンにサービスを提供しているメールホストが識別されるため、メール交換レコードには遠隔組織の DNS ドメイン名と、その IP アドレスまたは対応するメールホストのホスト名のいずれかが列挙されています。

DNS の構成ファイルとデータファイル

DNS のネームサーバーには、in.named デーモンに加えて、named.conf と呼ばれるブートファイル、resolv.conf という名前のリゾルバファイル、4 つのタイプのゾーンデータファイルがあります。

DNS データファイル名

内部的に矛盾がなければ、ゾーンデータファイルはどんな名前にもできます。このため、異なるサイトで作業をしようとする場合や 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() ステートメントによって識別されるファイル

named.conf ファイル

BIND 8.1 は、新しい構成ファイル /etc/named.conf を追加し、/etc/named.conf ファイルと置き換えます。/etc/named.conf ファイルは、サーバーを、主、副、またはキャッシュ専用ネームサーバーとして確立します。また、サーバーが権限を持つゾーンを指定し、どのデータファイルを読み取って初期データを取得するかを指定します。

/etc/named.conf ファイルには、以下を実現するステートメントが含まれています。

構成ファイルは、デーモンがサーバーの起動スクリプト /etc/init.d/inetsvc によって起動されるとき、in.named によって読み取られます。構成ファイルは、in.named を他のサーバーまたは指定されたドメインのローカルデータファイルに導きます。

named.conf ステートメント

named.conf ファイルには、ステートメントおよびコメントが含まれています。ステートメントはセミコロンで終わります。一部のステートメントは、ステートメントのブロックを含むことができます。ブロックの中の各ステートメントもセミコロンで終わります。

named.conf ファイルは、以下のステートメントをサポートします。

表 28-3
aclアクセス制御に使用する名前付き IP アドレス一致リストを定義。このアドレス一致リストは、1 つ以上の IP アドレス (小数点表記) または IP 接頭辞 (小数点表記の後にスラッシュとネットマスクのビット数をつけたもの) を指定する。acl ステートメントによって名前付き IP アドレス一致リストを定義しなければ、他の場所で名前付き IP 一致リストを使用することはできまない。前方参照は不可
include include ステートメントのある箇所にインクルードファイルを挿入する。include を使用すると管理の簡単なかたまりに構成を分割できる
key特定のネームサーバー上での認証および承認に使用する鍵の ID を指定する。server ステートメントを参照
logging サーバーが記録する情報およびログメッセージの宛先を指定
options グローバルサーバー構成オプションを制御し、他のステートメントのデフォルト値を設定
server リモートネームサーバーに関連付ける指定された構成オプションを設定する。すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用
zone ゾーンを定義する。すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用

例 28-1 主サーバー用マスター構成ファイルの例


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;
         };
};

BIND 4.9.x から BIND 8.1.x への移行

スーパーユーザーになって、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 ファイルによって、ルートサーバー名が確立され、そのアドレスが列挙されます。ネットワークがインターネットに接続されているなら、named.ca には、インターネットのネームサーバーが表示されます。接続されていなければ、ローカルネットワークのルートドメインネームサーバーが表示されます。in.named デーモンは、サーバーの 1 つに接続できるまで、サーバーのリストを一巡します。そして、そのサーバーから現在のルートサーバーのリストを入手します。デーモンは、このリストを named.ca の更新のために用います。

hosts ファイル

hosts ファイルには、ローカルゾーン内のマシンに関するすべてのデータが含まれています。このファイル名は、ブートファイル内で指定します。/etc/hosts との混同を避けるために、hosts 以外の名前を付けます。たとえば、これらのファイルに db.domain パターンを使用して名前を付けることができます。この命名方法により、doc.com と sales.doc.com ドメインのホストファイルは db.doc と db.sales になります。

hosts.rev ファイル

hosts.rev ファイルで、逆 (アドレスから名前) マッピングを行うための特別な in-addr.arpa. ドメインのゾーンを指定します。このファイル名は、ブートファイル内で指定します。

named.local ファイル

named.local で、ローカルループバックインタフェースのアドレスまたはローカルホストをネットワークアドレス 127.0.0.1 とともに指定します。このファイル名はブートファイルで指定します。他のファイルと同様、このマニュアルで使われていない名前を付けることもできます。

$INCLUDE ファイル

インクルードファイルは、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 フィールドによって変化します。

name フィールド

最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。

ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが相対名に付加されます。

ttl フィールド

2 番目のフィールドは、オプションの有効期限フィールドです。このフィールドで、データを破棄する前にデータベース内にデータをキャッシュに保存しておく時間 (秒)、すなわちサーバーに新しい情報を次回リクエストするまでの時間を指定します。このフィールドを空白のままにすると、ttl には、Start-Of-Authority (SOA) リソースレコードで指定された最小時間がデフォルトとして用いられます。

ttl の設定値があまりにも小さいと、サーバーはデータ更新のためのリクエストを頻繁に繰り返します。逆に、ttl の設定値があまりにも大きいと、情報の変更がタイムリーに反映されなくなります。

ほとんどの場合、ttl の値は、初期値として 1 日 (86400) から 1 週間 (604800) の間に設定するとよいでしょう。実際の情報の変更の頻度にあわせて、ttl の値を適切な値に変更してください。また、ほとんど変化することがないデータと関連しているということで ttl の値を大きく設定していた場合、そのデータが変更されるとわかった時点で、ttl の値を、データの変更があるときまで小さな値 (3600 から 86400) にし、その後またもとの大きな値に戻すこともできます。

同じ名前、クラス、タイプを持つすべての RR では、ttl は同じ値に設定してください。

class フィールド

3 番目のフィールドは、レコードのクラスです。現在のところ、1 つのクラスだけがあります。それは、TCP/IP プロトコルのファミリーであることを示す IN です。

record-type フィールド

4 番目のフィールドでは、リソースレコードのタイプを記述します。RR にはたくさんのタイプがあります。最も一般的に使用されるタイプは、「リソースレコードのタイプ」で説明されています。

record-specific-data フィールド

record-specific-data フィールドの中身は、特定のリソースレコードのタイプで異なります。

ネームフィールドやデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。しかし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。

特殊なリソースレコード文字

次に挙げる文字には特別な意味があります。

表 28-4 特別な意味を持つリソースレコード文字

文字 

定義 

.

ネームフィールドで、1 つのドットだけが指定された場合は現在のドメインを指す 

@

ネームフィールドで、1 つの @だけが指定された場合は現在の起点を示す

..

2 つのドットがネームフィールドに指定された場合は null ドメイン名を表す 

¥X

X は数字以外 (0-9) の任意の文字で、¥ を付けることによって文字に特別な意味を持たせないようにする。たとえば、¥. を指定して、ラベル内にドット文字おくことができる

¥DDD

各 D は一桁の数字で、¥ を付けることによって DDD で表される 10 進数に対応する 8 進数を表現する。結果的に得られる 8 進数は、テキストとみなされ、そのテキストに特別な意味があるかどうかはチェックされない

()

データが 1 行に収まらないようなとき、データをグループ化するのにカッコを使用する。結果的に、カッコの間では行の終わりが認識されない 

;

セミコロンでコメントが開始する。その行でセミコロン以降は無視される 

*

アスタリスクはワイルドカードを表す 

ほとんどのリソースレコードには、現在の起点があり、名前の最後にドット (.) が付いていなければ、現在の起点が名前に追加されます。この機能は、マシン名などのデータに現在のドメイン名を追加する際には便利ですが、追加したくない場合には、問題を引き起こすかもしれません。データファイルを作成しているドメイン内に名前がない場合、ピリオドで終わる完全指定名を使してください。

制御エントリ

データファイルで制御エントリの行だけは標準 RR 書式に従わない行です。制御エントリには、$INCLUDE() と $ORIGIN()の 2 つのタイプがあります。

$INCLUDE

インクルード行は 1 列目から $INCLUDE で始まり、後にファイル名 ($INCLUDE ファイル) が続きます。次の例に示すように、この機能は異なるタイプのデータを複数のファイルに分けるのに特に便利です。


$INCLUDE /etc/named/data/mailboxes

この行は、/etc/named/data/mailboxes ファイルを読み込むリクエストとして解釈されます。$INCLUDE コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。このコマンドを使用しても、あるゾーンのデータを別々のファイルに入れるだけです。たとえば、mailbox のデータはこの機能を使ってホストデータとは別に保存されます。

$INCLUDE の文とファイルは必要に応じて必要な数だけ使用できます。

$ORIGIN()

$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 

メール交換 

SOA - 権限の開始

例 28-2 に SOA リソースレコードの構文を示します。

例 28-2 SOA レコードの書式


name class SOA origin person-in-charge ( serial number
		refresh
	retry
	expire
	ttl)

権限の開始 (SOA) レコードでゾーンの開始を指定します。次の SOA レコードでそのゾーンは終了します。次に SOA レコードのフィールドについて述べます。

name

ゾーン名を指定します。ゾーン名の後にはドットを付ける必要があります。たとえば、doc.com. は正しいですが、一方、doc.com は誤りです。

class

アドレスのクラスです。たとえば、IN は、インターネットを示し、最も一般的に用いられるクラスです。

SOA

リソースレコードのタイプを示します。

origin

データファイルがあるホスト名のフィールドです。ホスト名の後にはドットを付ける必要があります。たとえば、dnsmaster.doc.com. は正しいですが、dnsmaster.doc.com は誤りです。

person-in-charge

ネームサーバーの責任者のメールアドレスのフィールドです。たとえば、kjd.nismaster.doc.com. です。この名前も終わりにドットを付ける必要があります。

serial

データファイルのバージョン番号のフィールドです。データを変更するたびにこの番号を増やしてください。副サーバーは serial フィールドを使って、最後にマスターサーバーからデータファイルをコピーしたときから変更があったかどうかを検出します。

refresh

更新が必要かどうかを見るために副ネームサーバーがどのくらいの頻度で主ネームサーバーをチェックすべきかを秒で指定します。たとえば、7200 は、2 時間を意味します。

retry

リフレッシュのためのチェックに失敗した後、副サーバーがどのくらいの時間再試行するかを秒で指定します。

expire

リフレッシュが頻繁に行われない場合に、データの期限が切れる前に、副ネームサーバーがそのデータを使用する上限の時間を秒で指定します。

ttl

リソースレコードの time-to-live フィールドで使用されるデフォルトの秒数を指定します。このデフォルト値はリソースレコードで ttl が指定されていないときに適用されます。

SOA は各ゾーンに 1 つだけ指定してください。例 28-3 に SOA リソースレコードの例を示します。

例 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			 )

NS - ネームサーバー

例 28-4 に、ネームサーバー (NS) リソースレコードの構文を示します。

例 28-4 NS レコードフォーマット


domainname [optional TTL] class NS name-server-name

ネームサーバーレコードには、対象としているドメインを受け持つサーバーの名前を指定します。name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。もし、name フィールドが指定されない場合、そのデフォルトは最後に指定された名前になります。そのドメインの主マスターサーバーと副マスターサーバーのそれぞれに 1 つの NS レコードが必要です。例 28-5 に NS リソースレコードの例を示します。

例 28-5 NS リソースレコードの例


;domainname    [TTL] 	 class	NS	nameserver
doc.com        90000    IN	NS 	sirius.doc.com.

A アドレス

例 28-6 に、アドレス (A) リソースレコードの構文を示します。

例 28-6 アドレスレコードの書式


	
machinename	[optional TTL] class A	address

アドレス (A) レコードでは、対象としているマシンのアドレスを指定します。name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。各マシンのアドレスに 1 つの A レコードが必要です。ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む別々のエントリがネットワークインタフェースに必要です。

例 28-7 アドレスレコードの例


;machinename	[TTL]	class	A	address
sirius		IN		A	123.45.6.1

HINFO - ホスト情報

例 28-8 に、ホスト情報 (HINFO) リソースレコードの構文を示します。

例 28-8 HINFO レコードの書式


[optional name] [optional TTL] 	class	HINFO hardware	OS

ホスト情報 (HINFO) リソースレコードでは、ホスト固有のデータを指定します。ハードウェアとこのホストで動作しているオペレーティング環境を指定します。マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。name フィールドでは、ホスト名を指定します。名前が指定されなければ、in.named での最後のホストがデフォルトになります。各ホストに1 つの HINFO レコードが必要です。例 28-9 に HINFO リソースレコードの例を示します。

例 28-9 HINFO リソースレコードの例


;[name]   [TTL] class HINFO   hardware    OS
                IN    HINFO   Sparc-10    UNIX
注意 - 注意 -

HINFO フィールドにはネットワーク上のマシンについての情報があるので、多くのサイトで、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。

WKS - 既知サービス

例 28-10 に、既知サービス (WKS) リソースレコードの構文を示します。

例 28-10 WKS レコードの書式


[Optional name] [TTL] class WKS address protocol-list-of-services

既知サービス (WKS) レコードには、指定されたアドレスの特定のプロトコルでサポートされるよく知られたサービスが記述されます。サービスのリストとポート番号はサービスデータベースで指定されたサービスのリストから得られます。各プロトコルの各アドレスに 1 つの WKS レコードが必要です。例 28-11 に 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 レコードはオプションです。セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。

CNAME - 正規名

例 28-12 に、正規名 (CNAME) リソースレコードの構文を示します。

例 28-12 CNAME レコードの書式


 nickname [optional TTL] class CNAME	canonical-name

正規名 (CNAME) リソースレコードでは、正規名に対するニックネームまたは別名を指定します。ニックネームは一意である必要があります。他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。ニックネームの作成と他のリソースレコードでの使用はしないでください。ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。例 28-13 に CNAME リソースレコードの例を示します。

例 28-13 CNAME リソースレコードの例


;nickname      [TTL]	class	CNAME	canonical-name
mailhost		IN	CNAME antares.doc.com

PTR - ポインタレコード

例 28-14 に、ポインター (PTR) リソースレコードの構文を示します。

例 28-14 PTR レコードの書式


 special-name	[optional TTL]  class	 PTR-real-name

特別名でドメイン内の他の場所を指すことが、ポインタレコードによって可能になります。例では、PTR は、アドレス (特別名) の実名への変換のために、主に in-addr.arpa. レコードで使用されます。アドレスを解釈するときは、ドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。PTR の名前付けは、ゾーンに対して一意である必要があります。PTR レコードによって特別なドメインである in-addr.arpa.ドメインに対する逆ポインタが設定 (例 28-15) されます。

例 28-15 PTR リソースレコードのサンプル


;special name   [TTL]	class	PTR-real-name
1			IN	PTR sirius.doc.com.

MX - メール交換

例 28-16 に、メール交換 (MX) リソースレコードの構文を示します。

例 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 自体には一致しません。

例 28-17 MX リソースレコードの例


;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 DNS BIND の実装

Solaris リリース 8 では、コンパイル版の Berkeley Internet Name Domain (BIND) 8.1.2 を提供します。Solaris 8 リリースでは、コンパイル版の BIND を提供しています。このソフトウェアのコンパイル時には、たくさんのサイトでの様々なニーズに対応するためにオプションの設定や選択が行われました。しかし、もしこのコンパイル版の BIND がニーズに合わない場合、公に入手可能なソースコードを用いて、再コンパイルし、自分用のオリジナルのバージョンの BIND を作成することもできます。

Solaris 7 以降のリリースで提供される BIND バージョンのコンパイルでは、以下の選択が行われました。