DOKK / manpages / debian 10 / manpages-ja / dhcpd.conf.5.ja
dhcpd.conf(5) File Formats Manual dhcpd.conf(5)

名前

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 は物理ハードウェアインターフェースの形式名です。 現在のところは ethernettoken-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 にあります。