本节书摘来自异步社区《DNS与BIND（第5版）》一书中的第10章，第10.2节,作者： 【美】Joseph Davies 更多章节内容可以访问云栖社区“异步社区”公众号查看。
10.2 DNS动态更新
Internet（即通常使用TCP/IP协议的网络）如今变得愈加动态化。许多大型企业使用DHCP动态分配IP地址。几乎所有的ISP都使用DHCP为其拨号及使用线缆调制解调器（cable modem）的用户分配IP地址。为适应这种变化，DNS需要提供动态增加和删除记录的功能。RFC 2136描述了这种机制，称为DNS动态更新。
BIND 8和9支持RFC 2136提出的动态更新功能。此功能允许经过授权的更新者（updater），在区域中的权威名称服务器上增加和删除资源记录。更新者可以通过检索区域的NS记录，找到该区域的权威名称服务器。如果名称服务器收到一个经过授权的更新消息，而它不是该区域的primary master，那么它会将该更新消息向上转发给自己的master服务器，这个过程称为更新转发（update forwarding）。如果接下来的这个名称服务器是该区域的slave，那么它仍然会将更新消息向上转发。毕竟，在一个区域中，只有primary名称服务器才拥有一个可更改的区域数据副本。所有slave，不管是直接或间接（通过其他slave），都是从primary取得它们的区域数据副本。一旦primary完成动态更新并且变更了区域数据后，slave就能通过区域传输得到一个新的副本。
动态更新不仅能完成简单的增删记录操作。更新者还能增加或删除个别的资源记录，删除RRsets（由相同的域名、类和类型组成的资源记录集合，例如www.movie.edu的所有IP地址），甚至删除与指定域名相关的所有记录。还可以将区域中的特定记录是否存在，作为更新是否生效的先决条件。例如，如下更新：
只有在域名armageddon.fx.movie.edu目前没有被使用，或者armageddon.fx.movie.edu目前没有地址记录的情况下，才会增加该地址记录。
提示
关于更新转发，有一点要注意：在版之前，BIND名称服务器并没有实现更新转发。因此，当使用低于9.1.0版的BIND名称服务器时，确保将更新直接发送至所要更新区域的primary名称服务器是非常重要的。要做到这一点，请确定该区域SOA记录的MNAME字段中，列出了该区域的primary名称服务器。大多数动态更新程序使用MNAME字段作为提示，来找到应该将更新发送至哪个权威名称服务器。
通常，会通过类似DHCP服务器的程序来使用动态更新功能。DHCP服务器会自动给计算机分配IP地址，并且记录分配的结果：名称到地址以及地址到名称的解析关系。一些使用动态更新功能的程序，会通过新的ns_update()解析程序创建更新消息，并把它们发送给该域名所在区域的权威服务器。
不过，也可以使用命令行程序nsupdate（此程序包含在标准的BIND发行套件中），来手动创建更新消息。nsupdate一次读取一行命令，并将其转换成一条更新消息。这些命令可以来自于标准输入（默认）或者一个文件（其文件名必须作为nsupdate的参数）。对于没有用空行隔开的命令，只要还有空间，就会被合并成一条更新消息。
nsupdate可以识别以下命令。
prereq yxrrset domain name type [rdata]
执行后续update命令所指定的更新之前，必须满足一个先决条件：domain name所拥有的type类型的RRset必须存在。如果指定了rdata，则它也必须存在。
prereq nxrrset domain name type
执行指定的更新之前，必须满足一个先决条件：domain name所拥有的type类型的RRset必须不存在。
prereq yxdomain domain name
执行更新之前，必须满足一个先决条件：指定的domain name必须存在。
prereq nxdomain domain name
执行更新之前，必须满足一个先决条件：指定的domain name必须不存在。
update delete domain name [type] [rdata]
删除指定的域名。如果指定了type则删除指定的RRset，如果同时指定了rdata，则删除匹配domain name、type及rdata的记录。
update add domain name ttl [class] type rdata
在区域中增加指定的记录。注意，除了type和rdata之外，还必须包含ttl（生存周期）。但是class（类）是可选的，其默认值为IN。
所以，下列命令：
就是要求服务器只在该域名不存在时才为mib.fx.movie.edu增加一个地址。需要注意的是，BIND 8在版之前，nsupdate使用一个空行作为发送更新的暗示，而不是使用send命令。
下面的命令会检查mib.fx.movie.edu是否已经存在MX记录，如果存在就将其删除，并且就地增加两条记录：
像查询一样，处理动态更新的名称服务器使用DNS消息来回应更新者。这些消息指出更新是否成功，如果失败，原因为何。导致更新失败的原因很多：例如，因为名称服务器实际上并不是所要更新区域中的权威服务器，因为不满足先决条件，或者因为更新者没有经过授权。
在进行动态更新时也存在一些限制：无法将整个区域完全删除（可以删除除了SOA记录和NS记录以外的所有记录），并且无法增加新的区域。
10.2.1 动态更新和序号
当名称服务器处理动态更新时，它会变更区域，而且必须增加区域的序号，以便通知区域中的slave，区域已经变更。这个过程是自动完成的。不过，名称服务器并不需要在每次动态更新时都增加序号。
在BIND 8中，名称服务器会延迟5分钟或者累计100次更新（以先达到者为准），才增加区域的序号。之所以这样做，主要是因为名称服务器处理动态更新的时间和传输区域数据时间相差太悬殊：对于大型区域而言，完成区域数据传输将会很费时间。当名称服务器最后增加区域序号时，它会发送一个NOTIFY通告（本章稍后会加以说明），通知区域中的slave序号已经改变。
在BIND 9中，名称服务器每处理一条动态更新就会增加序号一次。
10.2.2 动态更新和区域数据文件
由于动态更新会对区域数据造成永久性改变，因此必须将其保存在磁盘上。但是，如果每次对区域进行增删操作都改写区域数据文件，可能会给名称服务器带来沉重的负担。名称服务器每秒收到数十或数百条动态更新是很有可能的，可想而知改写区域数据文件要浪费多少时间。
因此，当BIND 8和9名称服务器接收到动态更新时，它们只在日志文件中附加一个简短的更新记录1。当然，更新会立即在内存中的区域数据文件副本中生效。名称服务器会等待指定的时间间隔（通常以小时计）后，才将整个区域数据写进磁盘。BIND 8名称服务器随后会删除日志文件，因为该文件已经没有用了。（这时，内存中的区域数据文件副本和磁盘上的区域数据文件完全一致。）然而BIND 9名称服务器会保留日志文件，因为它还被用到增量区域传输中，本章稍后会加以说明。（BIND 8名称服务器将增量区域传输信息保存在另一个文件中。）
在BIND 8名称服务器上，日志文件名是由区域数据文件名加上.log组成。在BIND 9名称服务器上，日志文件也被称为journal file，其文件名是由区域数据文件名加上.__jnl组成。所以当开始使用动态更新的功能时，如果看到这些文件出现在区域数据文件旁时不必惊慌失措：这是完全正常的。
在BIND 8名称服务器上，正常退出名称服务器或者每隔一个或数个小时，日志文件就会消失（如果名称服务器接收到很多更新消息，那日志文件很快就会再度重现）。在BIND 9名称服务器上，日志文件会一直存在。当名称服务器启动时，如果存在日志文件，则无论是BIND 8或9，都会将其中有更改的记录加入到区域数据中。
BIND 8的日志文件具有可读性，其包含的内容如下所示：
遗憾的是，BIND 9的日志文件不具有可读性。当然，它们本来也不是用来给人读的。
10.2.3 使用访问控制列表限制更新
动态更新显然赋予了更新者对一个区域可怕的控制力，因此必须对其进行严格限制。默认情况下，BIND 8和9名称服务器都不允许对权威区域进行动态更新。如果要在区域中使用动态更新，则必须在该区域的zone语句中增加allow-update或update-policy子语句。
allow-update使用一个地址匹配列表作为参数。只有和该列表匹配的地址才被允许对区域进行更新。谨慎起见，应尽可能严格地限制地址匹配列表。
经过allow-update的授权，更新者可以对区域进行任意变更：删除任意记录（SOA记录除外），或者增加任意记录。
10.2.4 经TSIG签名的更新
BIND 及其后续版本的slave名称服务器能够转发更新，那么应该如何使用基于IP地址的访问控制列表呢？如果primary名称服务器允许来自slave所在的IP地址进行更新，则只要是由slave转发的更新，不管原发送者是谁，一律都会被接受。这不是个好现象2。
首先，可以控制谁可以转发更新。allow-update-forwarding子语句使用一个地址匹配列表作为参数。只有和该列表匹配的IP地址发送的更新，才允许进行转发。下面的zone语句表示仅转发来自特效系（Special Effects Department）所在子网的更新：
其次，在使用更新转发功能时，还应该同时采用经事务签名（transaction signatures，简称TSIG）的动态更新。本书将在第11章深入探讨TSIG。目前只需要了解，经TSIG签名的动态更新，具有签名者的加密签名。如果这些更新被转发，则其附带的签名也随之被转发。只要验证签名，就能得知签署该更新的密钥名称。密钥的名称类似于域名，而且通常就是密钥所在主机的域名。
BIND 8.2及其后续版本的名称服务器，可以在一个地址匹配列表中包含一个或多个TSIG密钥的名称：
根据上述配置，更新者只要能用TSIG密钥dhcp-server.fx.movie.edu签名一个更新，就能对fx.movie.edu区域进行任意变更。可惜无法进一步限制拥有TSIG密钥的更新者的源IP地址。
BIND 9提供了比allow-update更细致的访问控制机制，该机制也是基于TSIG签名的。该机制使用了update-policy这个新的zone子语句。update-policy允许指定哪些密钥允许更新区域中的哪些记录。由于slave只转发更新，所以该机制仅对primary名称服务器有意义。
更新由以下方式指定：用来签名的密钥名称，加上域名，再加上打算更新的记录类型。update-policy的语法如下所示：
grant和deny显然表示：允许或不允许指定的动态更新。identity指的是用来对更新签名的TSIG密钥名称。nametype是以下选项中的一个。
name
比对所更新的域名是否和string字段所指定的字符串相同。
subdomain
比对所更新的域名是否是string字段所指定的字符串的子域。（当然该域名必须仍然在此区域中。）
wildcard
比对所更新的域名是否和string字段所指定的通配符表达式（wildcard expression）相符。
self
比对所更新的域名是否和identity（而非string！）字段中的名称相同——也就是说，所更新的域名与用来签名更新的密钥是相同的。如果nametype字段配置为self，便会忽略string字段。不过，当把nametype字段配置为self时，即使看起来多余（马上会在示例中看到），仍然必须包含string字段。
string字段在本质上是一个与nametype字段相对应的域名。例如，如果将nametype字段配置为wildcard，则string字段中就应该包含一个通配符标签（wildcard label）。
types字段是可选的，可以包含任一有效的记录类型（或者多个以空格分隔的记录类型），但不包括NSEC。（ANY是个方便的简写，代表除了NSEC之外的所有类型。）如果不配置types字段，则匹配除了SOA、NS、RRSIG以及NSEC之外的所有类型。
提示
注意update-policy规则的匹配优先级：在update-policy子语句中，最先匹配（而不是最后匹配）的规则会应用于动态更新。
因此，如果主机mummy.fx.movie.edu使用一个名为mummy.fx.movie.edu的密钥对它的动态更新进行签名，则可以通过如下配置来限制mummy.fx.movie.edu只能更新自己的记录：
或者通过如下配置来限制它只能更新自己的地址记录：
通常，可以通过如下配置来限制所有客户端只能更新它们自己的地址记录：
可以通过如下配置，允许DHCP服务器使用dhcp-server.fx.movie.edu作为密钥，来更新隶属于fx.movie.edu域名下的任意A、TXT及PTR记录。
如下两个例子：
和
之间的区别是：前者允许更新者使用密钥dhcp-server.fx.movie.edu来更新隶属于fx.movie.edu的记录（例如，该区域的NS记录），而后者不行。因为DHCP服务器并不负责修改隶属于该区域域名的任何记录，所以后者的配置更加安全。
下面的例子更加复杂：如果要允许所有客户端修改除SRV之外的任意记录（这些记录隶属于与密钥同名的域名），但是还允许matrix.fx.movie.edu更新与Active Directory（分别位于_udp.fx.movie.edu、_tcp.fx.movie.edu、_sites.fx.movie.edu及_msdcs.fx.movie.edu子域）相关的SRV、A及CNAME记录，可以这样配置：
因为update-policy子语句中的规则是按照出现顺序进行匹配的，所以虽然客户端不能更新它们的SRV记录，但是可以更新它们所拥有的其他任意记录。
如果想使用经TSIG签名的动态更新，却不想安装能够发送此更新的软件，那么可以使用较新版本的nsupdate；相关内容请参阅本书第11章。
