4. Requestor Behavior (请求者行为)

4. 请求者行为 (Requestor Behavior)

本节描述请求者的行为, 即发出 UPDATE 请求的代理的行为.

4.1. 请求者向正在更新的 zone 的已知权威名称服务器发送 UPDATE 请求. 此服务器可以是该 zone 的 primary server 或 slave server. 如果服务器是 slave, 请求将被转发到 primary. 请求者可以在找到有权威性且能够执行更新的服务器之前尝试多个服务器.

4.2. 如果服务器以 NOTAUTH 或 NOTIMP 响应代码响应, 请求者应尝试另一台服务器.

4.3. 如果响应代码为 SERVFAIL, 请求者应重试更新, 或许先等待一段时间. 但是, 在没有 DNS 服务发现协议指定更具体重试算法的情况下, 请求者不应无限期重试.

4.4. 如果响应代码为 YXRRSET 或 NXRRSET, 这意味着 prerequisite 未满足. 请求者可以使用修改后的 prerequisite 重试, 或者中止该更新.

4.5. 如果响应代码为 NOERROR, 更新已被 primary master 接受. 但是, 这不保证所有 slave 都已收到该更新.

4.6. 请求者可以在更新中包含 SOA RR, 以设置或更改 SOA 参数. 如果要按顺序发送同一 zone 的多条 UPDATE 消息, 且 SOA SERIAL 由请求者管理, 则请求者应在发送后续更新之前检查该 zone 当前的 SOA SERIAL (或许通过检查先前 UPDATE 的响应). 这可以避免请求者的 UPDATE 消息与 slave zone transfer 之间发生竞争.

4.7. 对于适合单个数据报的 UPDATE 请求, 首选 UDP, 因为这会给服务器带来较小负载, 并给请求者带来较低延迟. 但是, 如果 UDP 请求超时, 请求者应准备使用 TCP 重试该请求, 因为某些防火墙和包过滤器会阻止 UDP 端口 53. 需要准确响应代码的请求者必须使用 TCP, 因为 UDP 响应可能在传输途中丢失.

4.8. 虽然可以在单个 UPDATE 消息中包含多个更新, 但除非这些更新强相关, 否则不建议这样做. 原因是, 如果消息中的任何更新未能满足其 prerequisite 或在处理过程中遇到错误, 整个 UPDATE 消息都将被拒绝. 因此, 请求者通常应为不相关的更新发送单独的 UPDATE 消息.