-
4 DHCP
高级服务器配置
4.1
DHCP
规划
（
1
）小型网络
DHCP
服务器
1
）
DHCP
服务器硬件设备选择
2
）计算机
IP
获取方式规划
（静态、动态）
（
2
）大型网络
DHCP
服务器
1
）
DHCP
服务器位置：核心交换机
2
）
DHCP
服务器作用域设置：租约，台式和笔记本
（
3
）跨路由网络
DHCP
服务器
可以搭建
一台
DHCP
服务器，同时在连接多个子网的路由器上设置
DHCP
中继代理就可以利
用路由器转发<
/p>
DHCP
消息，所有计算机能够通过
DH
CP
服务器获取
TCP/IP
信息
（
4
）
80/20
规则
Failover peer
“
my
”
{
Primary;
Address
4.2
DHCP
多作用域设置
（
1
）简单实现
DHCP
多作用域
（
2
）
DHCP
超级作用域功能及实现<
/p>
关于超级作用域的配置，在
配置文件中有固定格式
shared-
network
超级作用域名称
{
#
作用域名称，标示超级作用域
[
参数
]
#
该参数对所有子作用域有效，可以
不配置
subnet
子网编号
netmask
子网掩码
{
[
参数
]
[
声明
]
}
}
修改
配置文
件，建立超级作用域并添加新作用域。
Ddns-
update-style interim;
Ignore client-
updates;
Shared-network super {
Option domain-name-servers 192.168.1.1
Option subnet-mask 255.255.255.0;
Default-lease-time 21600;
Max-lease-time 43200;
Subnet
192.168.2.0 netmask 255.255.255.0 {
}
Subnet
192.168.3.0 netmask 255.255.255.0 {
}
}
交换机配置：
System-view
Dhcp enable
Dhcp-server 1 ip a.b.c.d
Interface vlan-interface 100
Dhcp-server 1
Quit
Interface vlan-interface 200
Dhcp-server 1
Quit
Save
Option router
192.168.3.1;
Range dynamic-bootp
192.168.3.10 192.168.3.254;
Option
router 192.168.2.1;
Range dynamic-bootp
192.168.2.10 192.168.2.254;
名称
- dhcpd
配置文件
描述
文件包括
ISC DHCP
的
dhcpd
的配置信息。
文件是一个普通格式的
ASCII
码文档，<
/p>
它由内置的递归解析
器解释。
dhcpd.
文件可能会包含许多
额外的
tab
和空格、
空行，
它们的目的是让
文件更容易阅读。
其中的关键字对大小写不敏感。注释语句可以放在任何位置
（除了引号中）
注释语句用
#
开头，这一行结束时注释语句自然结束。
文件包括一组语句，语句在一对大括号中，包含参数和声明。
参数语句说明如何做一件事（例如，租期是多长时间），或者是否做一
件事情。
(
例如，
dhcpd
是否为未知客户提供地址
)
，或者给客户提供哪种参数
(
例如，
使用网关
220.177.244.7)
。
声明用来描述网络的拓扑结构、网络上的客户，提供可以为客户端分配
的地址，或者对某个客户端组应用组（
group
）参数。在任何组参数中，所有的
这些组参数必须比使用这些组参数的语句先出现。
网络声明包含多子网的网络
（有些地方译为：
超网，
但超网太难理解了，
这里叫
“
多子网网络”
）
和子网的拓扑声明。
对
于子网的客户端被动态分配地址，
子网声明中必须有一个
ran
ge
声明语句。对于静态分配的地址，或者是已知客户
的安装，
每个客户端都必须使用一个
host
声明语句。如果一个参数应
用到一组
声明中，这些声明并不只与某个子网相关，可以定义一个“组参数”。
对每一个要服务的子网，
每个
dhcp
服务器连接的子网，
都必须有一个子
网声明
，
用来告诉
dhcpd
如何处理那个子
网上的地址。
即使一个子网不需要分配
任何地址，也需要一个子
网声明。
一些物理网络上不只有一个
IP
子网存在，
例如，
如果一个网络需要一个<
/p>
8
位的子网，但是当业务发展使总的节点数超过了
254
台，就需要增加一个
8
位
的子网。这时，就增加了一个新的物理网络，这种情况下，
2
个网络的子网声明
必须包含在一个“多子网网络声明（超级作用
域）”中。
有些网络的客户端不只有一个子网，可能会为同一子网中一些
客户端分
配的一些参数与其它的客户端不同。这样的用户可以使用
host
语句来定义，一
些参数也可以定义在“组参数”语句
中，它被这些客户端共同调用。对于需要根
据不同情况获得不同地址的客户端，可能会使
用“类声明（
class declarations
）”
和“条件声明（
conditional declaration
s
）”语句，这样可以根据客户端发送的信
息来决定分配给客户
端的参数。
当一个客户端启动时，服务器先查看是否有匹配客户端的
host
语句，如
果没有，再看是否有匹配
的“类声明（
class declarations
）”语句
，接着查看是否
有“池
pool
”匹配
，“子网
subnet
”匹配和“多子网网络（超级作用域）<
/p>
shared-net-work
”匹配。
（根据这些匹配，）将符合这个客户端的参数提供给它。
每种参数都不会被分析第
2
次，
如果它们出现了
2
次或
2
次以上，
那么会使用那
个最精确出现的地方。
dhcpd
首先查找客户端是否有包含固定
IP
地址的
host
语句，这个地址要
在客户端启动的那个子网中，或者“多子网网络”中，如果没有对应的
ho
st
语
句匹配，那就查找非固定地址的声明。
< br>
例如：
一个典型的
文件将会象下面这样：
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 {
host-specific parameters...
}
host {
host-specific
parameters...
}
host {
host-specific
parameters...
}
}
图
1
注意文件的开始，它是全局参数放置的地方，可能会是：
组织的
域名，
DNS
服务器的地址（如果这个服务器对整个网络都是一
样
的）和其它一些。比如：
option domain-name
option domain-name-servers ,
;
图
2
如图
2<
/p>
中所示，可以使用
DNS
服务器的名称而
不使用它的
IP
地址，如
果指定不只一
个
DNS
服务器地址，那么只要有可能，所有地址都会提供给客
户
端。
每个子网都要指明的最可能必须的参数是
router
，如图
1
所示。因此
对
于第一个子网，它就应该是这个样子的
option routers
204.254.239.1;
注意这里的地址是数字形式的，如果每个网关都有域名，这就
不是必须
的，使用域名也是合法的。然而，很多情况下，多个网关只有一个域名，这样就
不能使用域名了。
在图
1<
/p>
中，
有一个
group
语句，
它为一组
host
语句
zappo
，
beppo
和
harpo
提供了通用的参数。
< br>如你所见，
这些主机都在
这个域
里，
这样它在
“组
参数”中指明就会覆
盖全局设置的参数：
option domain-name
而且，指明它们的域，可能用在测试机器中，如果我们要测试
DHC
P
的
租约机制，可以在这里设置比默认值更短的租约：
max-lease-time
120;
default-lease-
time 120;
你可能注意到有些参数以
option
关键字开头，有些不。以
option
关键
字开头的语句对应实际的
DHCP
选项，不以
option
关键字开头的选项控制服务
端
(
例如，租期
) <
/p>
或客户端的选项不在
DHCP
协议中（例
如，服务器名或文件名）
在图
1
中，
每个
host
都有指定的参数，它会包含象
< br>hostname
选项，要
上传的文件名
(filename
参数
)
，还有要上传的服务器的地址
(next-server
参数
)
。
通常，
任
何参数都可以在任何可以出现的地方出现，
并且按照参数出现位置确定
< br>应用范围。
假设你的环境中有许多没有
CD
的
X
终端，这些终端有不同的型号，你
想为每种型号确定一个启动文件，一种方法是给每个服务器和组都使用
host
语
句：
group {
filename
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
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
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)
用来定义一个地址池，即便是在同一个网段或者子网，
< br>也可以定义几个池，系统将通过“池”来区分它们。例如，你可能想提供一大段
地
址分配给
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
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 ,
max-lease-time
28800;
range 10.0.0.5
10.0.0.199;
deny unknown-
clients;
}
}
上面这
个例子中，已知客户和未知客户在相同的子网中，也可能将已知
和未知客户分配在不同的
子网中，或者在“多子网层次（超级作用域）”，这样
地址池的范围可能跨越不同的子网
。
正如前面的例子，
地址池可以允许或拒绝一
< br>个控制用户存取的组，这个组名前面要有
allow
或<
/p>
deny
关键字。
如果一个池有一个允许列表，只有匹配的客户端才可以获得地
址池的地
址，如果这个池有一个拒绝列表，只有不匹配的客户端才可以获得池中的地址，
如果同时存在允许和拒绝列表，
那么只有在允许列表并且不在拒
绝列表中的客户
端才可以获得池中的地址。
动态地址分配
地址分配实际只在客户端在初始状态并且发送一个
DHCPDISCOVER
信息时完成。如果客户端认为它有一个有效的租
约并且发送了一个
DHCPREQUEST
信息来初始化或者更
新租约，服务器就只有
3
个选择：
（<
/p>
1
）它
可以忽略
DHCPREQUEST
信息，
并且返回一个
< br>DHCPNAK
信息来告诉客户端，
要求客户端停止使
用这个地址，（
2
）或者发送一个
DH
CPACK
信息，告诉客户
端继续再使用这个地址一段时间，<
/p>
如果服务器找到客户端要求的地址，
并且这个
地址对于这个客户也是可用的，服务器会发送一个
DHCPACK
< br>信息，如果这个
地址已经不能用了，
客户端就不能使用它
，
此时服务器将会发送一个
DHCPNAK
信息，（
3
）如果服务器不知道这个地址，它会先保持沉默
，除非这个地址对于
客户端依附的地址段是不正确的，
这种情况
下服务器会发送一个
DHCPNAK
，
即
便它完全不知道这个地址。
如果有一个
host
语句定义了客户端，同时
host
< br>语句中包含了固定地址
（
fixed-address<
/p>
），这个
IP
地址对于客户端实际连接的
网段也是合法的，此时
DHCP
服务器不动态分配地址，
而是发送
host
语句指明的地址。
如果此时用户发
送了
DHCPREQUEST<
/p>
信息来获得其它地址，
服务器会回应一个
DHCPNAK
信息，
来拒绝为用户分配其它地址。
当一个
DHCP
服务器为客户端分配一个新
的地址时
(
记住，
这只发生在客
户端发送
DHCPDISCOVER
信息时<
/p>
)
，
它首先查找
lease
文件，
看客户机是否存在
一
个有效的地址租约，
或者此客户机原来是否有一个地址
（这个地
址已经过期）
，
如果有，
服务器就会检
查那个地址，
看客户端是否被允许使用这个地址，
如果客
户端已经不被允许使用这个地址
（通常是客户机从另外一个子网登录了
，
或者此
地址被其它客户端占用），并且服务器
lease
文件中显示原来的租约还存在，服
务器就释
放这个租约，事实上，此时是客户端发送的
DHCPDISCOVER
< br>信息，
它已经证明客户端实际并没有使用这个租约。
如果
没有找到存在的租约，
或者客
户端被强迫接收一个已经存在的租
约，
那么服务器就会查找客户端所在网段的地
址池，
找一个允许客户端使用而又没有使用的地址，
它会按顺序遍历每个地址池<
/p>
(
所有地址池外的“范围”
range<
/p>
定义语句都组成一个没有允许列表的单独的池
)
< br>。
如果地址池的允许列表允许客户端得到一个池中的地址，
这个地址池会被检查是
否有可用的地址，如果有，客户端将会得到这个地址；否则，会
检查下一个地址
池。
如果一直都没有找到可用的地址，
服务器就不发送回应。
如果找到一个地址，
这个
地址以前从未被任何客户端使用过，
这个地址将立即分配给这个客户，
< br>如果
这个地址曾经分配给另一个客户端，
服务器会尝试查
找一个从未分配的地址给客
户端。
DHCP
服务器使用哈希表
(hash
table)
来产生一组可用的
IP
地
址，这意味
着地址不以任何特定的顺序存放，这样也就不能预测
DHCP
服务器下一个要分
配的地址。前一个版本的
ISC DHCP
服务器使用降序来分配地址，现在不是了，
并且在这个版本里也没有办法配置服务器分发地址的顺序
(ISC DHCP 3)
。
防止
IP
地址冲突
DHCP
服务器在分配
IP
地址前检查它们是否被使用来防止冲突。
它通过
向准备分配的
IP
地址发送
ICMP Echo
请求信息来完成，
如果
1
秒内没有接收到
ICMP Echo r
eply
信息，
就假定这个地址是可用的。
这只对在
range
语句中指明的
租约，
并且租约被
DHCP
服务器认为
可用时有效。
例如，
DHCP
服务器或
者它的
热备机没有列出这个租约在使用中。如果收到
ICMP
Echo
回应，
DHCP
服务器
会假定出现了配置错误――
IP
地址被网络上
的主机使用了，然后它标记这个地
址为“废弃地址”，不再把它分配给客户端。如果
DHCP
客户端试图得到一个
地址，但是却
没有可用的地址，服务器会（随机）标记一个“废弃地址”为“可
用”，然后向这个地址
发送同样的
ICMP Echo
请求，如果没有得到
ICMP
Echo
reply
回应，这个地址就会分配给这个客户。<
/p>
如果要收回的第一个
IP
地址是可用的，<
/p>
DHCP
服务器不会去循环使用
“废弃地
址”
。
而且，当下一个客户的
DHCP
DISCOVER
信息到达时，它会用相同的方法开始一个新的分
配，并且尝试分配一个新的
IP
地址。
DHCP
失败恢复（热备机）
这个版本的
ISC DHCP
服务器支
持
DHCP
失败恢复协议，它在
中描述，这不是最终的协议文档，而且没有与其它产
品进行交互兼容性
操作，
这样，
你就不能假定产品适合标准。
如果你想使用这个
失败恢复协议，
一定要确定失败恢复的每
台机器都运行相同版本的
ISC
DHCP
服
务器。
失败恢复协议允许两台
DHCP
服务器
(
并
且不超过
2
台
)
共享一个通用
的地址池，
在任何指定的时间上每台服务器都有
池中一半的可分配地址，
如果一
台服务器失效了，
另一台服务器一旦查觉到两台服务器间的通讯丢失，
它将会继
续更新不在自己范围地址的租约，
并且分配不属于自己地址范围的地址。
在一台
服务器较长时间失效后，
另一台有效的
服务器将会要求分配另一台服务器管理的
地址，
并开始使用这些
地址。
这种状态是将服务器置于
PARTNER-
DOWN
（伙伴
机失效）状态。
可以使用命令
omshell
(1)
把服务器设置成
PARTNER-DOWN
状态。或者
设置成失效状态，
在租约文件中编辑最后
服务器
（
peer
）
< br>状态，
然后重启服务器，
如果用这种方法，一定要确定开
始状态的日期和时间留空。
failover peer
name state {
my state partner-
down;
peer state state at
date;
}
<
/p>
当失效的服务器启动完成并在线工作时，它应当自动侦测到它曾经掉线
并且会请求设置为
PARTNER-DOWN
状态的服务
器传送完整的更新数据，然后
两台服务器就又恢复到共同处理数据的状态。
有可能进入到一个危险的失败状态：如果你把一台服务器
< br>A
设置成
PARTNER-DOWN
状态，接着，另一台服务器
B
关机，当另一台服务器
B
恢复
时，
B
不知道
A
处于
PAR
TNER-DOWN
状态，此时
B
会分
配地址，这些地址中
部分是
A
正在分配
的，也就是说，一个地址可能分配给了两台不同的客户端，
这就造成了
< br>IP
地址冲突。因此，把一台服务器设置成
PARTNE
R-DOWN
状态，
一定确定另一台服务器不是自动重启的。
失败恢复协议定义了主服务器角色和次服务器角色，两着工作
有一些不
同，
大部分区别在与对方通讯的方法上。
这样，
一台服务器必须配置成主服务器，
而另一台服
务器必须配置成次服务器，它并不在意哪台机器失败恢复
（
FA
ILOVER STARTUP
）多少次。
当一个
服务器开始工作时，如果它还没有与它的失败恢复备机通讯，它
就必须先建立与失败恢复
备机建立通讯，
然后同步数据，
之后才能提供服务。
这
可能发生在你刚配置完你的
DHCP
服务器成为失败恢复备机中的一台时，或者
其中一台失败恢复伴侣服务器挂
掉，
并且丢失了它全部的数据。
初始化恢复的过
程设计要求确定伴侣服务器中的一台丢失了它的数据并且需要重新同步。
失效的
服务器在失效前分配的所有租约都将被认为有效，
当它启动完成
后，
它发现它没
有保存失败恢复数据，
它就会尝试与它的伴侣通讯。
当它们建立通讯后，
它会要
求伴侣服务器提供全部的租约数据库的拷贝，接着伴侣服务器发送完整的数据
< br>库，
发送完成后，
再发送一个信息，
表示传送完成，
失败的服务器接下来就等待，
直到
MCLT
信息到达，一旦
MCLT
到达，两台服务器就转换到正常状态操作。
这个等待时间由两台服务器设置的
MCLT
时长决定。
当一个
服务器从失效状态恢复后，
它的伴侣仍就保持
partner-
down
状态，
这表示它为所有客户端提供服务，
失效的服务器不会提供任何服务，
直到它转换
到正
常状态。
当两台服务器都发现它们从未与伴侣进行通讯，它们会都按照
前面描写
的过程进入恢复状态。这种情况下，直到
MCLT
过期，客户端才能得到
DHCP
服务。
配置失败恢复
为了配置失败恢复，需
要配置失败恢复协议的声明语句，并且在每个需
要失败恢复的地址池中配置推荐服务器。
在一个指定的网络中，
不需要为每个池
都配置失败恢复。
不能配置其中一个服务器在某个地址池上执行失败恢复，
而另
一个服务器不在这个地址池上执行失败恢复，
对
于一个指定的地址池，
是否执行
失败恢复的配置应该是相同的。
一个使用失败恢复的地址池的语句像下面的样
子：
pool {
failover peer
deny dynamic bootp clients;
pool specific parameters
};
动
态
BOOTP
租约不适合失败恢复，并且，如上，应该不允许失
败恢复的
地址池中有
BOOTP
客户。
服务器当前对配置文件只做很少的检查，因此，如果你配置有错，服务
器就会表现的很奇怪。
我想推荐你要么就做失败恢复，
要么就
别做，
不要在服务
器上混合做。
而且，
为两台服务器使用相同的主配置文件，
引用各自使用自己独
立的失败恢复相关的文件。这会帮助减少很多配置错误。
随着使
用的增加，失败恢复服务器的问题会变得越来越少。一个基本的
主服务器的
文件如下
failover peer
primary;
address
port 519;
peer address
peer port 520;
max-response-delay 60;
max-unacked-updates
10;
mclt
3600;
split 128;
load balance max seconds 3;
}
include
上面用到的语句声明意义如下：
primary
、
secondary
主、次服务器声明语句：
[
primary | secondary ];
它决定服务器的角色是主还是次，描述在前面
DHCP
FAILOVER
部
分。
address
语句
address address;
address
语句声明了服务器应该侦听或者连接的失败恢
复伴侣的
IP
地址或域名，同时也是
D
HCP
失败恢复协议服务器的标识。因为这个值用来标
识
DHCP
服务器在失败恢复伙伴中的地位，它不能被省略。
（这里应该是本机的
IP
地址或域名，
因为下面的
peer address
语句里面言
定义的是对端的
IP
地址或域
名，如果
按照字面的解释，这两个语句实际是冲突的，再看上面的例子，也应该
是本机的
IP
或域名，需要实验确定一下）
peer
address
语句
peer address
address;
表示失败恢复伴侣的
IP
地址或域名。
port
语句
port port-number;
本机监
听的
TCP
端口号，用来监听伴侣服务器的信息。当前这个选<
/p>
项不能被省略，因为失败恢复协议还没有保留的
TCP
端口号。
peer port
语句
peer port port-number;
指定要
连接的伴侣服务器的
TCP
端口号。
当
前这个选项不能被省略，
因为失败恢复协议还没有保留的
TCP
端口号。
它可以和
port
语句的端口号是一
个端口号。
max-response-delay
最大回应延时语句
max-response-
delay seconds;
最大回应延时语句说明多少秒后
DH
CP
服务器没有收到伴侣的信息，
它会认为伴侣已经失效。
这个值应该足够小，
如果一个短暂的网络失效打断伴侣
之间的连接不会影响服务器间的通讯太长时间，
但是也要足够大，
让服务器可以
建立中断的连接。这个参数必须指定。
（这里的解释也有问题，可以按例子来设
置，具体可能会依靠环境作优化）
max-unacked-
updates
语句
max-unacked-
updates count;
max-unacked-updates
语句告诉
DHCP
服务器在接收到从伴侣服务器
收到
BNDACK
信息之前可以发送多少个<
/p>
BNDUPD
信息。我没有足够的操作经
验来说明这个值多大为好，但是
10
看起来能工作，这个值必须
指定。
mclt
语句
mclt seconds;
mclt
语句定义了客户端最大引导时间（
Maximum
Client Lead Time
）
，
它一定要在主服务器上指定，
不需要在次服务器上指定。
这是
伴侣服务器双方不
通讯而分配的租约更新的时长。设置的越长，运行的服务器恢复转到<
/p>
PARTNER-DOWN
的时间就越长
;
设置的越短，服务器不能通讯时的负载就越
大。设置为
3600
或许比较好，但是我们并没有真正实际的经验。
split
语句
split index;
split
语句指定主、次服务器之间的负载平衡，当一个客
户端发送一
个
DHCP
请求，
DHCP
服务器按哈希算法为客户机设定地址，
如果哈希算法得出
的值小于分隔值，主服务器应答，如果值大于或等于分隔值，次服务器
应答。唯
一有意义的值是
128
，并且
只能配置在主服务器上。
hba
语句
hba colon-
separated-hex-list;
hba
语句指定主次服务器之间的分隔作为位图而不是中断（
as a
bitmap rather than a
cutoff
）
,
这理论上允许了更
精细的控制。在实践中，一般不
需要如此精细的控制。一个
hb
a
语句的例子如下：
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 <
/p>
或者
hba
定义，不能两个都
有。大多数情况下，更精细的控制
hba
并不需
要，一般都使用
split
，很少使用
hba
。
load balance max
seconds
语句
load balance
max seconds seconds;
这个语句允许配置一个界限，
过了这个界限后负载平衡就被关闭。
这
个界
限基于客户端发送
DHCPDISCOVER
或者
DHCPREQUEST
之后的秒数，
并且需要客户端装配
secs<
/p>
字段――幸运的是，大多数客户端都这样。我们推荐
设置这个值为
3
或
5<
/p>
。这个语句的作用是：如果一个失败恢复的伴侣进入一种
状态，<
/p>
它对另一个伴侣有应答，
但对客户端没有应答，
< br>正常的一台将会接管另一
台的负载。
客户端分类
(class)
客户端
可以被分成一些类，并且按照所属的类被区别对待，这个区分可
以由
conditional
语句完成，或者由
class<
/p>
语句中的
match
语句完成。可以指定
某
个指定的类或子类在同一时间内获得租约的全部客户端的限制数目，
< br>也可以基于
客户端发送包的内容来自动指定子类。
基于条
件的客户端分类，可以在
class
语句中指定一个
matching
表达式：
class
match if substring (option dhcp-client-
identifier, 1, 3) =
}
注意，
不管使用
match
语句或者使用
add
语句
(<
/p>
或者两者都使用
)
来给客户
端分类，
都必须首先声明用到的客户端的类。
如果没
有
match
语句也没有
in-sco
pe
语句，类声明语句就会是这个样子：
（这里有个矛盾，前面
应该是
in-scope
，而
不是
add
）
class
}
子类
(SUBCLASSES)
除了类
，
也可能会用到子类
subclass
。
子类是与通常的类有相同名字，
但
是
又有特定的可以用哈希算法快速匹配的附加条件
(submatch)
< br>。这本质上是速度
问题――一个有五个
match
语句的类和一个类有五个子类的主要区别是使用子
类速度更快，子类的
工作方式如下：
class
match pick-
first-value (option dhcp-client-identifier,
hardware);
}
class
match pick-first-value (option dhcp-
client-identifier, hardware);
}
subclass
subclass
subclass
subnet 10.0.0.0 netmask
255.255.255.0 {
pool {
allow members
of
range 10.0.0.11 10.0.0.50;
}
pool {
allow members
of
range 10.0.0.51 10.0.0.100;
}
}
在子类声明语句中跟在类名后的数据是一个固定值，用来匹配类中的
match
语句。当类匹配完成后，服务器会计算
match<
/p>
语句，然后在哈希表中查找
结果。如果找到一个匹配，客户端就被
认为是一个这个类和这个子类的成员。
子类
Su
bclasses
可以有也可以没有
scope
语句，在上面的例子中，使用
子类的单一目的就是允许一些客户端使用其中一个
地址池，
而其它一些客户端使
用别的地址池，所以这些子类没有
使用
scope
语句。如果使用子类的部分目标是
为部分客户端定义不同的参数，那就可能定义子类时使用
scope
语句了。在上面
的例子里，如果你的一个客户需要一些配置参数，而它客
户则不需要这些参数，
可以为这个客户使用下面的子类声明：
subclass
option root-path
filename
}
在这个例子里，我们使用子类来控制为每个客户进行地址分配。然而也
< br>可能使用子类不指明客户端，例如，使用值
vendor-class-
identifier
选项来确定给
vendor-
encapsulated-
options
选项发送什么值。在
dhcp-
options(5)
手册中的
VENDOR
ENCAPSULATED OPTIONS
里有一个例子。
动态地址分配时类的限制
(PER-CLASS LIMITS
ON DYNAMIC ADDRESS
ALLOCATION)
可以给某个类指定一个可以分配的
客户端的数目的最大值限制，它的影
响是一个新的客户端可能很难得到一个地址。
一旦类的这个限制数达到，
新客户
端得到地址
的唯一可能就是原来的某个客户端放弃了租约，
不管是租约过期还是
发送
DHCPRELEASE
包，有租约数限制的类都像下
面一样：
class
lease limit 4;
}
这将使这个类同一时间最多只能有
4
个成员
。
自动产生子类的类
SPAWNING CLASSES
可以定义一个
spawning
class
，
spawning c
lass
是一个根据客户端发送内
容自动产生子类的类。
Spawning class
建立的原因是为了使建立租约限制的类
不
工作。假定使用在
cable-
modem
环境中，
ISP
想为一个点的客户提供不只一个
IP
地址，但不
希望这个客户建立自己的子网，或者给这个客户连接的网段里无
限制的
< br>IP
地址数，很多
cable modem
的头端系统可以配置一个
DHCP
的中继代
理信息，它可以把客户端的
DHCP
请求发送到
DHCP
服务器，这些典型系统都
会使
用虚电路号
(circuit ID)
或者远程
ID
号
(remote ID)
来确定用户位置。
为了利用
这些，可以如下的类定义语句：<
/p>
class
spawn with option
t-id;
lease limit 4;
}
现在，
一旦用户节点的请求到达后，
cir
cuit ID
选项将会在
hash
表
中检查。
如果发现其中一个子类匹配了这个电路号
(circu
it ID)
，这个客户将会被归入这个
子类并按这个子类成员
对待。
如果没有发现匹配，
一个新的类将会建立并记录在
文件中，这个客户会被归入这个新类中。客户端被归类后，它将按<
/p>
照类的成员对待，在这种情况下，按类成员对待每个点最多
4
个成员。
使用子类生成机制并不仅限于中继代理选项，使用这个例子只
是因为它
容易理解。
组合匹配等
(COMBINING MATCH, MATCH
IF AND SPAWN WITH)
有些情况下，使用一个表达式指定一个客户端到一个类，然后
用第二个
表达式把它放到一个子类中是很有用的。这可以由组合
match
if
和
spawn
with
语句完成，或者由
match
if
和
match
完成，例如：
class
match if option dhcp-
vendor-identifier =
spawn with option t-id;
lease limit 4;
}
class
match if opton
dhcp-vendor-identifier =
spawn with option t-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<
/p>
交互模式和
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-hos
tname
配置选项，如果有，就用它
;
如果没有找到
这个选项，服务器在
FQDN
< br>选项中查找一个有效的主机名，把它发送给客户端。
如果找到一个，
就用它，
否则如果客户端发送了
host-name
选项，
就用它。
否则，
如果有一个
host
语句对应这个客户端，语句中的
名称就会被用上。如果上面所
有的都没有，服务器不会发送给客户端
hostname
，也不能进行
DNS
更新。
域名严格基于服务器的配置，而不基于客户端发送的内容。首
先，如果
有一个
ddns-domainname
配置选项，就用它
;
否则，如果有一个
domain-name
选
项配置，就用它。如
果两个都没有，服务器就不进行
DNS
更新。
< br>
正如我们描述的，客户端有完全资格的域名用来作为
”A”
记录中的名字
存储。
A
记录包含了租约中客户端被分配的
IP
地址。
< br>如果
DNS
服务器中已经有
了一
个相同名字的
A
记录，就不会对
A
或
PTR
记录更新了，这会阻止一个客户<
/p>
端宣称它的域名是某些网络的服务器。例如，如果你有一个文件服务器叫
< br>
，并且一个客户端宣称它的主机名是
，这时
DNS
就不会为
这个用户更
新
DNS
记录，同时会在日志文件中记录这个错误。
如果一个
A
记录更新成功，那么对应
的
PTR
记录也会被更新，指向
A
记录。这个更新是无条件的，即使有相同名字的另一个
PTR
记录存在。既然
IP
地址已经被
DHCP
服务器分配了，它就应该是安全的。
请注意
当前我们假定客户端只有一个网络接口，如果客户端有两个网络
接口，它会得到不希望得
到的结果。现在这还是个
bug
，下一个版本也许会修复
它。启用
one-lease-per-client
参数是有用的，那样漫游进来的客户就不会触发相
同的地址分配。
DHCP
协议通常包含
4
个包交换，
首先客户端发送
DHCPDISCOV
ER
信
息，接着服务器回应一个
DHC
POFFER
信息，然后客户端发送一个
DHCPREQUES
T
信息，服务器再回复一个
DHCPACK
信息。在当前的版本中，
服务器在收到一个
DHCPREQ
UEST
信息后会要求
DNS
更新，这
个动作在发送
DHCPACK
之前。
如
果它前面没有为客户端发送地址，
它只发送
DNS
更新信息，
为了最小化
DHCP
服务器的压力，如果它还没有完成为客户端发送地址时，它
只发送
< br>DNS
更新信息。
当客户
端的租约过期时，
DHCP
服务器
(<
/p>
如果它正好在操作，或者马上就
要被操作
)
将会从
DNS
数据库中移去客户端的
A
和
PTR
记录。
如果客户端通过
发送
DHCPRELEASE
信息释放了它的租约，服务器将会移去
A
和<
/p>
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
记录。例如，假定客户端是来自
域的一个访问者
，它的主
机名是
，服务器管理的是
域，
DHCP
客户
端发送的
FQDN
选项是
，它也要求更新自己的
A
记录，
DHCP
服务器因此不
去试图为这个客户端设置
A
记录，
但是要为这个
I
P
地址设置
PTR
记录，
它可以
自行更新自己的
A
记
录，假定
的
DNS
服务器允许这样做。
如果服务器配置不允许客户端更新，或者客户端不想自己更新
，服务器
就会简单的选择一个名字发送给客户端，
可能使用客户
端自己提供的主机名
(
在
这个例子中是
，它将会把自己的域名传送给客户端
，就像在
ad-hoc
update
更新中一样。它会更新
A
和
PTR
记录，使用它为客户端选择的名字。如
果客户端发送了完全合格的<
/p>
FQDN
选项，服务器只会选用最左边部分，前面的
例子中，
而不是
。
两种更新模式的另一种不同是，在
interim
模式中，有一种方法允许不只
一个
DHCP
服务器更新
DNS
数据库而不会偶然删除掉不
该删掉的
A
记录，
也不
会添加应该添加的记录失败，它工作的方式如下：
当
DHCP
服务器发布一个客户租约时，它建立一个文本串，这个
文本串是一个
MD5
哈希处理的
DHC
P
客户端鉴定
(
参见
< br>draft-ietf-dnsext-dhcid-rr-??.txt for
details)
，这个更新给
A
记录增加了服务器选择名字和一个包含哈希鉴定字符串
的
TXT
记录
(hashid)
，如果这个更新成功，服务器的工作完成。如果因为
A
记
录已经存在而导致更新失败，
DHCP
服务器会尝试添加
A
记录，前提是必须有
< br>一个和新的
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
contents must be equal to hashid.
如果这次更新成功，
客户端就会拥有它的
A
和
P
TR
记录，如果失败，客户端已经被分配的名字已经被使用了，不能被再用了，
此时，
DHCP
服务器放弃进行为这个客户所做
的
DNS
更新并为这个客户选择一
个新
的名称。
interim DNS
更新方案被叫做
interim
有两
个原因：
一是它并不完全遵守
草案，
当
前的草案使用新
DHCID Rrtype
，
< br>但是现在不能用，
interim DNS
更新使
用
TXT record
替代。而且，现存的
ddns
草案要注
DHCP
服务器在
PTR
记录上
发送
DHCID
RR
，而
interim
更新方案不这样做，在我们的观点中，和作者一
起工作的人都希望在下一个
草案中去掉这些东西，
或者说明为什么这样做是有用
的。
除了这些不同，
服务器的更新并不很强势。
因为每个
DNS
更新包含一个
到
DNS
服务器的数据往返，
即使它不真的修改
DNS
数据库，
这样的更新也消耗
资源，于是
DHCP
服务器不管它是否原来
更新过记录
(
这个信息保存在
leas
e
中
)
都不再尝试更新记录，而是认为
记录已经更新。
这会导致一种情况，
DHCP
服务器添加了一个记录，而这条记录又被其
它机制删除掉了，但是
DHCP
服务器再也不去更新
DNS
，因为它认为它已经更
新过了。
这种情况下，
可以通过移去租约文件中的相关内容来操作，
一旦操作完
成，下次客户端更新租约时就会
DNS
就会被
更新。
DNS
动态更新安全
当设置
DNS
服务器允许通过
DHCP
动态更新后，
就可能出现未授权的更
< br>新。
为了避免出现这种情况，
应该使用
< br>TSIG
签名――使用共享密钥进行密码签
名的方法。
只要你保护好这个密钥，你的更新就应该是安全的。注意，
DHCP
协
议自身没有提供安全，同时，客户端可以提供信息到
DH
CP
服务器，而
DHCP
服务器使用这
个信息进行更新，如同前面描述的一样。
DNS
服务器必须配置
成
允许
DHCP
服务器要更新的区域更
新。例如，假定
域中的客户被
分配地
址是
10.10.17.0/24
子网，
在这里，
会需要一个
key
语句来确
定将要使用的
TSIG
密钥，同时还要两个区域语句（
zone
）
，一个是
A
记录的，一个是
PTR
记
录的，对于
ISC
BIND
，会像这样：
key
DHCP_UPDATER {
algorithm hmac-md5;
secret
pRP5FapFoJ95JEL06sv4PQ==;
};
zone
type master;
file
allow-update { key DHCP_UPDATER;
};
};
zone
type master;
file
allow-update { key DHCP_UPDATER;
};
};
同时也必须配置
< br>DHCP
服务器来更新这个区域，可能需要添加如下的内
容到
文件中：