Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all 
名前
dhcpd.conf - dhcpd の設定ファイル
説明
dhcpd.conf は、Internet Software Consortium DHCP サーバ dhcpd の設定情報が書かれたファイルです。
dhcpd.conf ファイルは自由形式の ASCII テキストファイルです。 dhcpd に組み込まれた再帰下降型のパーザによっ
て解釈されます。 このファイルには、整形の目的で余分なタブや改行を入れてもかまいません。 このファイルで
は、キーワードの大文字小文字は区別されません。 コメントはファイルのどこにでも入れられます (クォートの内部
を除く)。 コメントは # 文字で始まり、行末で終わります。
このファイルは基本的には文 (statement) のリストからなります。 文は大きく二つのカテゴリに分けられます。パ
ラメータ文と宣言文です。
パラメータ文は、 なにかをどの様に行うか (例えば提供するリースの長さ)、 なにかを行うかどうか (例えば素性の
わからないクライアントにもアドレスを与えるかどうか)、 クライアントにどの様なパラメータを与えるか (例えば
ゲートウェイとして 220.177.244.7)、 などを決めます。
宣言文は、 ネットワークのトポロジーを記述したり、 ネットワークのクライアントを記述したり、 クライアントに
割り当て可能なアドレスを決めたり、 ひとまとまりのパラメータを宣言文のグループに与えたりするために用いま
す。 パラメータ文や宣言文のグループにおいては、 ある宣言文が依存するパラメータ文は、 その宣言文よりも前に
指定しなければなりません。
ネットワークトポロジーに関する宣言には shared-network 文と subnet 文があります。 サブネットにあるクライア
ントがアドレスを動的に割り当ててもらう場合は、 subnet 宣言の内部に range 宣言文も必要になります。 静的に
アドレスが割り当てられたクライアントや、 素性のわかっているクライアントにのみアドレスを提供するような設定
では、 このようなクライアントに対して host 宣言文が必要です。 特にサブネットに関連付けられていない宣言グ
ループに 何らかのパラメータを与えたい場合は、 group 宣言文が使えます。
サービスを受けるサブネットや、dhcp サーバが接続するサブネットには、 すべて subnet 宣言が必要となりま
す。これによって dhcpd は、 あるアドレスがそのサブネットにあることを認識するのです。 subnet 宣言は、 その
サブネットに動的割り当てを受けるアドレスがなくても必要です。
場合によっては、一つの物理的なネットワークに上で 2 つ以上の IP サブネットが動作することがあります。 例え
ば、組織のルールで 8 ビットのサブネットマスクを使っているとしましょう。 このときある部門で、 一つの物理
イーサネットネットワークに接続するノードが 254 を越えてしまったら、 新しい物理ネットワークが追加できるま
では、 そのイーサネットで 8 ビットのサブネットを 2 つ走らせなければならないでしょう。 このような場合に
は、 これらの 2 つのネットワークに対する subnet 宣言は、 shared-network (共有ネットワーク) 宣言で囲うこと
ができます。
サイトによっては、 ある部門のクライアントが 2 つ以上のサブネットに接続されていることもあるでしょう。 この
ときこれらのクライアントに共通のパラメータを与え、 かつ同じサブネットにいる別の部門のクライアントには 違
うパラメータを与えたいとしましょう。 host 宣言によって明示的に宣言するクライアントでは、 これらを group
宣言によって囲って、 その部門に共通のパラメータを与えることができます。 アドレスが動的に割り当てられるク
ライアントでは、 今のところネットワークトポロジーによる他には、 グループ単位でのパラメータ割り当てを行う
方法はありません。
あるクライアントがブートする場合、 そのブートパラメータを決定するには、 まずそのクライアントの host 宣言
が (存在すれば) 参照されます。 次にその host 宣言を囲っている group 宣言が (存在すれば) 参照されます。 そ
の次にはブートするクライアントが所属するサブネットの subnet 宣言が参照され、 さらにそのサブネットを囲って
いる shared-network 宣言が (存在すれば) 参照されます。 最後に、すべての宣言の外部に置かれている、 トップ
レベルのパラメータが参照されます。
dhcpd がクライアントに対応する host 宣言を探すときには、 まずそのクライアントがブートしようとしているサブ
ネット (または共有ネットワーク) にマッチする fixed-address パラメータを含む host 宣言を探します。 そのよ
うなエントリがなければ、 fixed-address パラメータが含まれないエントリを探します。 そのようなエントリもな
ければ、 たとえそのクライアントのエントリが別のサブネットや共有ネットワークにあっても、 dhcpd はそのクラ
イアントのエントリが dhcpd.conf ファイルには存在しないかのように動作します。
例
よくある dhcpd.conf ファイルの例を示します:
global parameters...
shared-network ISC-BIGGIE {
shared-network-specific parameters...
subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
}
}
subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}
group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
}
Figure 1
ファイルの先頭にはグローバルなパラメータのための 場所があることにお気づきになったかと思います。 ここでは
組織のドメイン名、ネームサーバのアドレス (組織全体に共通のものがあれば) などを指定します。 従って、例えば
次のようになるでしょう。
option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;
Figure 2
Figure 2 にあるとおり、パラメータに与えるホストのアドレスは、 数値形式の IP アドレスではなくドメイン名で
与えてもかまいません。 与えられたホスト名が 1 つ以上の IP アドレスに解決される (例えばホストがイーサネッ
トインターフェースを 2 つ持っているなど) 場合には、クライアントにはすべてのアドレスが渡されます。
Figure 1 からわかるとおり、shared-network 文も subnet 文もパラメータを取ることができます。 ここで共有ネッ
トワーク ISC-BIGGIE は部門 (例えば経理部門) 全体をサポートしているとしましょう。 経理部門には自前のドメイ
ンがあるとすると、 shared-network 専用のパラメータとして以下を与えるべきでしょう。
option domain-name "accounting.isc.org";
すると shared-network 宣言の内部にある subnet 宣言では、 domain-name オプションは単なる "isc.org" ではな
く "accounting.isc.org" になります。
Figure 1 のように subnet に固有のパラメータを与えたいのは、 当然ながら、サブネットはそれぞれ違ったルータ
を必要とするからです。 したがって最初のサブネットには、 例えば以下のような文が置かれることになるでしょ
う。
option routers 204.254.239.1;
ここではアドレスは数値で指定されています。 これは必須ではありません。 もしルータの各インターフェースが
別々のドメイン名を持っているなら、 そのインターフェースの指定には、数値でなくドメイン名を用いても全くかま
いません。 しかしながら、多くの場合ルータの IP アドレスそれぞれには 一つの同じドメイン名がつけられている
でしょうから、 ここでその名前を用いるのは適切ではないでしょう。
Figure 1 では、group 文も使われており、 3 つのホスト (zappo, beppo, harpo) に共通のパラメータをあたえてい
ます。 おわかりのように、これらのホストはすべて test.isc.org ドメインに属しています。 したがってこれらの
ホストには、 グループ固有のパラメータとしてドメイン名を上書きするかたちで 与えるのが良いでしょう。
option domain-name "test.isc.org";
また、所属するドメイン名から想像できるように、 これらはおそらくテスト用のマシンでしょう。 DHCP 貸し出し機
構をテストする場合には、 貸し出しの期限をデフォルトよりは少々短くしておくのが良いでしょう。
max-lease-time 120;
default-lease-time 120;
これまでのところで、option キーワードによって始まるパラメータと、 そうでないパラメータとがあることにお気
づきになったでしょうか。 option キーワードで始まるパラメータは、 実際の DHCP オプションに関連したもので
す。 そうでないものは、 DHCP サーバの動作を制御するもの (例えば dhcpd が提供する貸し出しの期限など) か、
DHCP プロトコルでは提供されていないクライアント用のパラメータ (例えばサーバ名やファイル名) です。
Figure 1 では、各ホストは「ホスト固有のパラメータ」を持っていました。 これらには例えば、hostname オプショ
ン、 取得するするファイル (filename パラメータ)、 ファイルを取得するホスト (next-server パラメータ) など
が含まれます。 一般的には、パラメータを指定できる場所にはどんなパラメータでも指定でき、 そのパラメータは
置かれた場所のスコープにしたがって適用されます。
NCD の X 端末がたくさんあるようなサイトを想像してください。 これらの端末にはさまざまなモデルがあるので、
それぞれのモデルに対して別々のブートファイルを指定したいとします。 これを行う一つの方法は、 各端末に host
宣言をさせ、それらをモデルごとに group 化することです。
group {
filename "Xncd19r";
next-server ncd-booter;
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}
group {
filename "Xncd19c";
next-server ncd-booter;
host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}
group {
filename "XncdHMX";
next-server ncd-booter;
host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}
リファレンス: 宣言文
shared-network 文
shared-network name {
[ parameters ]
[ declarations ]
}
shared-network 文は、複数の IP サブネットが実際には 一つの物理ネットワークを共有していることを DHCP サー
バに伝えるために用います。 共有ネットワーク内にあるサブネットは、 shared-network 文の内部で宣言するように
すべきです。 shared-network 文の内部で指定されたパラメータは、 それらのサブネットでブートしたクライアント
によって用いられます (ただしそのパラメータがサブネットやホストレベルで上書きされた場合を除く)。 共有ネッ
トワークに属するサブネットに動的割り当て可能なアドレスがあると、 これらのアドレスは共有ネットワーク用の場
所に共通にプールされ、 必要に応じてクライアントに提供されます。 あるクライアントが、(共有ネットワークに属
する) どのサブネットからブートさせるべきかを識別する方法はありません。
name には共通ネットワークの名前を指定しておきましょう。 この名前はデバッグメッセージの出力時に用いられる
ので、 その共通ネットワークの認識に役立ちます。 名前にはドメイン名として有効な書式 (ただしドメイン名とし
ては用いられない) が使えます。 あるいはクォートすればどんな名前でも使えます。
subnet 文
subnet subnet-number netmask netmask {
[ parameters ]
[ declarations ]
}
subnet 文は、 ある IP アドレスが特定のサブネットに属しているかどうか判断するための情報を dhcpd に与えるた
めに用います。 またサブネット固有のパラメータを指定したり、 そのサブネットでブートしたクライアントに 動的
割り当て可能なアドレスを指定するためにも利用されます。 後者のようなアドレスは range 宣言で指定されます。
subnet-number には IP アドレスか、 あるいは宣言するサブネットの IP 番号に解決されるドメイン名を与えます。
netmask には IP アドレスか、 あるいは宣言するサブネットのサブネットマスクに解決されるドメイン名を与えま
す。 サブネット番号とネットマスクとを与えると、 ある与えられた IP 番号が そのサブネットに属しているかどう
かを判断できるようになります。
ネットマスクはすべての subnet 宣言に必要ですが、 あるサイトの内部で用いているサブネットマスクに複数の種類
がある場合は、 subnet-mask オプション文を各 subnet 宣言の内部で用いて、 適切なサブネットマスクを設定する
こともしておくべきです。 なぜかというと、subnet-mask オプション文は、 subnet 文で宣言されたサブネットマス
クより優先されるからです。
range 文
range [ dynamic-bootp ] low-address [ high-address];
動的に割り当てられるアドレスを含むサブネットでは、 少なくとも range 文を一つ指定しなければなりません。
range 文には IP アドレスの範囲の最小値・最大値を与えます。 その範囲に入る IP アドレスのすべては、 range
文が宣言されたサブネットの中に入っている必要があります。 指定した範囲のアドレスを DHCP クライアントと
BOOTP クライアントの両方に割り当てて良い場合は、 dynamic-bootp フラグを指定します。 アドレス 1 つだけを割
り当てる場合は、 high-address は省略できます。
host 文
host hostname {
[ parameters ]
[ declarations ]
}
サービス対象となる BOOTP クライアントには、それぞれ host が最低ひとつづつ必要になります。 DHCP クライアン
トに対しても host 文は指定できますが、 素性のわからないホストにはブートを許可しないような設定でなければ、
指定しなくてもかまいません。
ある DHCP クライアントや BOOTP クライアントを、 複数のサブネットにおいて固定アドレスでブートさせたい場合
には、 fixed-address パラメータに複数のアドレスを指定するか、 あるいは host 文を複数指定します。
クライアント固有のブートパラメータを、 接続されたネットワークによって代えなければならない場合には、 host
文を複数用いるべきです。
可能な場合にはクライアントを固定アドレスでブートさせたいが、 それができなければ動的なアドレスを割り当てた
い、という場合には、 host 文の内部では fixed-address 文を指定しないようにします。
host 宣言を実際の DHCP クライアントや BOOTP クライアントにマッチさせる際には、 host 宣言の内部で指定され
た dhcp-client-identifier オプションが、 クライアントが渡してきた識別子とマッチするかを確認します。 もし
host 宣言の内部に dhcp-client-identifier がなかったり、 クライアントがこの識別子を渡してこなかった場合に
は、 host 宣言の内部で指定された hardware パラメータが、 クライアントが渡してきたハードウェアアドレスと
マッチするかを確認します。 BOOTP クライアントは通常 dhcp-client-identifier を渡さないので、 BOOTP プロト
コルでブートさせるクライアントに対しては、 必ずハードウェアアドレスを用いなければなりません。
group 文
group {
[ parameters ]
[ declarations ]
}
group 文は、なんらかのパラメータを宣言のグループに適用するために用います。 ホスト、共有ネットワーク、サブ
ネット等をまとめたり、 あるいは他のグループをまとめることもできます。
リファレンス: ALLOW と DENY
allow 文と deny 文を使うと、 いろいろな要求に対する dhcpd の振る舞いを制御できます。
unknown-clients キーワード
allow unknown-clients;
deny unknown-clients;
素性のわからない (unkown な) クライアントに動的にアドレスを割り当てるかどうかを dhcpd に指示します。 デ
フォルトでは unkown なクライアントへの動的アドレス割り当ては allow (許可) されています。
bootp キーワード
allow bootp;
deny bootp;
bootp フラグは、 bootp クエリ (問い合わせ) に答えるかどうかを dhcpd に指示します。 デフォルトでは bootp
クエリは allow (許可) されています。
booting キーワード
allow booting;
deny booting;
booting フラグは、 特定のクライアントからのクエリに答えるかどうかを dhcpd に指示します。 このキーワード
は、host 宣言の内部に置かれた場合にのみ意味を持ちます。 デフォルトでは booting は allow (許可) されていま
す。 しかしこれを特定のクライアントに対して無効にすると、 そのクライアントはこの DHCP サーバからはアドレ
スを取得できなくなります。
リファレンス: パラメータ
default-lease-time 文
default-lease-time time;
time は秒単位の時間で、 貸し出しを要求しているクライアントが特に期限を求めなければ、 この時間が貸し出し時
間になります。
max-lease-time 文
max-lease-time time;
time は秒単位の時間で、 貸し出しを要求しているクライアントが期限を求めた場合に、 割り当て可能な最大の貸出
時間です。
hardware 文
hardware hardware-type hardware-address;
BOOTP クライアントが認識されるためには、 host 文の内部で hardware 指定によってそのネットワークハードウェ
アアドレスが 指定されていなければなりません。 hardware-type は物理ハードウェアインターフェースの形式名で
す。 現在のところは ethernet と token-ring だけが認識されます (fddi などのハードウェア型も認識されると良
いのでしょうが)。 hardware-address は 16 進オクテット (0 から ff までの数値) のセットで、 区切りはコロン
です。 hardware 文は DHCP クライアントにも用いることができます。
filename 文
filename "filename";
filename 文はクライアントにロードさせる初期ブートファイルの指定に使います。 filename はクライアントが使う
であろうファイル転送プロトコルで 認識されるファイル名でなければなりません。
server-name 文
server-name "name";
server-name 文はクライアントに接続中のサーバの名前を伝えるために用います。 name はクライアントに渡される
名前です。
next-server 文
next-server server-name;
next-server 文は初期ブートファイル (filename 文で指定したもの) をロードするサーバのホストアドレスを指定す
るために使います。 server-name は数値の IP アドレスかドメイン名です。 接続してきたクライアントに対して与
えるべき next-server パラメータがなければ、DHCP サーバの IP アドレスが用いられます。
fixed-address 文
fixed-address address [, address ... ];
fixed-address 文は、あるクライアントに対して一つまたは複数の IP アドレスを割り当てるために用います。 host
宣言の内部でのみ用いられます。 複数のアドレスが指定された場合には、 そのクライアントがブートするネット
ワークに所属するアドレスが割り当てられます。 クライアントがブートするネットワークに属するアドレスが
fixed-address 文にない場合は、そのクライアントはその fixed-address 文が含まれる host 宣言にマッチしないこ
とになります。各 address は IP アドレスか、 一つ (または複数) の IP アドレスに解決されるドメイン名です。
dynamic-bootp-lease-cutoff 文
dynamic-bootp-lease-cutoff date;
dynamic-bootp-lease-cutoff 文は、動的に割り当てた BOOTP クライアントへのすべての貸し出しを終了させる時刻
を設定します。 BOOTP クライアントは貸し出しを更新する機構を持たず、 また貸し出しがいつ期限切れになるかを
知らないので、 デフォルトでは dhcpd は BOOTP クライアントへは無期限の貸し出しを行います。 しかし、ある場
合には BOOTP の貸し出し停止に意味があるかもしれません。 例えば学期の最後や、夜中のある時間になると施設が
閉まって、 すべてのマシンが電源停止になるような場合などです。
date は割り当てられた BOOTP 貸し出しのすべてが終了する時刻です。 date は以下の書式で指定します。
W YYYY/MM/DD HH:MM:SS
W は曜日を数値で指定したもので、0 (日曜日) から 6 (土曜日) までです。 YYYY は年で、世紀の桁も指定します。
MM は月を数値で指定したもので、 1 から 12 マデです。 DD は月内日を数値で指定したもので、 1 から数えます。
HH は時間で、0 から 23 までです。 次の MM は分で、SS は秒です。 時刻は常に協定世界時 (UTC) で指定します
(地方時ではありません)。
dynamic-bootp-lease-length 文
dynamic-bootp-lease-length length;
dynamic-bootp-lease-length 文は BOOTP クライアントへの動的割り当ての貸し出し期間の設定に用います。 サイト
によっては、一度アドレスを貸し出したクライアントから 一定の間 BOOTP や DHCP での再割り当て要求がなけれ
ば、 そのアドレスはもう使われない、とみなすことが可能かもしれません。 貸出機関は length に秒単位で指定し
ます。 その期間のうちにクライアントが BOOTP を用いて再ブートすると、 貸し出し期間も length にリセットされ
ます。 したがって頻繁にブートする BOOTP クライアントは、 割り当てられたアドレスをずっと保持し続けます。
言うまでもありませんが、このパラメータは細心の注意を払って決めてください。
get-lease-hostnames 文
get-lease-hostnames flag;
get-lease-hostnames 文は、貸し出し用にプールされている IP アドレスのドメイン名を引き、 そのアドレスを
DHCP hostname オプションに用いるかどうかを dhcpd に伝えるために用います。 flag が真ならば、現在のスコープ
にあるすべてのアドレスに対して この名前引きが実行されます。 デフォルトでは flag は偽で、名前引きは行われ
ません。
use-host-decl-names 文
use-host-decl-names flag;
use-host-decl-names パラメータがその置かれたスコープで真 (true) だと、 そのスコープに置かれたすべての
host 宣言において、 宣言に使われた名前がホスト名としてクライアントに渡されます。 したがって例えば、
group {
use-host-decl-names on;
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}
は次と全く同じになります。
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name "joe";
}
host 宣言の内部に置かれた option host-name 文は、宣言に用いられた名前よりも優先されます。
authoritative 文
authoritative;
not authoritative;
通常 DHCP サーバは、あるネットワークセグメントの設定情報は 正しくかつ信頼できるとみなしています。 よって
クライアントがあるネットワークセグメントの IP アドレスを要求したとき、 サーバがそれがそのセグメントでは正
しくないことを知っていると、 サーバは DHCPNAK メッセージを返します。 するとクライアントはその IP アドレス
を忘れ、 新しいアドレスを取得しようとします。
DHCP サーバがネットワーク管理者ではない人間によって設定され、 よってこのレベルの権威を持たせたくない場合
には、 設定ファイルの適切なスコープに "not authoritative" という文を入れておくと良いでしょう。
通常は、 not authoritative をファイルのトップレベルに書いておけば十分です。 しかし、あるネットワークに対
しては権威を持たせ、 別のネットワークに対しては持たせないように DHCP サーバを設定したい場合には、 ネット
ワークセグメント単位で authority を宣言するほうが良いでしょう。
authority が意味を持つスコープは、物理ネットワークセグメントの単位です。 すなわち shared-network 文か、
shared-network 文の内部にはない subnet 文です。 共有ネットワークに属しているサブネットの一部のみに対して
サーバに権威を持たせても意味はありません。 また一部の host 宣言に対してのみサーバに権威を持たせても、 同
じく意味はありません。
use-lease-addr-for-default-route 文
use-lease-addr-for-default-route flag;
use-lease-addr-for-default-route パラメータがその置かれたスコープで真だと、 routers オプションで指定した
値を送る (あるいは値を全く送らない) 代わりに、割り当てようとしている IP アドレスをクライアントに送りま
す。 こうすると Win95 マシンはすべての IP アドレスを ARP するようになり、 使っているルータが proxy ARP に
設定されている場合には役に立ちます。
use-lease-addr-for-default-route が有効になっていて、 option routes 文も同じスコープにある場合には、
routes オプションが優先されます。 この理由は、この機能を使いたい局面では、 たくさんある Windows 95 マシン
すべてにはこの機能を有効にし、 その他数台のマシンではこれを無効にしたくなるだろうからです。 不幸にして状
況が逆の場合は、 このフラグは用いないほうがたぶん良いでしょう。
always-reply-rfc1048 文
always-reply-rfc1048 flag;
BOOTP クライアントの中には、受信には RFC1048 形式のものを期待するのに、 送信では RFC1048 を守らないものが
あります。 あるクライアントがこの問題を抱えている場合には、 そのクライアントは設定したオプションを取得せ
ず、 また BOOTREQUEST するたびに サーバのログに "(non-rfc1048)" というメッセージが現れます。
このようなクライアントに rfc1048 オプションを送信したい場合は、 そのクライアントの host 宣言に always-
reply-rfc1048 を設定します。すると DHCP サーバは RFC-1048 形式のベンダーオプションフィールドを用いて応答
します。 このフラグはどのスコープにも設定でき、 そのスコープでカバーされるすべてのクライアントに適用され
ます。
server-identifier 文
server-identifier hostname;
server-identifier 文は、それが置かれたスコープ内において、 DHCP サーバ識別子オプションで送られる値を定義
するために用います。 指定する値は DHCP サーバの IP アドレスでなければならず、 そのスコープにおいてサービ
スを受けるすべてのクライアントから 到達可能でなければなりません。
server-identifier 文の使用は勧められません。 唯一の利用局面は、デフォルトで送られる値が間違っている場合
に、 その値を別のものに変更する場合だけです。 デフォルトの値は、要求が到達した物理ネットワークインター
フェースに 関連付けられた最初の IP アドレスです。
server-identifier 文が必要になるのは、物理インターフェースに複数の IP アドレスがついていて、 デフォルトで
送られるアドレスが、 サービスを受ける一部または全部のクライアントにとって適切ではない場合です。 他にあり
得る例としては、 DHCP サーバの IP アドレスを一貫させるために IP エイリアスが定義されており、 クライアント
がサーバいん接続する際にはこの IP アドレスを用いるのが望ましい場合があります。
リファレンス: オプション文
DHCP オプション文はマニュアルページ dhcp-options(5) で説明されています。
関連項目
dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
著者
dhcpd(8) は Ted Lemon <mellon@vix.com> が Vixie Labs との契約のもとに書きました。 このプロジェクトの資金
は、 Internet Software Corporation によって提供されました。 Internet Software Consortium の情報は
http://www.isc.org/isc にあります。
dhcpd.conf(5)