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