动态更新dns原理介绍

 动态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就会被更新。