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的信息，参见随机文档。
[版权声明]BSD爱好者乐园站内文章，如来源不是互联网，则均系原创或翻译之作，可随意转载，或以此为基础进行演译，但务必以链接形式注明原始出处和作者信息，否则属于侵权行为。另对本站转载他处文章，俱有说明，如有侵权请联系本人，本人将会在第一时间删除侵权文章。
TAG: 翻译