名称

named − インターネットドメインネームサーバ

形式

named [ −d debuglevel ] [ −p port# ] [{−b} bootfile ]

解説

named は、インターネットドメインネームサーバです。 インターネットドメインネームシステムについては、RFC883 を参照して下さい。 引数が指定されない場合、 named はデフォルトの設定ファイル /etc/named.boot を読み、初期データを読み込んで問い合わせに備えます。

以下に示すオプションが使用できます。

−d デバッギング情報を表示します。 “d”のあとの数字で、表示されるメッセージのレベルを指定します。

−p 異なるポート番号を使用します。 デフォルトは、 /etc/service に指定されている標準ポート番号です。

残りの引数があった場合は、設定ファイルの名前として扱われます。 設定ファイルには、ネームサーバが初期データをどこから得るかについての 情報が納められています。 以下に簡単な例を示します。

 ;
;boot file for name server
;
directory/usr/local/domain
 ; typedomainsource host/filebackup file
 cache.root.cache
primaryBerkeley.EDUberkeley.edu.zone
primary32.128.IN-ADDR.ARPAucbhosts.rev
secondaryCC.Berkeley.EDU128.32.137.8 128.32.137.3cc.zone.bak
secondary6.32.128.IN-ADDR.ARPA128.32.137.8 128.32.137.3cc.rev.bak
primary0.0.127.IN-ADDR.ARPAlocalhost.rev
forwarders10.0.0.78 10.2.0.78
; slave
 

“directory”の行は、サーバのワーキングディレクトリを 指定されたディレクトリに移すことを指示します。 このことは、プライマリゾーンファイル中の $INCLUDE が正しく動作するために 重要です。 “cache”の行は、“root.cache”ファイルに納められたデータを バックアップキャッシュとして使用することを指示します。 これは主にルートドメインサーバの位置を納めるのに使用されます。 このキャッシュは通常の操作では使用されませんが、現在のルートサーバを 探すための「ヒント」として使われます。 “root.cache”ファイルのフォーマットは“berkeley.edu.zone” ファイルと同様です。 複数の“cache”ファイルを指定することもできます キャッシュファイルでは、データが書かれた時点からの time-to-live があるとして処理されます。 ルートネームサーバのデータに関しては、必要に応じて常に有効なままに 保たれます。 最初の“primary”行は、“Berkeley.EDU”ゾーンの正式なデータが “berkeley.edu.zone”ファイルに含まれていることを示します。 “berkeley.edu.zone”ファイルには、RFC833 に述べられている マスタファイルのフォーマットのデータが書かれています。 すべてのドメイン名はオリジンからの相対名になります。この場合のオリジンは “Berkeley.EDU”です(詳細は後述)。 2つめの“primary”行は、 “berkeley.edu.zone”ファイルに“32.128.IN-ADDR.ARPA”ゾーンの 正式なデータが含まれていることを示します。このゾーンは ネットワーク 128.32 のアドレスをホスト名に変換するために 使用されます。 各マスタファイルには、そのゾーンの SOA レコード(後述) が含まれていなければ なりません。 最初の“secondary”行は“CC.Berkeley.EDU”ゾーンの正式なデータは すべて 128.32.137.8 にあるネームサーバから転送されるべきであるということを 意味します。 もし転送に失敗した場合は、128.32.137.3 かその行に示された他のアドレス (最大10個まで)を使用します。 セカンダリのコピーもそのドメインの正式なデータとして扱われます。 最初に現れたアドレス(4つの数をドットでつなげたもの)以外のものを 転送されたゾーンのバックアップファイル名として使用します。 ネームサーバの起動時には、マスタサーバと通信できない時でも 完全なコピーが用意できるように、バックアップファイルがあればそこから ゾーンの情報を読み込みます。 自動的なゾーン転送によって、マスタサーバの一つから 新しいドメインのコピーを受け取ったときにはこのファイルも更新されます。 2つめの“secondary”行はサブネット 133.32.136 のアドレスからホスト名への 対応を示す情報が、“CC.Berkeley.EDU”と同じマスタサーバから 得られるということを意味しています。 “forwarders”行によって、他のサーバからの再帰的な問い合わせを受け付ける ような、サイト単位のサーバのアドレスを指定します。 設定ファイルに1つ以上のフォワーダが指定されていた場合には サーバはキャッシュ中に存在しない情報を、すべてフォワーダに問い合わせます。 応答が得られるか、リストの終りになるまで、順にフォワーダとして 問い合わせを行ないます。 もし、どのフォワーダからも有用な情報が得られなかった場合は “slave”モードでない限り forwarders 行がなかったものとして 動作を続けます。 このフォワーディング機構によって、マスタ上にサイト単位の巨大なキャッシュを 作成することによって、サイト外のサーバとの通信量を減らす効果があります。 また、直接インタネットにアクセスできないが、接続されているのと 同様に動作する必要のあるサーバにも有用です。 “slave”行(コメントアウトして示されている)は、サーバをスレーブモードに することを指示します。 このモードでは、サーバはすべての問い合わせをフォワーダに対して行ないます。 このオプションは通常、物理的あるいは管理上の理由で インタネットへのアクセスが制限されているホスト上で サーバを動作させるために使用されます。 “sortlist”行はリストされたネットワークが、他のネットワークよりも 好ましいということを意味します。 サーバが問い合わせを受けたネットワークと同一ネットワーク上のホストから、 ホストアドレスの問い合わせがあった場合は、 最初にローカルアドレスのアドレス、次にソートリスト中のアドレスを、 最後に他のアドレスを返します。 この行は、初期設定時にのみ動作し、 SIGHUP を用いてデータを再ロードした時には無視されます。

マスタファイル中には、制御情報とそのゾーンに含まれるリソースレコードの リストが以下の形式で書かれます。

 $INCLUDE <filename> <opt_domain>
$ORIGIN <domain>
<domain> <opt_ttl> <opt_class> <type> <resource_record_data>
 

domain には、ルートの場合は“.”、現在のオリジンは“@”、 それ以外は通常の名前を記述できます。 もし、 domain が“.”で終らない名前だった場合は、現在のオリジンが名前に付加されます。 “.”で終っている名前はそのまま使用されます。 opt_domain は、インクルードされるファイルのオリジンを定義するために使用します。 これは、インクルードされるファイルの1行目より前に $ORIGIN を 書いたのと同じ意味になります。このフィールドは省略可能です。 opt_domain フィールドも $ORIGIN もなかった場合は、インクルードされるファイルの オリジンは現在のファイルと同じになります。 opt_ttl フィールドには time-to-live として使用される整数を書くことができます。 省略された場合は 0 となり、そのゾーンの SOA レコード中の 最小 TTL の値が使用されます。 opt_class ではオブジェクトのアドレスの種類を記述します。 現在 DARPA Internet に接続されているものについては、 IN のみがサポートされています。 type フィールドには以下のいずれかを記述します。かっこの中に、 resource_record_data フィールドに予想されるデータの種類を示します。

A ホストアドレス (ドットで区切られた 4つの 10進数)

NS正式なネームサーバ (ドメイン)

MXメールエクスチェンジャ (ドメイン)

CNAME別名に対する正式名 (ドメイン)

SOA正式なゾーンの始まりを示す (プライマリサーバのあるホスト、 管理者のドメインアドレス、シリアル番号、 秒単位の 4 つの数字(更新間隔、リトライ間隔、有効期限、最小 TTL)、 詳細は RFC883 参照)

MBメールボックスのドメイン名 (ドメイン)

MGメールグループメンバ (ドメイン)

MRメールリネームドメイン名 (ドメイン)

NULLナルリソースレコード (フォーマット/データなし)

WKSよく知られたサービスの記述 (まだ実現されていない)

PTRドメイン名のポインタ (ドメイン)

HINFOホスト情報 (CPUの種類 OSの種類)

MINFOメールボックスまたはメールリスト情報 (リクエスト送付先 エラー送付先)

各リソースレコードは通常、改行で終りますが、開きかっこと閉じかっこの 間は複数の行に渡っても構いません。 セミコロンから行末まではコメントになります。

各マスタゾーンファイルは、そのゾーンの SOA レコードで始まらなければ なりません。SOA レコードの例を以下に示します。

@INSOAucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
2.89    ; serial
10800   ; refresh
3600    ; retry
3600000 ; expire
86400 ) ; minimum

SOA に含まれているシリアル番号は、マスタファイルを変更するたびに 更新しなければなりません。 セカンダリサーバは、更新間隔で示された秒数ごとにシリアル番号を調べ、 シリアル番号が変わっていたら、新しい情報を得るために ゾーンの転送が行なわれます。 更新の際にマスタサーバが応答しなかった場合は、 リトライ間隔で示された秒数ごとに成功するまで更新を試みます。 もし有効期限で示された間ずっと応答がなかった場合は、 セカンダリサーバでは、そのゾーンのすべてのデータを破棄します。 最小 TTL はファイル中で明示的に time-to-live を示していない すべてのレコードの time-to-live として使用されます。

注意事項

設定ファイル中の“domain”と“suffixes”の指定は、 ドメイン名の相対記述に関するリゾルバベースのより便利な 機能が実装されたため、もはや使われなくなりました。 以前の機構は、特にローカルサーバが完全な情報を 持っていない時に、うまくいかないことがありました。 次のシグナルを、 kill(1) を使用してサーバプロセスへ送った場合には、それぞれ以下に示した働きをします。

SIGHUP
サーバは named.boot を読み込んで、データベースの再ロードを行ないます。

SIGINT
現在のデータベースとキャッシュの内容を /usr/tmp/named_dump.db に 出力します。

SIGIOT
サーバが -DSTATS でコンパイルされていれば、統計情報を /usr/tmp/named.stats に出力します。

SIGSYS
サーバがプロファイルつきでコンパイルされていれば、 プロファイル情報を /usr/tmp に出力します(サーバはフォークして、 cd したあと終了します)。

SIGTERM
プライマリおよびセカンダリのデータベースファイルに出力します。 サーバがダイナミックアップデート許可でコンパイルされていた場合に、 変更されたデータをシャットダウン時に保存するために使用します。

SIGUSR1
デバッグモードにします。 SIGUSR1 を送るたびに、デバッグレベルが1ずつあげられます。 (SIGUSR1 のない古いシステムでは SIGEMT を使います)

SIGUSR2
デバッグモードを完全に抜けます。 (SIGUSR2 のない古いシステムでは SIGFPE を使います)

関連ファイル

/etc/named.bootネームサーバ設定ファイル
/etc/named.pidプロセスID
/usr/tmp/named.runデバッグ出力
/usr/tmp/named_dump.dbネームサーバデータベースのダンプ
/usr/tmp/named.statsネームサーバの統計情報

関連事項

kill(1), gethostbyname(3N), signal(3c), resolver(3), resolver(5), hostname(7), RFC882, RFC883, RFC973, RFC974, Name Server Operations Guide for BIND

NEWS-OSRelease 4.1C