RFC2136(DNS动态更新)
Dynamic Updates in the Domain Name System (DNS UPDATE)
域名系统中的动态更新
1 - Definitions(定义)
This document intentionally gives more definition to the roles of “Master,” “Slave,” and “Primary Master” servers, and their enumeration in NS RRs, and the SOA MNAME field. In that sense, the following server type definitions can be considered an addendum to [RFC1035], and are intended to be consistent with [RFC1996]:
本文件有意更详细地定义了“主服务器”、“从服务器”和“主要主服务器”的角色，以及它们在 NS 资源记录和 SOA MNAME 字段中的列举。在这个意义上，以下的服务器类型定义可以被视为 [RFC1035] 的补充，并且旨在与 [RFC1996] 保持一致：
Slave an authoritative server that uses AXFR or IXFR to
retrieve the zone and is named in the zone's NS
RRset.
一个权威服务器，使用 AXFR 或 IXFR 来检索区域，并在该区域的 NS 资源记录集中被命名。
Master an authoritative server configured to be the
source of AXFR or IXFR data for one or more slave
servers.
一个权威服务器，被配置为一个或多个从服务器提供 AXFR 或 IXFR 数据的来源。
Primary Master master server at the root of the AXFR/IXFR
dependency graph. The primary master is named in
the zone's SOA MNAME field and optionally by an NS
RR. There is by definition only one primary master
server per zone.
处于 AXFR/IXFR 依赖关系图根部的主服务器。主要主服务器在区域的 SOA MNAME 字段中被命名，并且可选地在 NS 资源记录中命名。根据定义，每个区域只有一个主要主服务器。
A domain name identifies a node within the domain name space tree structure. Each node has a set (possibly empty) of Resource Records (RRs). All RRs having the same NAME, CLASS and TYPE are called a Resource Record Set (RRset).
域名标识域名空间树结构中的一个节点。每个节点都有一组（可能为空）的资源记录（RRs）。所有具有相同 NAME、CLASS 和 TYPE 的资源记录称为资源记录集（RRset）。
The pseudocode used in this document is for example purposes only. If it is found to disagree with the text, the text shall be considered authoritative. If the text is found to be ambiguous, the pseudocode can be used to help resolve the ambiguity.
本文档中使用的伪代码仅用于示例目的。如果发现其与正文不一致，应以正文为准。如果发现正文有歧义，可以使用伪代码来帮助解决歧义。
1.1 - Comparison Rules(比较规则)
- 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH and RDATA fields are equal. Note that the time-to-live (TTL) field is explicitly excluded from the comparison.
两个资源记录（RRs）如果它们的 NAME、CLASS、TYPE、RDLENGTH 和 RDATA 字段相等，则被认为是相等的。需要注意的是，比较中显式排除了生存时间（TTL）字段。
- 1.1.2. The rules for comparison of character strings in names are specified in [RFC1035 2.3.3].
在域名中的字符串的比较规则,在 [RFC1035 2.3.3] 中有详细规定。
- 1.1.3. Wildcarding is disabled. That is, a wildcard (““) in an update only matches a wildcard (““) in the zone, and vice versa.
通配符功能被禁用。也就是说，在更新中的通配符 (“”) 只能与区域中的通配符 (“”) 匹配，反之亦然。
- 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in the update, and will not otherwise be followed. All UPDATE operations are done on the basis of canonical names.
别名功能被禁用：区域中的 CNAME 只能与更新中的 CNAME 匹配，否则不会被跟随。所有更新操作都基于规范名称进行。
- 1.1.5. The following RR types cannot be appended to an RRset. If the following comparison rules are met, then an attempt to add the new RR will result in the replacement of the previous RR:
以下资源记录（RR）类型不能附加到一个 RRset。如果满足以下比较规则，那么尝试添加新的 RR 将会导致替换先前的 RR：
SOA compare only NAME, CLASS and TYPE -- it is not possible to
have more than one SOA per zone, even if any of the data
fields differ.
仅比较 NAME、CLASS 和 TYPE — 即使数据字段有任何差异，也不可能在一个区域中有多个 SOA 记录。
WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-- only one WKS RR is possible for this tuple, even if the
services masks differ.
仅比较 NAME、CLASS、TYPE、ADDRESS 和 PROTOCOL — 对于这个元组，即使服务掩码不同，也只可能有一个 WKS RR。
CNAME compare only NAME, CLASS, and TYPE -- it is not possible
to have more than one CNAME RR, even if their data fields
differ.
仅比较 NAME、CLASS 和 TYPE — 即使它们的数据字段不同，也不可能有多个 CNAME RR。
1.2 - Glue RRs(胶水 RR)
For the purpose of determining whether a domain name used in the UPDATE protocol is contained within a specified zone, a domain name is “in” a zone if it is owned by that zone’s domain name. See section 7.18 for details.
根据 UPDATE 协议确定一个域名是否包含在指定的区域中时，如果一个域名是由该区域的域名所有的，那么它就在该区域内。详细信息请参见第7.18节。
1.3 - New Assigned Numbers(新的分配号)
1 | |
2 - Update Message Format(更新消息格式)
The DNS Message Format is defined by [RFC1035 4.1]. Some extensions are necessary (for example, more error codes are possible under UPDATE than under QUERY) and some fields must be overloaded (see description of CLASS fields below).
DNS消息格式由[RFC1035 4.1]定义。某些扩展是必要的（例如，在更新操作中可能存在比查询操作更多的错误代码），并且某些字段必须被重载（参见下文中对CLASS字段的描述）。
The overall format of an UPDATE message is, following [ibid]:
更新消息的总体格式如下，遵循[RFC1035 4.1]的描述：
1 | |
The Header Section specifies that this message is an UPDATE, and describes the size of the other sections. The Zone Section names the zone that is to be updated by this message. The Prerequisite Section specifies the starting invariants (in terms of zone content) required for this update. The Update Section contains the edits to be made, and the Additional Data Section contains data which may be necessary to complete, but is not part of, this update.
Header 部分指定了这个消息是一个更新消息，并描述了其他部分的大小。Zone部分指定了将要被此消息更新的区域。Prerequisite 部分指定了此更新所需的起始不变量（以区域内容为基础）。Update 部分包含要进行的修改，Additional Data 部分包含可能需要的数据以完成这个更新，但不是这个更新的一部分。
2.1 - Transport Issues(传输问题)
An update transaction may be carried in a UDP datagram, if the request fits, or in a TCP connection (at the discretion of the requestor). When TCP is used, the message is in the format described in [RFC1035 4.2.2].
更新事务可以在UDP数据报中进行，如果请求适合的话，也可以在TCP连接中进行（由请求者决定）。当使用TCP时，消息的格式如[RFC1035 4.2.2]中描述的那样。
2.2 - Message Header(消息头)
The header of the DNS Message Format is defined by [RFC 1035 4.1]. Not all opcodes define the same set of flag bits, though as a practical matter most of the bits defined for QUERY (in [ibid]) are identically defined by the other opcodes. UPDATE uses only one flag bit (QR).
DNS消息格式的头部由[RFC 1035 4.1]定义。并非所有操作码(opcodes)都定义相同的一组标志位，但实际上，QUERY 定义的大多数位（在 [ibid] 中）与其他操作码的定义相同。UPDATE仅使用一个标志位（QR）。
The DNS Message Format specifies record counts for its four sections (Question, Answer, Authority, and Additional). UPDATE uses the same fields, and the same section formats, but the naming and use of these sections differs as shown in the following modified header, after [RFC1035 4.1.1]:
DNS消息格式规定了其四个部分（Question、Answer、Authority、Additional）的记录计数。UPDATE使用相同的字段和相同的部分格式，但这些部分的命名和使用有所不同，如在修改后的标题中所示，参考[RFC1035 4.1.1]。
1 | |
These fields are used as follows:
这些字段的使用方法如下：
1 | |
2.3 - Zone Section(zone 段)
The Zone Section has the same format as that specified in [RFC1035 4.1.2], with the fields redefined as follows:
Zone部分具有与[RFC1035 4.1.2]中指定的格式相同的格式，但字段重新定义如下：
1 | |
UPDATE uses this section to denote the zone of the records being updated. All records to be updated must be in the same zone, and therefore the Zone Section is allowed to contain exactly one record. The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is the zone’s class.
UPDATE 使用此部分来表示正在更新的记录的区域。所有要更新的记录必须位于同一区域，因此区域部分只能包含一条记录。ZNAME 是区域名称，ZTYPE 必须是 SOA，ZCLASS 是区域的类。
2.4 - Prerequisite Section(Prerequisite 段)
This section contains a set of RRset prerequisites which must be satisfied at the time the UPDATE packet is received by the primary master server. The format of this section is as specified by [RFC1035 4.1.3]. There are five possible sets of semantics that can be expressed here, summarized as follows and then explained below.
此节包含一组 RRset 先决(prerequisites)条件，这些先决条件在主服务器收到 UPDATE 数据包时必须得到满足。此节的格式由 [RFC1035 4.1.3] 指定。此处可以表达五种可能的语义集，总结如下，然后在下面进行解释。
1 | |
The syntax of these is as follows:
它们的语法如下：
2.4.1 - RRset Exists (Value Independent) (RRset 存在(与值无关))
At least one RR with a specified NAME and TYPE (in the zone and class specified in the Zone Section) must exist.
必须存在至少一个具有指定 NAME 和 TYPE 的 RR（在区域部分中指定的区域和类中）。
For this prerequisite, a requestor adds to the section a single RR whose NAME and TYPE are equal to that of the zone RRset whose existence is required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified as ANY to differentiate this condition from that of an actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TTL is specified as zero (0).
对于此先决条件，请求者向部分添加一个 RR，其 NAME 和 TYPE 等于需要存在的区域 RRset。RDLENGTH 为零，因此 RDATA 为空。必须将 CLASS 指定为 ANY，以将此条件与 RDLENGTH 自然为零 (0)（例如，NULL）的实际 RR 区分开来。TTL 指定为零 (0)。
2.4.2 - RRset Exists (Value Dependent)(RRset 存在(依赖于值))
A set of RRs with a specified NAME and TYPE exists and has the same members with the same RDATAs as the RRset specified here in this section. While RRset ordering is undefined and therefore not significant to this comparison, the sets be identical in their extent.
存在一组具有指定 NAME 和 TYPE 的 RR，并且它们具有与本节中指定的 RRset 相同的成员和相同的 RDATA。虽然 RRset 排序未定义，因此对于此比较并不重要，但这些集合的范围必须相同。
For this prerequisite, a requestor adds to the section an entire RRset whose preexistence is required. NAME and TYPE are that of the RRset being denoted. CLASS is that of the zone. TTL must be specified as zero (0) and is ignored when comparing RRsets for identity.
对于此先决条件，请求者将整个 RRset 添加到此部分，该 RRset 必须先存在。NAME 和 TYPE 是所表示的 RRset 的 NAME 和 TYPE。CLASS 是区域的 CLASS。TTL 必须指定为零 (0)，并且在比较 RRset 的身份时将被忽略。
2.4.3 - RRset Does Not Exist(RRset 不存在)
No RRs with a specified NAME and TYPE (in the zone and class denoted by the Zone Section) can exist.
不能存在具有指定 NAME 和 TYPE 的 RR（在区域部分表示的区域和类别中）。
For this prerequisite, a requestor adds to the section a single RR whose NAME and TYPE are equal to that of the RRset whose nonexistence is required. The RDLENGTH of this record is zero (0), and RDATA field is therefore empty. CLASS must be specified as NONE in order to distinguish this condition from a valid RR whose RDLENGTH is naturally zero (0) (for example, the NULL RR). TTL must be specified as zero (0).
对于此先决条件，请求者向部分添加单个 RR，其 NAME 和 TYPE 等于要求不存在的 RRset。此记录的 RDLENGTH 为零 (0)，因此 RDATA 字段为空。必须将 CLASS 指定为 NONE，以便将此条件与 RDLENGTH 自然为零 (0) 的有效 RR（例如，NULL RR）区分开来。TTL 必须指定为零 (0)。
2.4.4 - Name Is In Use(使用中的名字)
Name is in use. At least one RR with a specified NAME (in the zone and class specified by the Zone Section) must exist. Note that this prerequisite is NOT satisfied by empty nonterminals.
名称正在使用中。必须存在至少一个具有指定名称的 RR（在区域部分指定的区域和类别中）。请注意，空的非终结符不满足此先决条件。
For this prerequisite, a requestor adds to the section a single RR whose NAME is equal to that of the name whose ownership of an RR is required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified as ANY to differentiate this condition from that of an actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE must be specified as ANY to differentiate this case from that of an RRset existence test. TTL is specified as zero (0).
对于此先决条件，请求者向部分添加一个 RR，其名称等于需要拥有 RR 的名称。RDLENGTH 为零，因此 RDATA 为空。必须将 CLASS 指定为 ANY，以将此情况与 RDLENGTH 自然为零 (0) 的实际 RR（例如 NULL）区分开来。必须将 TYPE 指定为 ANY，以将此情况与 RRset 存在性测试区分开来。TTL 指定为零 (0)。
2.4.5 - Name Is Not In Use(未使用名字)
Name is not in use. No RR of any type is owned by a specified NAME. Note that this prerequisite IS satisfied by empty nonterminals.
名称未被使用。指定的名称不拥有任何类型的 RR。请注意，此先决条件由空的非终结符满足。
For this prerequisite, a requestor adds to the section a single RR whose NAME is equal to that of the name whose nonownership of any RRs is required. RDLENGTH is zero and RDATA is therefore empty. CLASS must be specified as NONE. TYPE must be specified as ANY. TTL must be specified as zero (0).
对于此先决条件，请求者向该部分添加一个 RR，其名称等于要求不拥有任何 RR 的名称的名称。RDLENGTH 为零，因此 RDATA 为空。CLASS 必须指定为 NONE。TYPE 必须指定为 ANY。TTL 必须指定为零 (0)。
2.5 - Update Section(Update 段)
This section contains RRs to be added to or deleted from the zone. The format of this section is as specified by [RFC1035 4.1.3]. There are four possible sets of semantics, summarized below and with details to follow.
此部分包含要添加到区域或从区域中删除的 RR。此部分的格式由 [RFC1035 4.1.3] 指定。有四组可能的语义，总结如下，后面会详细介绍。
1 | |
The syntax of these is as follows:
2.5.1 - Add To An RRset(添加到 RRset)
RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH and RDATA are those being added, and CLASS is the same as the zone class. Any duplicate RRs will be silently ignored by the primary master.
RR 被添加到Update Section，其 NAME、TYPE、TTL、RDLENGTH 和 RDATA 是被添加的，并且 CLASS 与区域类相同。任何重复的 RR 将被主服务器默默忽略。
2.5.2 - Delete An RRset(删除 RRset)
One RR is added to the Update Section whose NAME and TYPE are those of the RRset to be deleted. TTL must be specified as zero (0) and is otherwise not used by the primary master. CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. If no such RRset exists, then this Update RR will be silently ignored by the primary master.
向Update Section添加一个 RR，其 NAME 和 TYPE 是要删除的 RRset 的 NAME 和 TYPE。TTL 必须指定为零 (0)，否则主主服务器不会使用它。CLASS 必须指定为 ANY。RDLENGTH 必须为零 (0)，因此 RDATA 必须为空。如果不存在这样的 RRset，则主主服务器将默默忽略此更新 RR。
2.5.3 - Delete All RRsets From A Name(删除名称中的所有 RRset)
One RR is added to the Update Section whose NAME is that of the name to be cleansed of RRsets. TYPE must be specified as ANY. TTL must be specified as zero (0) and is otherwise not used by the primary master. CLASS must be specified as ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. If no such RRsets exist, then this Update RR will be silently ignored by the primary master.
一个 RR 被添加到Update Section，其 NAME 是要清除 RRset 的名称。TYPE 必须指定为 ANY。TTL 必须指定为零 (0)，否则主主服务器不会使用它。CLASS 必须指定为 ANY。RDLENGTH 必须为零 (0)，因此 RDATA 必须为空。如果不存在这样的 RRset，则主主服务器将默默忽略此更新 RR。
2.5.4 - Delete An RR From An RRset(从 RRset 中删除 RR)
RRs to be deleted are added to the Update Section. The NAME, TYPE, RDLENGTH and RDATA must match the RR being deleted. TTL must be specified as zero (0) and will otherwise be ignored by the primary master. CLASS must be specified as NONE to distinguish this from an RR addition. If no such RRs exist, then this Update RR will be silently ignored by the primary master.
要删除的 RR 被添加到Update Section。NAME、TYPE、RDLENGTH 和 RDATA 必须与要删除的 RR 匹配。TTL 必须指定为零 (0)，否则将被主主服务器忽略。CLASS 必须指定为 NONE 以将其与 RR 添加区分开来。如果不存在这样的 RR，则主主服务器将默默忽略此更新 RR。
2.6 - Additional Data Section(Additional Data 段)
This section contains RRs which are related to the update itself, or to new RRs being added by the update. For example, out of zone glue (A RRs referred to by new NS RRs) should be presented here. The server can use or ignore out of zone glue, at the discretion of the server implementor. The format of this section is as specified by [RFC1035 4.1.3].
本节包含与更新本身或更新所添加的新 RR 相关的 RR。例如，应在此处显示区域外粘合（新 NS RR 所指的 A RR）。服务器可以使用或忽略区域外粘合，由服务器实现者自行决定。本节的格式由 [RFC1035 4.1.3] 指定。
3 - Server Behavior(服务器行为)
A server, upon receiving an UPDATE request, will signal NOTIMP to the requestor if the UPDATE opcode is not recognized or if it is recognized but has not been implemented. Otherwise, processing continues as follows.
服务器在收到 UPDATE 请求后，如果 UPDATE 操作码未被识别或被识别但尚未执行，则将向请求者发出 NOTIMP 信号。否则，处理将继续进行，如下所示。
3.1 - Process Zone Section(处理Zone段)
- 3.1.1. The Zone Section is checked to see that there is exactly one RR therein and that the RR’s ZTYPE is SOA, else signal FORMERR to the requestor. Next, the ZNAME and ZCLASS are checked to see if the zone so named is one of this server’s authority zones, else signal NOTAUTH to the requestor. If the server is a zone slave, the request will be forwarded toward the primary master.
检查Zone段，查看其中是否只有一个 RR，并且 RR 的 ZTYPE 是否为 SOA，否则向请求者发出 FORMERR 信号。接下来，检查 ZNAME 和 ZCLASS，查看如此命名的区域是否是此服务器的授权区域之一，否则向请求者发出 NOTAUTH 信号。如果服务器是区域从属服务器，则请求将转发到主主服务器。
- 3.1.2 - Pseudocode For Zone Section Processing
区域部分处理的伪代码
1 | |
Sections 3.2 through 3.8 describe the primary master’s behaviour, whereas Section 6 describes a forwarder’s behaviour.
3.2 - Process Prerequisite Section(处理Prerequisite段)
Next, the Prerequisite Section is checked to see that all prerequisites are satisfied by the current state of the zone. Using the definitions expressed in Section 1.2, if any RR’s NAME is not within the zone specified in the Zone Section, signal NOTZONE to the requestor.
接下来，检查先决条件部分，查看区域当前状态是否满足所有先决条件。使用第 1.2 节中表达的定义，如果任何 RR 的 NAME 不在区域部分中指定的区域内，则向请求者发出 NOTZONE 信号。
- 3.2.1. For RRs in this section whose CLASS is ANY, test to see that TTL and RDLENGTH are both zero (0), else signal FORMERR to the requestor. If TYPE is ANY, test to see that there is at least one RR in the zone whose NAME is the same as that of the Prerequisite RR, else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to see that there is at least one RR in the zone whose NAME and TYPE are the same as that of the Prerequisite RR, else signal NXRRSET to the requestor.
对于本节中 CLASS 为 ANY 的 RR，测试 TTL 和 RDLENGTH 是否都为零 (0)，否则向请求者发出 FORMERR 信号。如果 TYPE 为 ANY，测试区域中至少有一个 RR 的 NAME 与先决条件 RR 的 NAME 相同，否则向请求者发出 NXDOMAIN 信号。如果 TYPE 不是 ANY，测试区域中至少有一个 RR 的 NAME 和 TYPE 与先决条件 RR 的 NAME 和 TYPE 相同，否则向请求者发出 NXRRSET 信号。
- 3.2.2. For RRs in this section whose CLASS is NONE, test to see that the TTL and RDLENGTH are both zero (0), else signal FORMERR to the requestor. If the TYPE is ANY, test to see that there are no RRs in the zone whose NAME is the same as that of the Prerequisite RR, else signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to see that there are no RRs in the zone whose NAME and TYPE are the same as that of the Prerequisite RR, else signal YXRRSET to the requestor.
对于本节中 CLASS 为 NONE 的 RR，测试 TTL 和 RDLENGTH 是否均为零 (0)，否则向请求者发出 FORMERR 信号。如果 TYPE 为 ANY，测试区域中是否存在 NAME 与先决条件 RR 相同的 RR，否则向请求者发出 YXDOMAIN 信号。如果 TYPE 不是 ANY，测试区域中是否存在 NAME 和 TYPE 与先决条件 RR 相同的 RR，否则向请求者发出 YXRRSET 信号。
- 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,test to see that the TTL is zero (0), else signal FORMERR to the requestor. Then, build an RRset for each unique <NAME,TYPE> and compare each resulting RRset for set equality (same members, no more, no less) with RRsets in the zone. If any Prerequisite RRset is not entirely and exactly matched by a zone RRset, signal NXRRSET to the requestor. If any RR in this section has a CLASS other than ZCLASS or NONE or ANY, signal FORMERR to the requestor.
对于本节中 CLASS 与 ZCLASS 相同的 RR，测试 TTL 是否为零 (0)，否则向请求者发出 FORMERR 信号。然后，为每个唯一的 <NAME,TYPE> 构建一个 RRset，并将每个生成的 RRset 与区域中的 RRset 进行比较，看是否集合相等（成员相同，不多不少）。如果任何先决条件 RRset 与区域 RRset 不完全匹配，则向请求者发出 NXRRSET 信号。如果此部分中的任何 RR 具有除 ZCLASS 或 NONE 或 ANY 之外的 CLASS，则向请求者发出 FORMERR 信号。
3.2.4 - Table Of Metavalues Used In Prerequisite Section(Prerequisite 段使用的元值表)
1
2
3
4
5
6
7CLASS TYPE RDATA Meaning
------------------------------------------------------------
ANY ANY empty Name is in use
ANY rrset empty RRset exists (value independent)
NONE ANY empty Name is not in use
NONE rrset empty RRset does not exist
zone rrset rr RRset exists (value dependent)3.2.5 - Pseudocode for Prerequisite Section Processing(Prerequisite 段 处理的伪代码)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31for rr in prerequisites
if (rr.ttl != 0)
return (FORMERR)
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == ANY)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (!zone_name<rr.name>)
return (NXDOMAIN)
else
if (!zone_rrset<rr.name, rr.type>)
return (NXRRSET)
if (rr.class == NONE)
if (rr.rdlength != 0)
return (FORMERR)
if (rr.type == ANY)
if (zone_name<rr.name>)
return (YXDOMAIN)
else
if (zone_rrset<rr.name, rr.type>)
return (YXRRSET)
if (rr.class == zclass)
temp<rr.name, rr.type> += rr
else
return (FORMERR)
for rrset in temp
if (zone_rrset<rrset.name, rrset.type> != rrset)
return (NXRRSET)
3.3 - Check Requestor’s Permissions(检查请求者的权限)
- 3.3.1. Next, the requestor’s permission to update the RRs named in the Update Section may be tested in an implementation dependent fashion or using mechanisms specified in a subsequent Secure DNS Update protocol. If the requestor does not have permission to perform these updates, the server may write a warning message in its operations log, and may either signal REFUSED to the requestor, or ignore the permission problem and proceed with the update.
接下来，可以以依赖于实现的方式或使用后续安全 DNS 更新协议中指定的机制来测试请求者更新更新部分中命名的 RR 的权限。如果请求者无权执行这些更新，则服务器可能会在其操作日志中写入警告消息，并可以向请求者发出 REFUSED 信号，或忽略权限问题并继续更新。
- 3.3.2. While the exact processing is implementation defined, if these verification activities are to be performed, this is the point in the server’s processing where such performance should take place, since if a REFUSED condition is encountered after an update has been partially applied, it will be necessary to undo the partial update and restore the zone to its original state before answering the requestor.
虽然确切的处理是实现定义的，但如果要执行这些验证活动，则这是服务器处理中应进行此类执行的点，因为如果在部分应用更新后遇到 REFUSED 条件，则需要撤消部分更新并将区域恢复到其原始状态，然后再回答请求者。
- 3.3.3 - Pseudocode for Permission Checking(权限检查的伪代码)
1
2
3
4
5
6if (security policy exists)
if (this update is not permitted)
if (local option)
log a message about permission problem
if (local option)
return (REFUSED)
3.4 - Process Update Section(流程更新部分)
Next, the Update Section is processed as follows.
接下来，更新部分按如下方式处理。
3.4.1 - Prescan(预扫描)
The Update Section is parsed into RRs and each RR’s CLASS is checked to see if it is ANY, NONE, or the same as the Zone Class, else signal a FORMERR to the requestor. Using the definitions in Section 1.2, each RR’s NAME must be in the zone specified by the Zone Section, else signal NOTZONE to the requestor.
将更新部分解析为 RR，并检查每个 RR 的 CLASS 以查看其是否为 ANY、NONE 或与区域类相同，否则向请求者发出 FORMERR 信号。使用第 1.2 节中的定义，每个 RR 的 NAME 必须位于区域部分指定的区域中，否则向请求者发出 NOTZONE 信号。
- 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any unrecognized type, then signal FORMERR to the requestor. For RRs whose CLASS is ANY or NONE, check the TTL to see that it is zero (0), else signal a FORMERR to the requestor. For any RR whose CLASS is ANY, check the RDLENGTH to make sure that it is zero (0) (that is, the RDATA field is empty), and that the TYPE is not AXFR, MAILA, MAILB, or any other QUERY metatype besides ANY, or any unrecognized type, else signal FORMERR to the requestor.
对于 CLASS 不是 ANY 的 RR，检查 TYPE，如果它是 ANY、AXFR、MAILA、MAILB 或任何其他 QUERY 元类型，或任何无法识别的类型，则向请求者发出 FORMERR 信号。对于 CLASS 为 ANY 或 NONE 的 RR，检查 TTL 以查看它是否为零 (0)，否则向请求者发出 FORMERR 信号。对于 CLASS 为 ANY 的任何 RR，请检查 RDLENGTH 以确保它为零 (0)（即，RDATA 字段为空），并且 TYPE 不是 AXFR、MAILA、MAILB 或除 ANY 之外的任何其他 QUERY 元类型或任何无法识别的类型，否则向请求者发出 FORMERR 信号。
- 3.4.1.3 - Pseudocode For Update Section Prescan(Update 段预扫描的伪代码)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15[rr] for rr in updates
if (zone_of(rr.name) != ZNAME)
return (NOTZONE);
if (rr.class == zclass)
if (rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == ANY)
if (rr.ttl != 0 || rr.rdlength != 0
|| rr.type & AXFR|MAILA|MAILB)
return (FORMERR)
elsif (rr.class == NONE)
if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
return (FORMERR)
else
return (FORMERR)
3.4.2 - Update(更新)
The Update Section is parsed into RRs and these RRs are processed in order.
Update段 被解析为 RR，并按顺序处理这些 RR。
- 3.4.2.1. If any system failure (such as an out of memory condition, or a hardware error in persistent storage) occurs during the processing of this section, signal SERVFAIL to the requestor and undo all updates applied to the zone during this transaction.
如果在处理此部分期间发生任何系统故障（例如内存不足或持久存储中的硬件错误），则向请求者发出 SERVFAIL 信号并撤消在此事务期间应用于区域的所有更新。
- 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to the zone. In case of duplicate RDATAs (which for SOA RRs is always the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL fields both match), the Zone RR is replaced by Update RR. If the TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is lower (according to [RFC1982]) than or equal to the current Zone SOA RR’s SOA.SERIAL, the Update RR is ignored. In the case of a CNAME Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME Update RR, otherwise replace the CNAME Zone RR with the CNAME Update RR.
任何 CLASS 与 ZCLASS 相同的更新 RR 都将添加到区域中。如果存在重复的 RDATA（对于 SOA RR 来说总是如此，对于 WKS RR 来说，如果 ADDRESS 和 PROTOCOL 字段都匹配，则会出现这种情况），则区域 RR 将由更新 RR 替换。如果 TYPE 是 SOA 并且没有区域 SOA RR，或者新的 SOA.SERIAL 低于或等于（根据 [RFC1982]）当前区域 SOA RR 的 SOA.SERIAL，则忽略更新 RR。如果是 CNAME 更新 RR 和非 CNAME 区域 RRset 或反之亦然，则忽略 CNAME 更新 RR，否则用 CNAME 更新 RR 替换 CNAME 区域 RR。
- 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, all Zone RRs with the same NAME are deleted, unless the NAME is the same as ZNAME in which case only those RRs whose TYPE is other than SOA or NS are deleted. For any Update RR whose CLASS is ANY and whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are deleted, unless the NAME is the same as ZNAME in which case neither SOA or NS RRs will be deleted.
对于 CLASS 为 ANY 且 TYPE 为 ANY 的任何更新 RR，将删除所有具有相同 NAME 的区域 RR，除非 NAME 与 ZNAME 相同，在这种情况下，只有 TYPE 不是 SOA 或 NS 的 RR 才会被删除。对于 CLASS 为 ANY 且 TYPE 不是 ANY 的任何更新 RR，将删除所有具有相同 NAME 和 TYPE 的区域 RR，除非 NAME 与 ZNAME 相同，在这种情况下，不会删除 SOA 或 NS RR。
- 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, unless the NAME is the same as ZNAME and either the TYPE is SOA or the TYPE is NS and the matching Zone RR is the only NS remaining in the RRset, in which case this Update RR is ignored.
对于任何类为 NONE 的更新 RR，任何 NAME、TYPE、RDATA 和 RDLENGTH 等于更新 RR 的区域 RR 都将被删除，除非 NAME 与 ZNAME 相同，并且 TYPE 为 SOA 或 TYPE 为 NS，并且匹配的区域 RR 是 RRset 中剩余的唯一 NS，在这种情况下，将忽略此更新 RR。
3.4.2.5. Signal NOERROR to the requestor.(向请求者发出 NOERROR 信号。)
3.4.2.6 - Table Of Metavalues Used In Update Section(Update段 使用的元值表)
1
2
3
4
5
6CLASS TYPE RDATA Meaning
---------------------------------------------------------
ANY ANY empty Delete all RRsets from a name
ANY rrset empty Delete an RRset
NONE rrset rr Delete an RR from an RRset
zone rrset rr Add to an RRset3.4.2.7 - Pseudocode For Update Section Processing(Update段 处理的伪代码)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37[rr] for rr in updates
if (rr.class == zclass)
if (rr.type == CNAME)
if (zone_rrset<rr.name, ~CNAME>)
next [rr]
elsif (zone_rrset<rr.name, CNAME>)
next [rr]
if (rr.type == SOA)
if (!zone_rrset<rr.name, SOA> ||
zone_rr<rr.name, SOA>.serial > rr.soa.serial)
next [rr]
for zrr in zone_rrset<rr.name, rr.type>
if (rr.type == CNAME || rr.type == SOA ||
(rr.type == WKS && rr.proto == zrr.proto &&
rr.address == zrr.address) ||
rr.rdata == zrr.rdata)
zrr = rr
next [rr]
zone_rrset<rr.name, rr.type> += rr
elsif (rr.class == ANY)
if (rr.type == ANY)
if (rr.name == zname)
zone_rrset<rr.name, ~(SOA|NS)> = Nil
else
zone_rrset<rr.name, *> = Nil
elsif (rr.name == zname &&
(rr.type == SOA || rr.type == NS))
next [rr]
else
zone_rrset<rr.name, rr.type> = Nil
elsif (rr.class == NONE)
if (rr.type == SOA)
next [rr]
if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
next [rr]
zone_rr<rr.name, rr.type, rr.data> = Nil
return (NOERROR)3.5 - Stability(稳定性)
When a zone is modified by an UPDATE operation, the server must commit the change to nonvolatile storage before sending a response to the requestor or answering any queries or transfers for the modified zone. It is reasonable for a server to store only the update records as long as a system reboot or power failure will cause these update records to be incorporated into the zone the next time the server is started. It is also reasonable for the server to copy the entire modified zone to nonvolatile storage after each update operation, though this would have suboptimal performance for large zones.
当区域被 UPDATE 操作修改时，服务器必须先将更改提交到非易失性存储中，然后再向请求者发送响应或回答针对已修改区域的任何查询或传输。服务器只存储更新记录是合理的，只要系统重新启动或电源故障会导致这些更新记录在下次启动服务器时合并到区域中。服务器在每次更新操作后将整个已修改区域复制到非易失性存储中也是合理的，尽管这对于大型区域的性能不是最佳的。
3.6 - Zone Identity(区域标识)
If the zone’s SOA SERIAL is changed by an update operation, that change must be in a positive direction (using modulo 2**32 arithmetic as specified by [RFC1982]). Attempts to replace an SOA with one whose SERIAL is less than the current one will be silently ignored by the primary master server.
如果区域的 SOA SERIAL 因更新操作而更改，则该更改必须是正向的（使用 [RFC1982] 指定的模 2**32 算法）。如果尝试用 SERIAL 小于当前 SOA 的 SOA 替换该 SOA，主服务器将默默忽略该尝试。
If the zone’s SOA’s SERIAL is not changed as a result of an update operation, then the server shall increment it automatically before the SOA or any changed name or RR or RRset is included in any response or transfer. The primary master server’s implementor might choose to autoincrement the SOA SERIAL if any of the following events occurs:
如果区域的 SOA 的 SERIAL 未因更新操作而更改，则服务器应在任何响应或传输中包含 SOA 或任何更改的名称或 RR 或 RRset 之前自动增加它。如果发生以下任何事件，主服务器的实施者可能会选择自动增加 SOA SERIAL：
1 | |
It is imperative that the zone’s contents and the SOA’s SERIAL be tightly synchronized. If the zone appears to change, the SOA must appear to change as well.
区域的内容和 SOA 的 SERIAL 必须紧密同步。如果区域似乎发生变化，则 SOA 也必须发生变化。
3.7 - Atomicity(原子性)
During the processing of an UPDATE transaction, the server must ensure atomicity with respect to other (concurrent) UPDATE or QUERY transactions. No two transactions can be processed concurrently if either depends on the final results of the other; in particular, a QUERY should not be able to retrieve RRsets which have been partially modified by a concurrent UPDATE, and an UPDATE should not be able to start from prerequisites that might not still hold at the completion of some other concurrent UPDATE. Finally, if two UPDATE transactions would modify the same names, RRs or RRsets, then such UPDATE transactions must be serialized.
在处理 UPDATE 事务期间，服务器必须确保与其他（并发）UPDATE 或 QUERY 事务的原子性。如果两个事务中有一个依赖于另一个的最终结果，则不能同时处理这两个事务；特别是，QUERY 不能检索已被并发 UPDATE 部分修改的 RRset，UPDATE 也不能从其他并发 UPDATE 完成时可能不再成立的先决条件开始。最后，如果两个 UPDATE 事务修改相同的名称、RR 或 RRset，则必须序列化此类 UPDATE 事务。
3.8 - Response(应答)
At the end of UPDATE processing, a response code will be known. A response message is generated by copying the ID and Opcode fields from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, and ADCOUNT fields and associated sections, or placing zeros (0) in the these “count” fields and not including any part of the original update. The QR bit is set to one (1), and the response is sent back to the requestor. If the requestor used UDP, then the response will be sent to the requestor’s source UDP port. If the requestor used TCP, then the response will be sent back on the requestor’s open TCP connection.
在 UPDATE 处理结束时，将知道响应代码。通过从请求中复制 ID 和 Opcode 字段，并复制 ZOCOUNT、PRCOUNT、UPCOUNT 和 ADCOUNT 字段及其相关部分，或在这些计数字段中放置零 (0) 而不包括原始更新的任何部分，可以生成响应消息。QR 位设置为一 (1)，并将响应发送回请求者。如果请求者使用 UDP，则响应将发送到请求者的源 UDP 端口。如果请求者使用 TCP，则响应将在请求者的打开的 TCP 连接上发送回。
4 - Requestor Behaviour(请求者行为)
- 4.1. From a requestor’s point of view, any authoritative server for the zone can appear to be able to process update requests, even though only the primary master server is actually able to modify the zone’s master file. Requestors are expected to know the name of the zone they intend to update and to know or be able to determine the name servers for that zone.
从请求者的角度来看，区域的任何权威服务器似乎都能够处理更新请求，即使只有主服务器才能真正修改区域的主文件。请求者应该知道他们打算更新的区域的名称，并知道或能够确定该区域的名称服务器。
- 4.2. If update ordering is desired, the requestor will need to know the value of the existing SOA RR. Requestors who update the SOA RR must update the SOA SERIAL field in a positive direction (as defined by [RFC1982]) and also preserve the other SOA fields unless the requestor’s explicit intent is to change them. The SOA SERIAL field must never be set to zero (0).
如果需要更新顺序，请求者将需要知道现有 SOA RR 的值。更新 SOA RR 的请求者必须以正向更新 SOA SERIAL 字段（如 [RFC1982] 所定义），并保留其他 SOA 字段，除非请求者的明确意图是更改它们。SOA SERIAL 字段绝不能设置为零 (0)。
- 4.3. If the requestor has reasonable cause to believe that all of a zone’s servers will be equally reachable, then it should arrange to try the primary master server (as given by the SOA MNAME field if matched by some NS NSDNAME) first to avoid unnecessary forwarding inside the slave servers. (Note that the primary master will in some cases not be reachable by all requestors, due to firewalls or network partitioning.)
如果请求者有合理理由相信区域的所有服务器都同样可访问，则应安排首先尝试主要主服务器（如果与某些 NS NSDNAME 匹配，则由 SOA MNAME 字段给出），以避免在从属服务器内进行不必要的转发。（请注意，由于防火墙或网络分区，在某些情况下，所有请求者都无法访问主要主服务器。）
- 4.4. Once the zone’s name servers been found and possibly sorted so that the ones more likely to be reachable and/or support the UPDATE opcode are listed first, the requestor composes an UPDATE message of the following form and sends it to the first name server on its list:
一旦找到区域的名称服务器并可能对其进行排序，以便首先列出最有可能可访问和/或支持 UPDATE 操作码的服务器，请求者将编写以下形式的 UPDATE 消息并将其发送到其列表中的第一个名称服务器：
1 | |
- 4.5. If the requestor receives a response, and the response has an RCODE other than SERVFAIL or NOTIMP, then the requestor returns an appropriate response to its caller.
如果请求者收到响应，并且响应的 RCODE 不是 SERVFAIL 或 NOTIMP，则请求者向其调用者返回适当的响应。
- 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or if no response is received within an implementation dependent timeout period, or if an ICMP error is received indicating that the server’s port is unreachable, then the requestor will delete the unusable server from its internal name server list and try the next one, repeating until the name server list is empty. If the requestor runs out of servers to try, an appropriate error will be returned to the requestor’s caller.
如果收到的响应的 RCODE 为 SERVFAIL 或 NOTIMP，或者在实现相关的超时期限内未收到任何响应，或者收到指示服务器端口无法访问的 ICMP 错误，则请求者将从其内部名称服务器列表中删除不可用的服务器并尝试下一个服务器，重复此过程，直到名称服务器列表为空。如果请求者没有服务器可尝试，则将向请求者的调用者返回适当的错误。
5 - Duplicate Detection, Ordering and Mutual Exclusion(重复检测、排序和互斥)
- 5.1. For correct operation, mechanisms may be needed to ensure idempotence, order UPDATE requests and provide mutual exclusion. An UPDATE message or response might be delivered zero times, one time, or multiple times. Datagram duplication is of particular interest since it covers the case of the so-called “replay attack” where a correct request is duplicated maliciously by an intruder.
为了正确操作，可能需要一些机制来确保幂等性、对 UPDATE 请求进行排序并提供互斥。UPDATE 消息或响应可能被传递零次、一次或多次。数据报重复尤其令人感兴趣，因为它涵盖了所谓的“重放攻击”的情况，即入侵者恶意复制正确的请求。
- 5.2. Multiple UPDATE requests or responses in transit might be delivered in any order, due to network topology changes or load balancing, or to multipath forwarding graphs wherein several slave servers all forward to the primary master. In some cases, it might be required that the earlier update not be applied after the later update, where “earlier” and “later” are defined by an external time base visible to some set of requestors, rather than by the order of request receipt at the primary master.
由于网络拓扑变化或负载平衡，或者由于多路径转发图（其中多个从属服务器都转发到主服务器），传输中的多个 UPDATE 请求或响应可能以任何顺序传递。在某些情况下，可能要求较早的更新不应用于较晚的更新之后，其中“较早”和“较晚”由某些请求者可见的外部时间基准定义，而不是由主服务器接收请求的顺序定义。
- 5.3. A requestor can ensure transaction idempotence by explicitly deleting some “marker RR” (rather than deleting the RRset of which it is a part) and then adding a new “marker RR” with a different RDATA field. The Prerequisite Section should specify that the original “marker RR” must be present in order for this UPDATE message to be accepted by the server.
请求者可以通过明确删除某些“标记 RR”（而不是删除它所属的 RRset），然后添加具有不同 RDATA 字段的新“标记 RR”，来确保事务幂等性。先决条件部分应指定原始“标记 RR”必须存在，以便服务器接受此 UPDATE 消息。
- 5.4. If the request is duplicated by a network error, all duplicate requests will fail since only the first will find the original “marker RR” present and having its known previous value. The decisions of whether to use such a “marker RR” and what RR to use are left up to the application programmer, though one obvious choice is the zone’s SOA RR as described below.
如果请求因网络错误而重复，则所有重复请求都将失败，因为只有第一个请求会发现原始“标记 RR”存在且具有其已知的先前值。是否使用这样的“标记 RR”以及使用什么 RR 的决定由应用程序程序员决定，但一个明显的选择是区域的 SOA RR，如下所述。
- 5.5. Requestors can ensure update ordering by externally synchronizing their use of successive values of the “marker RR.” Mutual exclusion can be addressed as a degenerate case, in that a single succession of the “marker RR” is all that is needed.
请求者可以通过外部同步其对“标记 RR”的连续值的使用来确保更新顺序。互斥可以作为一种退化情况来处理，因为只需要一个“标记 RR”的连续性即可。
- 5.6. A special case where update ordering and datagram duplication intersect is when an RR validly changes to some new value and then back to its previous value. Without a “marker RR” as described above, this sequence of updates can leave the zone in an undefined state if datagrams are duplicated.
更新顺序和数据报重复相交的一个特殊情况是当 RR 有效地更改为某个新值然后又回到其先前的值时。如果没有如上所述的“标记 RR”，如果数据报重复，此更新序列可能会使区域处于未定义状态。
- 5.7. To achieve an atomic multitransaction “read-modify-write” cycle, a requestor could first retrieve the SOA RR, and build an UPDATE message one of whose prerequisites was the old SOA RR. It would then specify updates that would delete this SOA RR and add a new one with an incremented SOA SERIAL, along with whatever actual prerequisites and updates were the object of the transaction. If the transaction succeeds, the requestor knows that the RRs being changed were not otherwise altered by any other requestor.
为了实现原子多事务“读取-修改-写入”循环，请求者可以首先检索 SOA RR，并构建一个 UPDATE 消息，其先决条件之一是旧的 SOA RR。然后，它将指定更新，这些更新将删除此 SOA RR 并添加一个具有递增 SOA SERIAL 的新更新，以及作为事务对象的任何实际先决条件和更新。如果事务成功，请求者知道正在更改的 RR 未被任何其他请求者更改。
6 - Forwarding(转发)
When a zone slave forwards an UPDATE message upward toward the zone’s primary master server, it must allocate a new ID and prepare to enter the role of “forwarding server,” which is a requestor with respect to the forward server.
当区域从属服务器将 UPDATE 消息向上转发到区域的主要主服务器时，它必须分配一个新 ID 并准备进入“转发服务器”的角色，即转发服务器的请求者。
- 6.1. The set of forward servers will be same as the set of servers this zone slave would use as the source of AXFR or IXFR data. So, while the original requestor might have used the zone’s NS RRset to locate its update server, a forwarder always forwards toward its designated zone master servers.
转发服务器集将与此区域从属服务器用作 AXFR 或 IXFR 数据源的服务器集相同。因此，虽然原始请求者可能已使用区域的 NS RRset 来定位其更新服务器，但转发器始终会转发到其指定的区域主服务器。
- 6.2. If the original requestor used TCP, then the TCP connection from the requestor is still open and the forwarder must use TCP to forward the message. If the original requestor used UDP, the forwarder may use either UDP or TCP to forward the message, at the whim of the implementor.
如果原始请求者使用 TCP，则来自请求者的 TCP 连接仍处于打开状态，转发器必须使用 TCP 来转发消息。如果原始请求者使用 UDP，则转发器可以使用 UDP 或 TCP 来转发消息，这取决于实施者的想法。
- 6.3. It is reasonable for forward servers to be forwarders themselves, if the AXFR dependency graph being followed is a deep one involving firewalls and multiple connectivity realms. In most cases the AXFR dependency graph will be shallow and the forward server will be the primary master server.
如果所遵循的 AXFR 依赖关系图是涉及防火墙和多个连接领域的深层依赖关系图，则转发服务器本身作为转发器是合理的。在大多数情况下，AXFR 依赖关系图将很浅，并且转发服务器将是主要主服务器。
- 6.4. The forwarder will not respond to its requestor until it receives a response from its forward server. UPDATE transactions involving forwarders are therefore time synchronized with respect to the original requestor and the primary master server.
转发器在收到转发服务器的响应之前不会响应其请求者。因此，涉及转发器的 UPDATE 事务相对于原始请求者和主要主服务器是时间同步的。
- 6.5. When there are multiple possible sources of AXFR data and therefore multiple possible forward servers, a forwarder will use the same fallback strategy with respect to connectivity or timeout errors that it would use when performing an AXFR. This is implementation dependent.
当存在多个可能的 AXFR 数据源并因此存在多个可能的转发服务器时，转发器将使用与执行 AXFR 时相同的连接或超时错误后备策略。这取决于实现。
- 6.6. When a forwarder receives a response from a forward server, it copies this response into a new response message, assigns its requestor’s ID to that message, and sends the response back to the requestor.
当转发器收到转发服务器的响应时，它会将此响应复制到新的响应消息中，将其请求者的 ID 分配给该消息，然后将响应发送回请求者。
7 - Design, Implementation, Operation, and Protocol Notes(设计、实施、操作和协议说明)
Some of the principles which guided the design of this UPDATE specification are as follows. Note that these are not part of the formal specification and any disagreement between this section and any other section of this document should be resolved in favour of the other section.
指导本 UPDATE 规范设计的一些原则如下。请注意，这些原则不是正式规范的一部分，本节与本文档其他任何部分之间的任何分歧都应以其他部分为准。
- 7.1. Using metavalues for CLASS is possible only because all RRs in the packet are assumed to be in the same zone, and CLASS is an attribute of a zone rather than of an RRset. (It is for this reason that the Zone Section is not optional.)
之所以可以使用 CLASS 的元值，是因为数据包中的所有 RR 都假定位于同一区域中，并且 CLASS 是区域的属性，而不是 RRset 的属性。（因此，区域部分不是可选的。）
- 7.2. Since there are no data-present or data-absent errors possible from processing the Update Section, any necessary data-present and data- absent dependencies should be specified in the Prerequisite Section.
由于处理更新部分时不可能出现数据存在或数据缺失错误，因此应在先决条件部分中指定任何必要的数据存在和数据缺失依赖关系。
- 7.3. The Additional Data Section can be used to supply a server with out of zone glue that will be needed in referrals. For example, if adding a new NS RR to HOME.VIX.COM specifying a nameserver called NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional Data Section. Servers can use this information or ignore it, at the discretion of the implementor. We discourage caching this information for use in subsequent DNS responses.
附加数据部分可用于为服务器提供引用中需要的区域外胶水。例如，如果向 HOME.VIX.COM 添加新的 NS RR 并指定名为 NS.AU.OZ 的名称服务器，则 NS.AU.OZ 的 A RR 可以包含在附加数据部分中。服务器可以使用或忽略此信息，由实施者自行决定。我们不鼓励缓存此信息以用于后续 DNS 响应。
- 7.4. The Additional Data Section might be used if some of the RRs later needed for Secure DNS Update are not actually zone updates, but rather ancillary keys or signatures not intended to be stored in the zone (as an update would be), yet necessary for validating the update operation.
如果安全 DNS 更新稍后需要的某些 RR 实际上不是区域更新，而是辅助密钥或签名（不打算存储在区域中，因为更新会存储），但对于验证更新操作是必需的，则可以使用附加数据部分。
- 7.5. It is expected that in the absence of Secure DNS Update, a server will only accept updates if they come from a source address that has been statically configured in the server’s description of a primary master zone. DHCP servers would be likely candidates for inclusion in this statically configured list.
在没有安全 DNS 更新的情况下，服务器只会接受来自服务器对主要主区域的描述中已静态配置的源地址的更新。DHCP 服务器可能是包含在此静态配置列表中的候选者。
- 7.6. It is not possible to create a zone using this protocol, since there is no provision for a slave server to be told who its master servers are. It is expected that this protocol will be extended in the future to cover this case. Therefore, at this time, the addition of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs is also unsupported.
无法使用此协议创建区域，因为没有规定从属服务器被告知其主服务器是谁。预计此协议将来会扩展以涵盖这种情况。因此，目前不支持添加 SOA RR。出于类似原因，也不支持删除 SOA RR。
- 7.7. The prerequisite for specifying that a name own at least one RR differs semantically from QUERY, in that QUERY would return <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at this name, while UPDATE’s prerequisite condition [Section 2.4.4] would NOT be satisfied.
指定名称拥有至少一个 RR 的先决条件在语义上与 QUERY 不同，因为如果查询此名称的 RRset，QUERY 将返回 <NOERROR,ANCOUNT=0> 而不是 NXDOMAIN，而 UPDATE 的先决条件 [第 2.4.4 节] 将不满足。
- 7.8. It is possible for a UDP response to be lost in transit and for a request to be retried due to a timeout condition. In this case an UPDATE that was successful the first time it was received by the primary master might ultimately appear to have failed when the response to a duplicate request is finally received by the requestor. (This is because the original prerequisites may no longer be satisfied after the update has been applied.) For this reason, requestors who require an accurate response code must use TCP.
UDP 响应可能会在传输过程中丢失，并且由于超时条件，请求可能会重试。在这种情况下，当请求者最终收到对重复请求的响应时，主主服务器第一次收到成功的 UPDATE 可能最终看起来失败了。（这是因为在应用更新后，原始先决条件可能不再满足。）因此，需要准确响应代码的请求者必须使用 TCP。
- 7.9. Because a requestor who requires an accurate response code will initiate their UPDATE transaction using TCP, a forwarder who receives a request via TCP must forward it using TCP.
由于需要准确响应代码的请求者将使用 TCP 启动其 UPDATE 事务，因此通过 TCP 接收请求的转发器必须使用 TCP 转发该请求。
-7.10. Deferral of SOA SERIAL autoincrements is made possible so that serial numbers can be conserved and wraparound at 2**32 can be made an infrequent occurance. Visible (to DNS clients) SOA SERIALs need to differ if the zone differs. Note that the Authority Section SOA in a QUERY response is a form of visibility, for the purposes of this prerequisite.
可以延迟 SOA SERIAL 自动增量，以便可以保存序列号，并且可以使 2**32 处的回绕不频繁发生。如果区域不同，可见的（对 DNS 客户端）SOA SERIAL 需要不同。请注意，出于此先决条件的目的，QUERY 响应中的 Authority Section SOA 是一种可见性形式。
- 7.11. A zone’s SOA SERIAL should never be set to zero (0) due to interoperability problems with some older but widely installed implementations of DNS. When incrementing an SOA SERIAL, if the result of the increment is zero (0) (as will be true when wrapping around 2**32), it is necessary to increment it again or set it to one (1). See [RFC1982] for more detail on this subject.
由于与某些较旧但广泛安装的 DNS 实现存在互操作性问题，因此区域的 SOA SERIAL 绝不能设置为零 (0)。在增加 SOA SERIAL 时，如果增加的结果为零 (0)（当环绕 2**32 时将为真），则需要再次增加它或将其设置为一 (1)。有关此主题的更多详细信息，请参阅 [RFC1982]。
- 7.12. Due to the TTL minimalization necessary when caching an RRset, it is recommended that all TTLs in an RRset be set to the same value. While the DNS Message Format permits variant TTLs to exist in the same RRset, and this variance can exist inside a zone, such variance will have counterintuitive results and its use is discouraged.
由于缓存 RRset 时需要最小化 TTL，因此建议将 RRset 中的所有 TTL 设置为相同的值。虽然 DNS 消息格式允许变体 TTL 存在于同一个 RRset 中，并且这种差异可以存在于区域内，但这种差异会产生违反直觉的结果，因此不鼓励使用。
- 7.13. Zone cut management presents some obscure corner cases to the add and delete operations in the Update Section. It is possible to delete an NS RR as long as it is not the last NS RR at the root of a zone. If deleting all RRs from a name, SOA and NS RRs at the root of a zone are unaffected. If deleting RRsets, it is not possible to delete either SOA or NS RRsets at the top of a zone. An attempt to add an SOA will be treated as a replace operation if an SOA already exists, or as a no-op if the SOA would be new.
区域切割管理在更新部分中介绍了一些添加和删除操作的模糊极端情况。只要 NS RR 不是区域根目录下的最后一个 NS RR，就可以删除它。如果从名称中删除所有 RR，则区域根目录下的 SOA 和 NS RR 不受影响。如果删除 RRset，则无法删除区域顶部的 SOA 或 NS RRset。如果 SOA 已经存在，则添加 SOA 的尝试将被视为替换操作，如果 SOA 是新的，则将被视为无操作。
- 7.14. No semantic checking is required in the primary master server when adding new RRs. Therefore a requestor can cause CNAME or NS or any other kind of RR to be added even if their target name does not exist or does not have the proper RRsets to make the original RR useful. Primary master servers that DO implement this kind of checking should take great care to avoid out-of-zone dependencies (whose veracity cannot be authoritatively checked) and should implement all such checking during the prescan phase.
在添加新 RR 时，主主服务器中不需要进行语义检查。因此，即使目标名称不存在或没有适当的 RRset 使原始 RR 有用，请求者也可以添加 CNAME 或 NS 或任何其他类型的 RR。实施此类检查的主主服务器应非常小心地避免区域外的依赖关系（无法对其真实性进行权威检查），并且应在预扫描阶段实施所有此类检查。
- 7.15. Nonterminal or wildcard CNAMEs are not well specified by [RFC1035] and their use will probably lead to unpredictable results. Their use is discouraged.
没有很好地指定非终端或通配符 CNAME，使用它们可能会导致不可预测的结果。不鼓励使用它们。
- 7.16. Empty nonterminals (nodes with children but no RRs of their own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response to a query of any type for that name. There is no provision for empty terminal nodes – so if all RRs of a terminal node are deleted, the name is no longer in use, and queries of any type for that name will result in an NXDOMAIN response.
空的非终端（有子节点但没有自己的 RR 的节点）将导致发送 <NOERROR,ANCOUNT=0> 响应以响应针对该名称的任何类型的查询。没有为空终端节点提供任何规定——因此，如果删除终端节点的所有 RR，则该名称将不再使用，并且对该名称的任何类型的查询都将导致 NXDOMAIN 响应。
- 7.17. In a deep AXFR dependency graph, it has not historically been an error for slaves to depend mutually upon each other. This configuration has been used to enable a zone to flow from the primary master to all slaves even though not all slaves have continuous connectivity to the primary master. UPDATE’s use of the AXFR dependency graph for forwarding prohibits this kind of dependency loop, since UPDATE forwarding has no loop detection analagous to the SOA SERIAL pretest used by AXFR.
在深度 AXFR 依赖关系图中，从属设备相互依赖在历史上并不是一个错误。此配置已用于使区域能够从主主设备流向所有从属设备，即使并非所有从属设备都与主主设备保持持续连接。UPDATE 使用 AXFR 依赖关系图进行转发禁止了这种依赖循环，因为 UPDATE 转发没有类似于 AXFR 使用的 SOA SERIAL 预测试的循环检测。
- 7.18. Previously existing names which are occluded by a new zone cut are still considered part of the parent zone, for the purposes of zone transfers, even though queries for such names will be referred to the new subzone’s servers. If a zone cut is removed, all parent zone names that were occluded by it will again become visible to queries. (This is a clarification of [RFC1034].)
出于区域传输的目的，被新区域切割遮挡的先前存在的名称仍被视为父区域的一部分，即使对此类名称的查询将被转交给新子区域的服务器。如果删除了区域切分，则被其遮挡的所有父区域名称将再次对查询可见。（这是对 [RFC1034] 的澄清。）
- 7.19. If a server is authoritative for both a zone and its child, then queries for names at the zone cut between them will be answered authoritatively using only data from the child zone. (This is a clarification of [RFC1034].)
如果服务器对区域及其子区域都具有权威性，则对它们之间的区域切分处的名称的查询将仅使用子区域的数据进行权威性回答。（这是对 [RFC1034] 的澄清。）
- 7.20. Update ordering using the SOA RR is problematic since there is no way to know which of a zone’s NS RRs represents the primary master, and the zone slaves can be out of date if their SOA.REFRESH timers have not elapsed since the last time the zone was changed on the primary master. We recommend that a zone needing ordered updates use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see [RFC1995]), and that a client receiving a prerequisite error while attempting an ordered update simply retry after a random delay period to allow the zone to settle.
使用 SOA RR 进行更新排序是有问题的，因为无法知道区域的哪个 NS RR 代表主主服务器，并且如果区域从属服务器的 SOA.REFRESH 计时器自上次在主主服务器上更改区域以来尚未过去，则它们可能已过时。我们建议需要有序更新的区域仅使用实现 NOTIFY（参见 [RFC1996]）和 IXFR（参见 [RFC1995]）的服务器，并且建议在尝试有序更新时接收到先决条件错误的客户端在随机延迟期后重试以允许区域稳定下来。
8 - Security Considerations(安全注意事项)
- 8.1. In the absence of [RFC2137] or equivilent technology, the protocol described by this document makes it possible for anyone who can reach an authoritative name server to alter the contents of any zones on that server. This is a serious increase in vulnerability from the current technology. Therefore it is very strongly recommended that the protocols described in this document not be used without [RFC2137] or other equivalently strong security measures, e.g. IPsec.
在没有 [RFC2137] 或同等技术的情况下，本文档描述的协议使任何能够访问权威名称服务器的人都可以更改该服务器上任何区域的内容。这与当前技术相比，漏洞严重增加。因此，强烈建议不要在没有 [RFC2137] 或其他同等强大的安全措施（例如 IPsec）的情况下使用本文档中描述的协议。
- 8.2. A denial of service attack can be launched by flooding an update forwarder with TCP sessions containing updates that the primary master server will ultimately refuse due to permission problems. This arises due to the requirement that an update forwarder receiving a request via TCP use a synchronous TCP session for its forwarding operation. The connection management mechanisms of [RFC1035 4.2.2] are sufficient to prevent large scale damage from such an attack, but not to prevent some queries from going unanswered during the attack.
可以通过向更新转发器发送包含更新的 TCP 会话来发起拒绝服务攻击，而主服务器最终会因为权限问题而拒绝这些更新。这是因为要求通过 TCP 接收请求的更新转发器使用同步 TCP 会话进行转发操作。[RFC1035 4.2.2] 的连接管理机制足以防止此类攻击造成大规模破坏，但无法防止某些查询在攻击期间得不到答复。
本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！