DHCPD.CONF中文翻译

[jacky]

DHCPD.CONF中文翻译
2008-03-11 admin 点击: 1296

DHCPD.CONF中文翻译
http://blog.chinaunix.net/u1/39411/showart_321308.html 中文翻译 liufirst


名称

dhcpd.conf - dhcpd 配置文件



描述

dhcpd.conf 文件包括ISC DHCP的dhcpd的配置信息。

dhcpd.conf文件是一个普通格式的ASCII码文档， 它由内置的递归解析器解释。

dhcpd. 文件可能会包含许多额外的tab和空格、空行，它们的目的是让文件更容易阅读。 其中的关键字对大小写不敏感。注释语句可以放在任何位置（除了引号中）注释语句用# 开头，这一行结束时注释语句自然结束。



文件包括一组语句，语句在一对大括号中，包含参数和声明。



参数语句说明如何做一件事（例如，租期是多长时间），或者是否做一件事情。 (例如， dhcpd 是否为未知客户提供地址)，或者给客户提供哪种参数(例如，使用网关220.177.244.7)。

声明用来描述网络的拓扑结构、网络上的客户，提供可以为客户端分配的地址，或者对某个客户端组应用组（group）参数。在任何组参数中，所有的这些组参数必须比使用这些组参数的语句先出现。

网络声明包含多子网的网络（有些地方译为：超网，但超网太难理解了，这里叫“多子网网络”）和子网的拓扑声明。对于子网的客户端被动态分配地址，子网声明中必须有一个range声明语句。对于静态分配的地址，或者是已知客户的安装，每个客户端都必须使用一个host声明语句。如果一个参数应用到一组声明中，这些声明并不只与某个子网相关，可以定义一个“组参数”。

对每一个要服务的子网，每个dhcp服务器连接的子网，都必须有一个子网声明，用来告诉dhcpd如何处理那个子网上的地址。即使一个子网不需要分配任何地址，也需要一个子网声明。

一些物理网络上不只有一个IP子网存在，例如，如果一个网络需要一个8位的子网，但是当业务发展使总的节点数超过了254台，就需要增加一个8位的子网。这时，就增加了一个新的物理网络，这种情况下，2个网络的子网声明必须包含在一个“多子网网络声明（超级作用域）”中。

有些网络的客户端不只有一个子网，可能会为同一子网中一些客户端分配的一些参数与其它的客户端不同。这样的用户可以使用host语句来定义，一些参数也可以定义在“组参数”语句中，它被这些客户端共同调用。对于需要根据不同情况获得不同地址的客户端，可能会使用“类声明（class declarations）”和“条件声明（conditional declarations）”语句，这样可以根据客户端发送的信息来决定分配给客户端的参数。

当一个客户端启动时，服务器先查看是否有匹配客户端的host语句，如果没有，再看是否有匹配的“类声明（class declarations）”语句，接着查看是否有“池pool”匹配，“子网subnet”匹配和“多子网网络（超级作用域）shared-net-work”匹配。（根据这些匹配，）将符合这个客户端的参数提供给它。每种参数都不会被分析第2次，如果它们出现了2次或2次以上，那么会使用那个最精确出现的地方。

dhcpd首先查找客户端是否有包含固定IP地址的host语句，这个地址要在客户端启动的那个子网中，或者“多子网网络”中，如果没有对应的host语句匹配，那就查找非固定地址的声明。



例如：

一个典型的dhcpd.conf 文件将会象下面这样：



global 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...

}

}



图 1



注意文件的开始，它是全局参数放置的地方，可能会是：

组织的域名，DNS服务器的地址（如果这个服务器对整个网络都是一样的）和其它一些。比如：



option domain-name "isc.org";

option domain-name-servers ns1.isc.org, ns2.isc.org;



图 2



如图2中所示，可以使用DNS服务器的名称而不使用它的IP地址，如果指定不只一个DNS服务器地址，那么只要有可能，所有地址都会提供给客户端。

每个子网都要指明的最可能必须的参数是router，如图1所示。因此对于第一个子网，它就应该是这个样子的

option routers 204.254.239.1;

注意这里的地址是数字形式的，如果每个网关都有域名，这就不是必须的，使用域名也是合法的。然而，很多情况下，多个网关只有一个域名，这样就不能使用域名了。

在图1中，有一个group 语句，它为一组host语句zappo，beppo和harpo提供了通用的参数。如你所见，这些主机都在test.isc.org这个域里，这样它在“组参数”中指明就会覆盖全局设置的参数：



option domain-name "test.isc.org";



而且，指明它们的域，可能用在测试机器中，如果我们要测试DHCP的租约机制，可以在这里设置比默认值更短的租约：



max-lease-time 120;

default-lease-time 120;



你可能注意到有些参数以option 关键字开头，有些不。以option 关键字开头的语句对应实际的DHCP选项，不以option关键字开头的选项控制服务端(例如，租期) 或客户端的选项不在DHCP协议中（例如，服务器名或文件名）

在图1中，每个host 都有指定的参数，它会包含象hostname选项，要上传的文件名(filename 参数)，还有要上传的服务器的地址(next-server 参数)。通常，任何参数都可以在任何可以出现的地方出现，并且按照参数出现位置确定应用范围。

假设你的环境中有许多没有CD的X终端，这些终端有不同的型号，你想为每种型号确定一个启动文件，一种方法是给每个服务器和组都使用host语句：



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

}



地址池

“池”语句(pool)用来定义一个地址池，即便是在同一个网段或者子网，也可以定义几个池，系统将通过“池”来区分它们。例如，你可能想提供一大段地址分配给DHCP客户端时同时提供很短的租约的一小段地址，用来给未知客户。如果有防火墙，你可能会安排一段地址池能上网，另一个地址池不能上网，这可以鼓励用户注册到DHCP系统中来，也就需要建立两个地址池：



subnet 10.0.0.0 netmask 255.255.255.0 {

option routers 10.0.0.254;



# Unknown clients get this pool.

pool {

option domain-name-servers bogus.example.com;

max-lease-time 300;

range 10.0.0.200 10.0.0.253;

allow unknown-clients;

}



# Known clients get this pool.

pool {

option domain-name-servers ns1.example.com, ns2.example.com;

max-lease-time 28800;

range 10.0.0.5 10.0.0.199;

deny unknown-clients;

}

}



上面这个例子中，已知客户和未知客户在相同的子网中，也可能将已知和未知客户分配在不同的子网中，或者在“多子网层次（超级作用域）”，这样地址池的范围可能跨越不同的子网。正如前面的例子，地址池可以允许或拒绝一个控制用户存取的组，这个组名前面要有allow或 deny 关键字。

如果一个池有一个允许列表，只有匹配的客户端才可以获得地址池的地址，如果这个池有一个拒绝列表，只有不匹配的客户端才可以获得池中的地址，如果同时存在允许和拒绝列表，那么只有在允许列表并且不在拒绝列表中的客户端才可以获得池中的地址。



动态地址分配

地址分配实际只在客户端在初始状态并且发送一个 DHCPDISCOVER信息时完成。如果客户端认为它有一个有效的租约并且发送了一个DHCPREQUEST信息来初始化或者更新租约，服务器就只有3个选择：（1）它可以忽略DHCPREQUEST信息，并且返回一个DHCPNAK 信息来告诉客户端，要求客户端停止使用这个地址，（2）或者发送一个DHCPACK信息，告诉客户端继续再使用这个地址一段时间，如果服务器找到客户端要求的地址，并且这个地址对于这个客户也是可用的，服务器会发送一个DHCPACK信息，如果这个地址已经不能用了，客户端就不能使用它，此时服务器将会发送一个DHCPNAK信息，（3）如果服务器不知道这个地址，它会先保持沉默，除非这个地址对于客户端依附的地址段是不正确的，这种情况下服务器会发送一个DHCPNAK，即便它完全不知道这个地址。

如果有一个host语句定义了客户端，同时host语句中包含了固定地址（fixed-address），这个IP地址对于客户端实际连接的网段也是合法的，此时DHCP服务器不动态分配地址，而是发送host语句指明的地址。如果此时用户发送了DHCPREQUEST信息来获得其它地址，服务器会回应一个DHCPNAK信息，来拒绝为用户分配其它地址。

当一个DHCP服务器为客户端分配一个新的地址时(记住，这只发生在客户端发送DHCPDISCOVER信息时)，它首先查找lease文件，看客户机是否存在一个有效的地址租约，或者此客户机原来是否有一个地址（这个地址已经过期），如果有，服务器就会检查那个地址，看客户端是否被允许使用这个地址，如果客户端已经不被允许使用这个地址（通常是客户机从另外一个子网登录了，或者此地址被其它客户端占用），并且服务器lease文件中显示原来的租约还存在，服务器就释放这个租约，事实上，此时是客户端发送的DHCPDISCOVER信息，它已经证明客户端实际并没有使用这个租约。如果没有找到存在的租约，或者客户端被强迫接收一个已经存在的租约，那么服务器就会查找客户端所在网段的地址池，找一个允许客户端使用而又没有使用的地址，它会按顺序遍历每个地址池(所有地址池外的“范围”range定义语句都组成一个没有允许列表的单独的池)。如果地址池的允许列表允许客户端得到一个池中的地址，这个地址池会被检查是否有可用的地址，如果有，客户端将会得到这个地址；否则，会检查下一个地址池。如果一直都没有找到可用的地址，服务器就不发送回应。如果找到一个地址，这个地址以前从未被任何客户端使用过，这个地址将立即分配给这个客户，如果这个地址曾经分配给另一个客户端，服务器会尝试查找一个从未分配的地址给客户端。

DHCP服务器使用哈希表(hash table)来产生一组可用的IP地址，这意味着地址不以任何特定的顺序存放，这样也就不能预测DHCP服务器下一个要分配的地址。前一个版本的ISC DHCP服务器使用降序来分配地址，现在不是了，并且在这个版本里也没有办法配置服务器分发地址的顺序 (ISC DHCP 3)。



防止IP地址冲突

DHCP服务器在分配IP地址前检查它们是否被使用来防止冲突。它通过向准备分配的IP地址发送ICMP Echo 请求信息来完成，如果1秒内没有接收到ICMP Echo reply信息，就假定这个地址是可用的。这只对在range语句中指明的租约，并且租约被DHCP服务器认为可用时有效。例如，DHCP服务器或者它的热备机没有列出这个租约在使用中。如果收到ICMP Echo回应，DHCP服务器会假定出现了配置错误――IP地址被网络上的主机使用了，然后它标记这个地址为“废弃地址”，不再把它分配给客户端。如果DHCP客户端试图得到一个地址，但是却没有可用的地址，服务器会（随机）标记一个“废弃地址”为“可用”，然后向这个地址发送同样的ICMP Echo 请求，如果没有得到 ICMP Echo reply回应，这个地址就会分配给这个客户。

如果要收回的第一个IP地址是可用的，DHCP服务器不会去循环使用“废弃地址”。而且，当下一个客户的DHCPDISCOVER信息到达时，它会用相同的方法开始一个新的分配，并且尝试分配一个新的IP地址。

DHCP 失败恢复（热备机）

这个版本的ISC DHCP服务器支持DHCP失败恢复协议，它在draft-ietf-dhc-failover-07.txt中描述，这不是最终的协议文档，而且没有与其它产品进行交互兼容性操作，这样，你就不能假定产品适合标准。如果你想使用这个失败恢复协议，一定要确定失败恢复的每台机器都运行相同版本的ISC DHCP服务器。

失败恢复协议允许两台DHCP 服务器 (并且不超过2台)共享一个通用的地址池，在任何指定的时间上每台服务器都有池中一半的可分配地址，如果一台服务器失效了，另一台服务器一旦查觉到两台服务器间的通讯丢失，它将会继续更新不在自己范围地址的租约，并且分配不属于自己地址范围的地址。在一台服务器较长时间失效后，另一台有效的服务器将会要求分配另一台服务器管理的地址，并开始使用这些地址。这种状态是将服务器置于PARTNER-DOWN（伙伴机失效）状态。

可以使用命令omshell (1)把服务器设置成PARTNER-DOWN状态。或者设置成失效状态，在租约文件中编辑最后服务器（peer）状态，然后重启服务器，如果用这种方法，一定要确定开始状态的日期和时间留空。



failover peer name state {

my state partner-down;

peer state state at date;

}



当失效的服务器启动完成并在线工作时，它应当自动侦测到它曾经掉线并且会请求设置为PARTNER-DOWN 状态的服务器传送完整的更新数据，然后两台服务器就又恢复到共同处理数据的状态。

有可能进入到一个危险的失败状态：如果你把一台服务器A设置成PARTNER-DOWN状态，接着，另一台服务器B关机，当另一台服务器B恢复时，B不知道A处于PARTNER-DOWN状态，此时B会分配地址，这些地址中部分是A正在分配的，也就是说，一个地址可能分配给了两台不同的客户端，这就造成了IP地址冲突。因此，把一台服务器设置成PARTNER-DOWN 状态，一定确定另一台服务器不是自动重启的。

失败恢复协议定义了主服务器角色和次服务器角色，两着工作有一些不同，大部分区别在与对方通讯的方法上。这样，一台服务器必须配置成主服务器，而另一台服务器必须配置成次服务器，它并不在意哪台机器失败恢复（FAILOVER STARTUP）多少次。

当一个服务器开始工作时，如果它还没有与它的失败恢复备机通讯，它就必须先建立与失败恢复备机建立通讯，然后同步数据，之后才能提供服务。这可能发生在你刚配置完你的DHCP服务器成为失败恢复备机中的一台时，或者其中一台失败恢复伴侣服务器挂掉，并且丢失了它全部的数据。初始化恢复的过程设计要求确定伴侣服务器中的一台丢失了它的数据并且需要重新同步。失效的服务器在失效前分配的所有租约都将被认为有效，当它启动完成后，它发现它没有保存失败恢复数据，它就会尝试与它的伴侣通讯。当它们建立通讯后，它会要求伴侣服务器提供全部的租约数据库的拷贝，接着伴侣服务器发送完整的数据库，发送完成后，再发送一个信息，表示传送完成，失败的服务器接下来就等待，直到MCLT信息到达，一旦MCLT到达，两台服务器就转换到正常状态操作。这个等待时间由两台服务器设置的MCLT时长决定。

当一个服务器从失效状态恢复后，它的伴侣仍就保持partner-down 状态，这表示它为所有客户端提供服务，失效的服务器不会提供任何服务，直到它转换到正常状态。

当两台服务器都发现它们从未与伴侣进行通讯，它们会都按照前面描写的过程进入恢复状态。这种情况下，直到MCLT过期，客户端才能得到DHCP服务。



配置失败恢复

为了配置失败恢复，需要配置失败恢复协议的声明语句，并且在每个需要失败恢复的地址池中配置推荐服务器。在一个指定的网络中，不需要为每个池都配置失败恢复。不能配置其中一个服务器在某个地址池上执行失败恢复，而另一个服务器不在这个地址池上执行失败恢复，对于一个指定的地址池，是否执行失败恢复的配置应该是相同的。一个使用失败恢复的地址池的语句像下面的样子：



pool {

failover peer "foo";

deny dynamic bootp clients;

pool specific parameters

};



动态BOOTP租约不适合失败恢复，并且，如上，应该不允许失败恢复的地址池中有BOOTP客户。

服务器当前对配置文件只做很少的检查，因此，如果你配置有错，服务器就会表现的很奇怪。我想推荐你要么就做失败恢复，要么就别做，不要在服务器上混合做。而且，为两台服务器使用相同的主配置文件，引用各自使用自己独立的失败恢复相关的文件。这会帮助减少很多配置错误。

随着使用的增加，失败恢复服务器的问题会变得越来越少。一个基本的主服务器的dhcpd.conf文件如下



failover peer "foo" {

primary;

address anthrax.rc.vix.com;

port 519;

peer address trantor.rc.vix.com;

peer port 520;

max-response-delay 60;

max-unacked-updates 10;

mclt 3600;

split 128;

load balance max seconds 3;

}

include "/etc/dhcpd.master";



上面用到的语句声明意义如下：



primary 、secondary主、次服务器声明语句：



[ primary | secondary ];



它决定服务器的角色是主还是次，描述在前面DHCP FAILOVER部分。



address 语句



address address;



address 语句声明了服务器应该侦听或者连接的失败恢复伴侣的IP地址或域名，同时也是DHCP失败恢复协议服务器的标识。因为这个值用来标识DHCP服务器在失败恢复伙伴中的地位，它不能被省略。（这里应该是本机的IP地址或域名，因为下面的peer address语句里面言定义的是对端的IP地址或域名，如果按照字面的解释，这两个语句实际是冲突的，再看上面的例子，也应该是本机的IP或域名，需要实验确定一下）



peer address语句



peer address address;



表示失败恢复伴侣的IP地址或域名。



port语句



port port-number;



本机监听的TCP端口号，用来监听伴侣服务器的信息。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。



peer port 语句



peer port port-number;



指定要连接的伴侣服务器的TCP端口号。当前这个选项不能被省略，因为失败恢复协议还没有保留的TCP 端口号。它可以和port 语句的端口号是一个端口号。



max-response-delay 最大回应延时语句



max-response-delay seconds;



最大回应延时语句说明多少秒后DHCP服务器没有收到伴侣的信息，它会认为伴侣已经失效。这个值应该足够小，如果一个短暂的网络失效打断伴侣之间的连接不会影响服务器间的通讯太长时间，但是也要足够大，让服务器可以建立中断的连接。这个参数必须指定。（这里的解释也有问题，可以按例子来设置，具体可能会依靠环境作优化）



max-unacked-updates语句



max-unacked-updates count;



max-unacked-updates 语句告诉DHCP服务器在接收到从伴侣服务器收到BNDACK信息之前可以发送多少个BNDUPD信息。我没有足够的操作经验来说明这个值多大为好，但是10看起来能工作，这个值必须指定。



mclt语句



mclt seconds;



mclt 语句定义了客户端最大引导时间（Maximum Client Lead Time），它一定要在主服务器上指定，不需要在次服务器上指定。这是伴侣服务器双方不通讯而分配的租约更新的时长。设置的越长，运行的服务器恢复转到PARTNER-DOWN 的时间就越长;设置的越短，服务器不能通讯时的负载就越大。设置为3600或许比较好，但是我们并没有真正实际的经验。



split 语句



split index;



split 语句指定主、次服务器之间的负载平衡，当一个客户端发送一个DHCP请求，DHCP服务器按哈希算法为客户机设定地址，如果哈希算法得出的值小于分隔值，主服务器应答，如果值大于或等于分隔值，次服务器应答。唯一有意义的值是128，并且只能配置在主服务器上。



hba语句



hba colon-separated-hex-list;

hba 语句指定主次服务器之间的分隔作为位图而不是中断（as a bitmap rather than a cutoff）, 这理论上允许了更精细的控制。在实践中，一般不需要如此精细的控制。一个hba 语句的例子如下：



hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;



这等价于“split 128”，只能有一个split 或者hba定义，不能两个都有。大多数情况下，更精细的控制hba 并不需要，一般都使用split，很少使用hba。



load balance max seconds语句



load balance max seconds seconds;



这个语句允许配置一个界限，过了这个界限后负载平衡就被关闭。这个界限基于客户端发送DHCPDISCOVER 或者 DHCPREQUEST之后的秒数，并且需要客户端装配secs字段――幸运的是，大多数客户端都这样。我们推荐设置这个值为3 或 5。这个语句的作用是：如果一个失败恢复的伴侣进入一种状态，它对另一个伴侣有应答，但对客户端没有应答，正常的一台将会接管另一台的负载。



客户端分类(class)

客户端可以被分成一些类，并且按照所属的类被区别对待，这个区分可以由conditional 语句完成，或者由class语句中的match语句完成。可以指定某个指定的类或子类在同一时间内获得租约的全部客户端的限制数目，也可以基于客户端发送包的内容来自动指定子类。

基于条件的客户端分类，可以在class语句中指定一个matching表达式：



class "ras-clients" {

match if substring (option dhcp-client-identifier, 1, 3) = "RAS";

}



注意，不管使用match语句或者使用add语句(或者两者都使用)来给客户端分类，都必须首先声明用到的客户端的类。如果没有match语句也没有in-scope语句，类声明语句就会是这个样子：（这里有个矛盾，前面应该是in-scope，而不是add）



class "ras-clients" {

}



子类(SUBCLASSES)

除了类，也可能会用到子类subclass。子类是与通常的类有相同名字，但是又有特定的可以用哈希算法快速匹配的附加条件(submatch)。这本质上是速度问题――一个有五个match语句的类和一个类有五个子类的主要区别是使用子类速度更快，子类的工作方式如下：



class "allocation-class-1" {

match pick-first-value (option dhcp-client-identifier, hardware);

}



class "allocation-class-2" {

match pick-first-value (option dhcp-client-identifier, hardware);

}



subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;

subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;

subclass "allocation-class-1" 1:0:0:c4:aa:29:44;



subnet 10.0.0.0 netmask 255.255.255.0 {

pool {

allow members of "allocation-class-1";

range 10.0.0.11 10.0.0.50;

}

pool {

allow members of "allocation-class-2";

range 10.0.0.51 10.0.0.100;

}

}



在子类声明语句中跟在类名后的数据是一个固定值，用来匹配类中的match语句。当类匹配完成后，服务器会计算match语句，然后在哈希表中查找结果。如果找到一个匹配，客户端就被认为是一个这个类和这个子类的成员。

子类Subclasses可以有也可以没有scope语句，在上面的例子中，使用子类的单一目的就是允许一些客户端使用其中一个地址池，而其它一些客户端使用别的地址池，所以这些子类没有使用scope语句。如果使用子类的部分目标是为部分客户端定义不同的参数，那就可能定义子类时使用scope语句了。在上面的例子里，如果你的一个客户需要一些配置参数，而它客户则不需要这些参数，可以为这个客户使用下面的子类声明：



subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {

option root-path "samsara:/var/diskless/alphapc";

filename "/tftpboot/netbsd.alphapc-diskless";

}



在这个例子里，我们使用子类来控制为每个客户进行地址分配。然而也可能使用子类不指明客户端，例如，使用值vendor-class-identifier 选项来确定给vendor-encapsulated-options选项发送什么值。在dhcp-options(5)手册中的VENDOR ENCAPSULATED OPTIONS 里有一个例子。



动态地址分配时类的限制(PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION)

可以给某个类指定一个可以分配的客户端的数目的最大值限制，它的影响是一个新的客户端可能很难得到一个地址。一旦类的这个限制数达到，新客户端得到地址的唯一可能就是原来的某个客户端放弃了租约，不管是租约过期还是发送DHCPRELEASE包，有租约数限制的类都像下面一样：



class "limited-1" {

lease limit 4;

}



这将使这个类同一时间最多只能有4个成员。



自动产生子类的类SPAWNING CLASSES

可以定义一个spawning class， spawning class是一个根据客户端发送内容自动产生子类的类。Spawning class建立的原因是为了使建立租约限制的类不工作。假定使用在cable-modem环境中， ISP想为一个点的客户提供不只一个IP地址，但不希望这个客户建立自己的子网，或者给这个客户连接的网段里无限制的IP地址数，很多cable modem的头端系统可以配置一个DHCP的中继代理信息，它可以把客户端的DHCP请求发送到DHCP服务器，这些典型系统都会使用虚电路号(circuit ID)或者远程ID号(remote ID)来确定用户位置。为了利用这些，可以如下的类定义语句：



class "customer" {

spawn with option agent.circuit-id;

lease limit 4;

}



现在，一旦用户节点的请求到达后，circuit ID选项将会在hash表中检查。如果发现其中一个子类匹配了这个电路号(circuit ID)，这个客户将会被归入这个子类并按这个子类成员对待。如果没有发现匹配，一个新的类将会建立并记录在dhcpd.leases 文件中，这个客户会被归入这个新类中。客户端被归类后，它将按照类的成员对待，在这种情况下，按类成员对待每个点最多4个成员。

使用子类生成机制并不仅限于中继代理选项，使用这个例子只是因为它容易理解。



组合匹配等(COMBINING MATCH, MATCH IF AND SPAWN WITH)

有些情况下，使用一个表达式指定一个客户端到一个类，然后用第二个表达式把它放到一个子类中是很有用的。这可以由组合match if 和spawn with语句完成，或者由match if 和match完成，例如：



class "jr-cable-modems" {

match if option dhcp-vendor-identifier = "jrcm";

spawn with option agent.circuit-id;

lease limit 4;

}



class "dv-dsl-modems" {

match if opton dhcp-vendor-identifier = "dvdsl";

spawn with option agent.circuit-id;

lease limit 16;

}



这允许你的两个类中有相同的spawn with 表达式，而不会把一个客户端弄到两个类中，从而互相混乱



动态DNS更新（DYNAMIC DNS UPDATES）

DHCP 服务器有可以动态更新DNS的能力。在配置文件中，你可以定义如何使DNS更新，这些更新是指符合RFC 2136的DNS。支持RFC 2136 应该能够从DHCP服务器中进行动态更新。

两个DNS更新草案已经实施，另一个正在规划中。两个已经实施的是ad-hoc DNS 更新模式和interim DHCP-DNS 交互更新模式。如果当DHCP-DNS交互模式和DHCID模式通过IETF标准过程，就会有第三种方案，会是标准DNS更新模式。DHCP服务器必须被配置成一种或两种当前支持的模式，或者配置为不进行DNS更新。这些将在ddns-update-style 中配置。



AD-HOC DNS更新草案

ad-hoc动态DNS更新草案现在有很多反对意见，而且不能工作，以后的ISC DHCP服务器计划中看起来也不会支持它。interim 草案可以工作，允许失败恢复，现在也可以用，下面的描述仅仅作为资料。

这个版本的ISC DHCP中的ad-hoc动态DNS更新草案仅仅是原型设计，它与已经标准化的IETF DHC工作组标准没有很多关系，但是安装很基本，也很有效，能够更新。这种模式与失败恢复不能同时工作，因为它没有解决两个不同的DHCP服务器更新同一组DNS记录。

对于ad-hoc DNS更新方式，客户的FQDN起源自两个部分，首先，主机名是确定的，然后，域名是确定的，紧接着主机名。DHCP服务器决定客户端的主机名时，首先查找ddns-hostname配置选项，如果有，就用它;如果没有找到这个选项，服务器在FQDN选项中查找一个有效的主机名，把它发送给客户端。如果找到一个，就用它，否则如果客户端发送了host-name选项，就用它。否则，如果有一个host 语句对应这个客户端，语句中的名称就会被用上。如果上面所有的都没有，服务器不会发送给客户端hostname，也不能进行DNS更新。

域名严格基于服务器的配置，而不基于客户端发送的内容。首先，如果有一个ddns-domainname 配置选项，就用它;否则，如果有一个domain-name 选项配置，就用它。如果两个都没有，服务器就不进行DNS更新。

正如我们描述的，客户端有完全资格的域名用来作为”A”记录中的名字存储。A记录包含了租约中客户端被分配的IP地址。如果DNS服务器中已经有了一个相同名字的A记录，就不会对A或PTR记录更新了，这会阻止一个客户端宣称它的域名是某些网络的服务器。例如，如果你有一个文件服务器叫"fs.sneedville.edu"，并且一个客户端宣称它的主机名是"fs"，这时DNS就不会为这个用户更新DNS记录，同时会在日志文件中记录这个错误。

如果一个A 记录更新成功，那么对应的PTR记录也会被更新，指向A记录。这个更新是无条件的，即使有相同名字的另一个PTR记录存在。既然IP地址已经被DHCP服务器分配了，它就应该是安全的。

请注意当前我们假定客户端只有一个网络接口，如果客户端有两个网络接口，它会得到不希望得到的结果。现在这还是个bug，下一个版本也许会修复它。启用one-lease-per-client 参数是有用的，那样漫游进来的客户就不会触发相同的地址分配。

DHCP 协议通常包含4个包交换，首先客户端发送DHCPDISCOVER信息，接着服务器回应一个DHCPOFFER信息，然后客户端发送一个DHCPREQUEST信息，服务器再回复一个DHCPACK信息。在当前的版本中，服务器在收到一个DHCPREQUEST信息后会要求DNS更新，这个动作在发送DHCPACK之前。如果它前面没有为客户端发送地址，它只发送DNS更新信息，为了最小化DHCP服务器的压力，如果它还没有完成为客户端发送地址时，它只发送DNS更新信息。



当客户端的租约过期时，DHCP服务器(如果它正好在操作，或者马上就要被操作)将会从DNS数据库中移去客户端的A 和PTR 记录。如果客户端通过发送 DHCPRELEASE信息释放了它的租约，服务器将会移去A 和PTR记录。



THE INTERIM DNS UPDATE SCHEME过渡DNS更新方案

interim DNS 更新方案案大多数遵守几个被IETF考虑并希望成为标准的草案，但现在还不是标准，也不是当前提议的精确标准。它们是：



draft-ietf-dhc-ddns-resolution-??.txt

draft-ietf-dhc-fqdn-option-??.txt

draft-ietf-dnsext-dhcid-rr-??.txt



因为我们的操作与标准有稍微的不同，这里简短的说明一下这种更新方式。

第一点，理解这种方式的DNS更新不像ad-hoc 方式，DHCP 服务器不需要总是更新A 和PTR 记录，FQDN 选项包含了一个标志，当由客户端发送时，它指示客户端希望更新自己的A记录，这种情况下，服务器可以被配置成信任客户端信息或者忽略这个信息。这由allow client-updates语句完成或者是ignore client-updates语句完成。默认情况下，客户端更新是被允许的。

如果服务器配置允许客户端更新，然后如果客户端在FQDN选项中发送了一个完全合格的域名，服务器就会在FQDN选项中采用客户端发送的名字来更新PTR记录。例如，假定客户端是来自"radish.org" 域的一个访问者，它的主机名是"jschmoe"，服务器管理的是"example.org"域，DHCP客户端发送的FQDN选项是"jschmoe.radish.org."，它也要求更新自己的A记录，DHCP服务器因此不去试图为这个客户端设置A记录，但是要为这个IP地址设置PTR记录，它可以自行更新自己的A记录，假定"radish.org"的DNS服务器允许这样做。

如果服务器配置不允许客户端更新，或者客户端不想自己更新，服务器就会简单的选择一个名字发送给客户端，可能使用客户端自己提供的主机名 (在这个例子中是"jschmoe")，它将会把自己的域名传送给客户端，就像在ad-hoc update更新中一样。它会更新A和PTR记录，使用它为客户端选择的名字。如果客户端发送了完全合格的FQDN选项，服务器只会选用最左边部分，前面的例子中，"jschmoe" 而不是"jschmoe.radish.org"。

两种更新模式的另一种不同是，在interim 模式中，有一种方法允许不只一个DHCP服务器更新DNS数据库而不会偶然删除掉不该删掉的A记录，也不会添加应该添加的记录失败，它工作的方式如下：

当DHCP服务器发布一个客户租约时，它建立一个文本串，这个文本串是一个MD5哈希处理的DHCP客户端鉴定(参见draft-ietf-dnsext-dhcid-rr-??.txt for details)，这个更新给A记录增加了服务器选择名字和一个包含哈希鉴定字符串的TXT记录 (hashid)，如果这个更新成功，服务器的工作完成。如果因为A记录已经存在而导致更新失败，DHCP服务器会尝试添加A记录，前提是必须有一个和新的A记录同名的TXT记录，并且那个TXT记录包含相同的hashid。（乱了，搞不清意思）If the update fails because the A record already exists, then the DHCP server attempts to add the A record with the prerequisite that there must be a TXT record in the same name as the new A record, and that TXT record<A1><AF>s contents must be equal to hashid. 如果这次更新成功，客户端就会拥有它的A和PTR记录，如果失败，客户端已经被分配的名字已经被使用了，不能被再用了，此时，DHCP服务器放弃进行为这个客户所做的DNS更新并为这个客户选择一个新的名称。

interim DNS 更新方案被叫做interim 有两个原因：一是它并不完全遵守草案，当前的草案使用新DHCID Rrtype，但是现在不能用，interim DNS 更新使用TXT record替代。而且，现存的ddns草案要注DHCP服务器在PTR记录上发送DHCID RR，而interim 更新方案不这样做，在我们的观点中，和作者一起工作的人都希望在下一个草案中去掉这些东西，或者说明为什么这样做是有用的。

除了这些不同，服务器的更新并不很强势。因为每个DNS更新包含一个到DNS服务器的数据往返，即使它不真的修改DNS数据库，这样的更新也消耗资源，于是DHCP服务器不管它是否原来更新过记录(这个信息保存在lease中)都不再尝试更新记录，而是认为记录已经更新。

这会导致一种情况，DHCP服务器添加了一个记录，而这条记录又被其它机制删除掉了，但是DHCP服务器再也不去更新DNS，因为它认为它已经更新过了。这种情况下，可以通过移去租约文件中的相关内容来操作，一旦操作完成，下次客户端更新租约时就会DNS就会被更新。



DNS动态更新安全

当设置DNS服务器允许通过DHCP动态更新后，就可能出现未授权的更新。为了避免出现这种情况，应该使用TSIG 签名――使用共享密钥进行密码签名的方法。只要你保护好这个密钥，你的更新就应该是安全的。注意，DHCP协议自身没有提供安全，同时，客户端可以提供信息到DHCP服务器，而DHCP服务器使用这个信息进行更新，如同前面描述的一样。DNS服务器必须配置成允许DHCP服务器要更新的区域更新。例如，假定sneedville.edu 域中的客户被分配地址是10.10.17.0/24子网，在这里，会需要一个key语句来确定将要使用的TSIG密钥，同时还要两个区域语句（zone），一个是A记录的，一个是PTR记录的，对于ISC BIND，会像这样：



key DHCP_UPDATER {

algorithm hmac-md5;

secret pRP5FapFoJ95JEL06sv4PQ==;

};



zone "example.org" {

type master;

file "example.org.db";

allow-update { key DHCP_UPDATER; };

};



zone "17.10.10.in-addr.arpa" {

type master;

file "10.10.17.db";

allow-update { key DHCP_UPDATER; };

};



同时也必须配置DHCP服务器来更新这个区域，可能需要添加如下的内容到dhcpd.conf 文件中：



key DHCP_UPDATER {

algorithm hmac-md5;

secret pRP5FapFoJ95JEL06sv4PQ==;

};



zone EXAMPLE.ORG. {

primary 127.0.0.1;

key DHCP_UPDATER;

}



zone 17.127.10.in-addr.arpa. {

primary 127.0.0.1;

key DHCP_UPDATER;

}



primary 语句指定区域数据需要更新的DNS的IP地址。注意zone 语句一定要对应DNS中authority 记录，在上面的例子中，必须有一个"example.org."和"17.10.10.in-addr.arpa."的SOA 记录。例如，如果有一个子域"foo.example.org"，它没有独立的SOA，就不能为它配置一个zone语句。也一定要记住，在DHCP配置文件中，区域名称一定要以"."结束，这是首选句法。如果没有以"."结束，DHCP服务器就会被弄糊涂，也要注意在DHCP配置中，区域名称没有包含在引号里面，而在DNS配置中是要包含在引号里的。

你应该自己选择密钥，当然ISC BIND 8 和9 安装版本里面有一个密钥生成工具，叫dnssec-keygen， BIND 9中的工具看起来生成的密钥更随机，因此推荐使用BIND 9中的工具，即便不用BIND 9做DNS服务器。如果使用BIND 9 的dnssec-keygen，上面的密钥将会按下面的方法生成：



dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER



如果使用BIND 8 的dnskeygen 程序，用下面的命令生成密钥：



dnskeygen -H 128 -u -c -n DHCP_UPDATER



如果想激活DNS日志记录DNS更新，需要一个logging语句：



logging {

channel update_debug {

file "/var/log/update-debug.log";

severity debug 3;

print-category yes;

print-severity yes;

print-time yes;

};

channel security_info {

file "/var/log/named-auth.info";

severity info;

print-category yes;

print-severity yes;

print-time yes;

};



category update { update_debug; };

category security { security_info; };

};



在开始DNS服务前需要先建立/var/log/named-auth.info 和/var/log/update-debug.log两个文件。更多配置ISC BIND的信息，参见随机文档。

dhcpd.conf用到的所有参数（REFERENCE: PARAMETERS）

always-broadcast语句



always-broadcast flag;



DHCP 和BOOTP 协议都需要DHCP和BOOTP客户端在BOOTP信息头的标志位设置广播标志，不幸的是，有些DHCP 和BOOTP客户不这样做，因此它们不会从DHCP服务器中获得回应。DHCP服务器可以通过relevant scope设置标志设置成总是广播它的回应到客户端，relevant scope可以在一个conditional语句中，作为一个类的参数，或者host的参数。为了避免网络中出现过多的广播包，推荐尽量限制使用这个选项。例如， Microsoft DHCP 客户端已知没有这个问题，OpenTransport和ISC DHCP 客户端也没有这个问题。



always-reply-rfc1048 语句



always-reply-rfc1048 flag;



一些BOOTP 客户端需要FC1048格式的回应，但是发送请求时却不遵守RFC1048的规定。可以告诉有这个问题的客户端，如果它没有获得你为它配置的选项，同时如果在服务器的日志中找到对应于每一个BOOTREQUEST 的"(non-rfc1048)"，可以为这样的客户提供rfc1048 回应：在客户的host语句中设置这个选项，这样DHCP服务器就会为这个客户提供RFC-1048-style 的回应了。这个标志可以设置在任何地方，对它起作用的区域都产生影响。



Authoritative语句



authoritative;

not authoritative;



对于一个指定的网段配置信息，DHCP 服务器通常不知道自己是否是合法和权威的。因此，如果一个天真的用户安装了DHCP服务器，也不知道如何配置它，它就不会为收到的DHCP请求发送假的DHCPNAK信息。

网络管理员为他们的网络设置权威的DHCP服务器，需要在配置文件的顶层添加authoritative语句，来指示此DHCP服务器应该回应DHCPNAK信息。如果没有做这些，客户端在改变子网后就不能得到正确的IP地址，除非它们旧的租约已经到期，这可能需要相当长的时间。

通常，在配置文件的顶部标明authoritative应该是足够的，但是如果一个DHCP服务器知道它在一些子网中是权威的服务器，而在另一些子网中不是，它就需要在需要的网段声明自己是权威的。

注意，这个权威的概念更多的存在于物理网络中，不管是多子网环境还是单子网环境。指定一个服务器在某个多子网环境中的单个子网中是权威的而在别的子网中不是权威的是没有意义的。



boot-unknown-clients语句



boot-unknown-clients flag;



如果有boot-unknown-clients语句并且值是false 或者 off，那么对于没有host 语句定义的客户端将不允许获得IP地址。如果这个语句不存在或者值为true 或on，没有用host语句定义的客户端将被允许获得IP地址。如同那些在池中没有被allow或者deny语句限制的地址一样。



ddns-hostname语句



ddns-hostname name;



这个name 参数是hostname，它将被用来设置客户端的A和PTR记录。如果没有ddns-hostname 设定，服务器将会自动使用hostname代替，两种方法使用不同的算法更新。



ddns-domainname 语句



ddns-domainname name;



这个name参数是域名，它添加到客户端hostname后面，形成一个完整有效的域名domain-name (FQDN)。



ddns-rev-domainname语句



ddns-rev-domainname name;

这个name参数是域名，它会添加到客户端的反向IP地址（reversed IP address）中，在客户端的PTR记录中产生一个可用的名字。默认情况下，它是"in-addr.arpa."，但是这里可以修改默认值。

这个被添加的域名的客户端的反向IP地址，是由点“.”分隔的，例如，如果客户端得到的IP地址是10.17.92.74，那么反向IP地址就是74.92.17.10，那么客户端的PTR记录就会是10.17.92.74.in-addr.arpa.（好像不对呀，应该是92.17.10.in-addr.arpa）



ddns-update-style 参数



ddns-update-style style;



这个style参数必须是ad-hoc、interim或者什么也没有。ddns-update-style语句只在外部范围使用―― 它只在读入dhcpd.conf 文件时进行解释，而不是每次客户端获得地址时，因此不可能为不同的客户使用不同的DNS更新方法。



ddns-updates语句



ddns-updates flag;



这个ddns-updates参数控制当一个租约确定后服务器是否尝试进行DNS更新。 设置成off在其范围内将不会尝试更新。默认这个值是on。在全部范围内禁止DNS 更新，使用ddns-update-style 语句，把值设置成none。



default-lease-time语句



default-lease-time time;



Time是以秒为单位的租约时长，如果客户端没有要求特殊的延期的话。



do-forward-updates语句



do-forward-updates flag;



do-forward-updates语句在客户端获得或更新租约时指示DHCP服务器是否尝试更新DHCP客户的A记录。这个语句在DNS更新有效并且ddns-update-style设置为interim时才有用。默认些值是enable的。如果这个语句用于禁止Forward updates，DHCP服务器将会不再尝试更新客户端的A记录，如果客户端提供在PTR记录中使用的FQDN信息时，服务器将尝试更新客户端的PTR记录 。如果这个选项设为enabled，DHCP服务器将会信任client-updates 标志。



dynamic-bootp-lease-cutoff 语句



dynamic-bootp-lease-cutoff date;



这个dynamic-bootp-lease-cutoff 语句设置所有动态分配的BOOTP客户端租约的结束时间。因为BOOTP客户端没有任何方法更新租约，而且不知道他们的租约会过期， 默认情况下，dhcpd 分配给BOOTP客户无限的租约，然而，有时给BOOTP用户设置一个终止时间是有意义的。例如，学期结束时，或者到晚上设备关机时。日期应该是所有BOOTP租约结束时，日期应该以下面的格式设定：



W YYYY/MM/DD HH:MM:SS



W 是表示星期几的数字，从0(星期日)到6 (星期六)， YYYY 是4位的年号， MM是月份，从1 到12，DD 是一月中的哪一天。从1开始。HH 是小时从0到23，MM是分钟，SS是秒，时间总是设定为Coordinated Universal Time (世界时UTC)，而不是本地时间。



dynamic-bootp-lease-length 语句



dynamic-bootp-lease-length length;



这个dynamic-bootp-lease-length语句用来设置动态分配的BOOTP客户租约的时长。在某些站点，可能会假设如果在一段时间里如果BOOTP或者DHCP客户没有再次申请继续租用它的地址，就认为这个客户已经不使用这个地址了。这个时长设定使用秒为单位。如果使用BOOTP的客户端重启时超过租约时间，租约将会重新设定为原来租约的长度，这样一个足够频繁启动的BOOTP客户总是不会丢失租约。不需说明，这个参数应该非常小心的设置。



filename语句



filename "filename";



这个filename语句可以用来指定客户端启动要载入的初始启动文件，这个文件名应该是客户端能够识别的任何文件传送协议，可以用来传送那个文件。



fixed-address声明语句



fixed-address address [, address ... ];



这个fixed-address声明语句用来给一个客户端分配一个或者多个固定地址。它只能出现在host语句中。如果提供了多个地址，当客户端启动时，它会被分配到相应子网中的那个地址。如果没有一个fixed-address对于那个子网是有效的，客户端就不匹配这个host语句。每一个fixed-address 语句中都应该是IP地址或者是可以解析成IP地址的域名。



get-lease-hostnames语句



get-lease-hostnames flag;



这个get-lease-hostnames 语句用来告诉dhcpd是否查找租约池中每一个IP地址对应的域名，并且使用这个地址作为hostname选项。如果设置为true，就对范围内所有地址进行查找。默认是false，不进行查找。



hardware语句



hardware hardware-type hardware-address;



为了能够被识别BOOTP客户端，它的网络硬件地址必须在host语句中使用hardware子句声明。hardware-type必须是物理硬件接口类型，现在只可以识别ethernet和token-ring 类型，虽然支持fddi类型 (或者其它的)。硬件地址应该是一组16进制数(从0到ff) ，扩冒号分隔。hardware 语句也用于DHCP 客户端。



lease-file-name语句



lease-file-name name;



这里的名字是DHCP服务器存放租约的文件名。默认是/var/lib/dhcp/dhcpd.leases。这个语句必须出现在配置文件的顶部，出现在其它位置无效。



local-port语句



local-port port;



这个语句使DHCP 服务器在指定的UDP端口侦听DHCP 请求，而不一定是默认的67。



log-facility语句



log-facility facility;



这个语句使DHCP服务器把它的所有日志记录到一个指定的日志设备上，一旦dhcpd.conf 文件被读入，默认DHCP服务器就到后台设备。可能的设备有auth， authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp, local0到local7。这些设备并不是在所有系统中都可以使用，有些系统中可能还有其它可用的设备。

除了设定这个值，可能还需要修改syslog.conf 文件来配置日志记录DHCP服务器的行为。例如，可能会需要增加这样一行：



local7.debug /var/log/dhcpd.log



不同操作系统中syslog.conf 文件的语句可能有些不同，要查看syslog.conf manual手册来确定一下。为了让syslog 开始记录一个新文件，必须先用有权限的用户名建立一个新文件(通常是与/var/log/messages或者/usr/adm/messages文件拥有者或与之有相同权限的)，并且发送一个SIGHUP 信号给syslogd。有些系统支持通过脚本或者一个叫newsyslog或者logrotate的程序循环记录日志，你可以配置它们，以免日志文件大的不可控制。

因为日志机制由dhcpd.conf 控制，因此分析dhcpd.conf 文件的日志会记录在默认的日志设备上，为了避免它，参看本发行版的README文件，那里描述了如何改变默认的日志设备。当使用这个参数时，DHCP服务器在分析完配置文件后立即把它的信息写入指定设备，这样日志就尽量完整了。



max-lease-time语句

max-lease-time time;



Time是以秒为单位的时间，用来分配的最长租约。例外的只有动态BOOTP租约长度，它不由客户端指定，也不由这个值限制。



min-lease-time语句



min-lease-time time;



Time 是用于租约的以秒为单位的最短时间。



min-secs语句



min-secs seconds;



Seconds是从客户端试图获得一个新的租约开始到DHCP服务器回应客户端请求时最小的秒数。这个秒数基于客户端的报告 ，客户端可以报告的最大值是255秒。通常设置它会导致DHCP服务器对客户端的第一次请求不做回应，但却对其第二次请求回应。

利用这个参数可以设置一个秒级DHCP服务器，通常他不对客户端分配地址，直到主服务器给它一个机会。如果主服务器死机，客户端就会绑定到这个次服务器上，但其它情况客户端都绑定在主服务器上。注意这个语句不能单独完成上面的功能，需要允许主、次服务器共享一个动态地址分配池。



next-server 语句



next-server server-name;



这个next-server 语句用来指定初始启动文件存放的主机地址 (filename指定的文件)。Server-name 是一个数字的IP地址或者是域名。如果没有next-server参数传送给客户端，就使用DHCP服务器的地址。



omapi-port 语句



omapi-port port;



这个omapi-port语句使DHCP服务器在指定的端口侦听OMAPI连接。这个语句需要激活OMAPI 协议，它用来在DHCP服务器运行时检验和修改它的状态。

one-lease-per-client语句



one-lease-per-client flag;



如果这个标志设置成enabled，当一个客户端发送一个DHCPREQUEST信息来租用租约时，服务器会自动释放所有这个客户的所有其它租约。服务器假定当一个客户端发送DHCPREQUEST信息时，它已经忘记任何它没有在DHCPREQUEST中提到的租约，例如，客户端只是一个简单的网络接口，不能记住原来拥有而现在不用的租约。这些假定都是没有保证，而且不可证明的，因此小心使用这个语句。



pid-file-name 语句



pid-file-name name;



Name是DHCP服务器的process ID 文件名。这个文件保存DHCP启动时的process ID。默认是/var/run/dhcpd.pid。如同lease-file-name语句，这个语句也要放在配置文件的最顶层。



ping-check 语句



ping-check flag;



当DHCP服务器准备动态分配IP地址给一个客户端时，它先发送一个ICMP Echo 请求 (ping)给这个要分配的地址，然后等1秒钏，如果没有ICMP Echo信息返回，它就分配这个地址。如果有返回信息，就把这个地址放弃，服务器不会给客户端回应。

这个ping检查导致在回应DHCPDISCOVER信息时默认有1秒钟的延迟，这对某些客户端可能是问题。可以在这里配置是否检查。如果这个值设置为false，就不进行ping检查。



ping-timeout 语句



ping-timeout seconds;



如果DHCP服务器决定发送ICMP ECHO检查 (ping)，因为ping-check 设置为true，ping-timeout允许配置DHCP服务器应该等多长时间。如果没有设置值，默认是1秒。



server-identifier语句



server-identifier hostname;



这个server-identifier语句可以用来定义指定范围里发送的DHCP服务器身份信息，这个指定的值必须是DHCP服务器的IP地址，而且必须能够使此范围内的所有客户端访问。

不推荐使用这个值，使用它的唯一目的是有时默认的值是不正确的。默认的值是第一个回应客户端的服务器地址。

还有一个不太常见的用法，当物理接口不只有一个地址时，需要设置 server-identifier值，并且发送的默认值可能不正确。另一个情况是，为了在DHCP服务器中拥有固定IP地址而定义一个别名，并且希望客户端与服务器联系时使用这个IP地址。为dhcp-server-identifier 提供一个值等价于server-identifier语句。(!有些问题)



server-name语句



server-name name ;



这个server-name 语句用来告诉客户端分配地址的服务器的名字。 Name 是提供给客户端的名字。



site-option-space语句



site-option-space name ;



这个site-option-space 语句用来决定本地地址选项(site-local)。这与vendor-option-space 语句有很多相似之处。DHCP中的Site-local是数字大于128的。这些选项倾向于使用详细地址(site-specific)，但是它经常被嵌入式硬件开发商使用，包含DHCP客户端。因为site-specific选项是在ad hoc环境下分配的，很可能一个开发商的DHCP客户端使用与另一开发商相同的代码而实现不同的目的。site-option-space 选项可以使用conditional evaluation为每个不同的开发商分配不同的一组的site-specific选项 (参见 dhcp-eval (5))。



stash-agent-options语句



stash-agent-options flag;



对于指定的客户端，如果stash-agent-options(隐蔽中继代理)参数是true，当客户端在SELECTING状态，并且行为如同在DHCPREQUEST序列中的RENEWING 状态，服务器将会记录客户端初始化DHCPREQUEST期间中继代理发送的信息。它在与中继代理共同工作时有问题，就是它们通常不在客户端的DHCPREQUEST信息中 ，在RENEWING状态中，因为这些信息是直接到服务器的单播信息，并不经过中继代理。(？)



update-optimization语句



update-optimization flag;



对于指定的客户端，如果update-optimization(更新优化)参数是false，每次在这个客户端更新租约时，服务器都会为这个客户尝试进行DNS更新，而不是服务器认为有必要时才更新。这将使DNS更容易保持数据库的一致性，代价是DHCP服务器要多做很多次DNS更新。推荐激活这个功能，这也是默认的。这个选项只影响interim DNS 更新。对ad-hoc DNS 更新没有影响。如果不指定这个参数，或者参数是true， DHCP服务器只在客户端信息改变时进行更新：比如客户端得到了一个不同的租约，或者租约过期。



update-static-leases 语句



update-static-leases flag;



这个update-static-leases标志如果是enabled，使DHCP服务器即使在客户端分配的是固定地址时也做DNS 更新。这只作用于interim DNS更新方案中。不推荐使用，因为DHCP服务器没办法结束更新，因此地址不用时也不会删除记录。而且，服务器必须在客户端更新租约时尝试更新，这在负载很高的DHCP系统中造成了明显的性能下降。



use-host-decl-names 语句



use-host-decl-names flag;



如果在指定范围内use-host-decl-names 参数是true，这个范围内所有的host语句，提供给host语句的name将会是客户端自己的hostname.，因此，例如：



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语句中可选的host-name语句将会覆盖host中的名字。应该注意，大部分DHCP客户端都完全忽略了DHCP服务器发送的host-name选项，而且没有办法配置它们不这样做。因此通常都选择不提供任何hostname给客户端，或者执行DNS更新。本文档中有具体的内容描述如何操作。



use-lease-addr-for-default-route 语句



use-lease-addr-for-default-route flag;



在指定范围内，如果use-lease-addr-for-default-route参数是true，那么，不再给分配租约的IP地址或客户端发送routers选项(或者不发送信息)，。 可以想象，这会导致WIN95的机器解析所有IP地址，它在网关配置成proxy ARP时有用。这种用法不被推荐，因为很多DHCP客户端都不支持这个做。(将自己作为网关，广播查找目标地址)



vendor-option-space 语句



vendor-option-space string;



vendor-option-space 参数指定开发商参数。使用这个配置参数在dhcp-options(5) 中有详细解释。在 VENDOR ENCAPSULATED OPTIONS一节。



使用表达式设置参数值SETTING PARAMETER VALUES USING EXPRESSIONS

有时可以根据客户端发送的内容设置服务器上的某些参数是有用的。完成这些，可以使用表达式。dhcp-eval(5)手册描述如何使用表达式。把等式的值赋给参数，定义参数的方法如下：



my-parameter = expression ;



例如：



ddns-hostname=binary-to-ascii(16,8,"-", substring (hardware, 1, 6));



REFERENCE: OPTION STATEMENTS

DHCP 选项语句在dhcp-options(5)手册中。



REFERENCE: EXPRESSIONS

DHCP 选项语句的表达式和elsewhere 在dhcp-eval(5) 手册中



另见

dhcpd(8), dhcpd.leases(5), dhcp-options(5), dhcp-eval(5), RFC2132, RFC2131.



作者

dhcpd.conf(5)作者Ted Lemon与 Vixie 实验室。此项目由ISC提供http://www.isc.org。



翻译：liufirst