4. Requestor Behavior
4. Requestor Behavior
This section describes the behaviour of a requestor, i.e., an agent making UPDATE requests.
4.1. A requestor sends an UPDATE request to a known authoritative name server for the zone being updated. This server may be a primary or a slave server for the zone. If the server is a slave, the request will be forwarded to the primary. The requestor may try multiple servers before finding one that is authoritative and can perform the update.
4.2. If the server responses with a NOTAUTH or NOTIMP response code, the requestor should try a different server.
4.3. If the response code is SERVFAIL, the requestor should retry the update, perhaps after some delay. However, in the absence of a more specific retry algorithm specified by a DNS service discovery protocol, the requestor should not retry indefinitely.
4.4. If the response code is YXRRSET or NXRRSET, this means that the prerequisite was not met. The requestor may retry with a modified prerequisite or may abort the update.
4.5. If the response code is NOERROR, the update was accepted by the primary master. However, this does not guarantee that all slaves have received the update.
4.6. A requestor may include an SOA RR in the update to set or change SOA parameters. If multiple UPDATE messages for the same zone are to be sent in sequence, and if the SOA SERIAL is being managed by the requestor, then the requestor should check the zone's current SOA SERIAL (perhaps by examining the response to a previous UPDATE) before sending subsequent updates. This avoids races between the requestor's UPDATE messages and slave zone transfers.
4.7. UDP is preferred for UPDATE requests that fit in a single datagram, since this imposes less load on the server and less delay for the requestor. However, requestors should be prepared to retry the request using TCP if the UDP request times out, since some firewalls and packet filters block UDP port 53. Requestors requiring an accurate response code must use TCP, since a UDP response may be lost in transit.
4.8. While it is possible to include multiple updates in a single UPDATE message, doing so is not recommended unless the updates are strongly related. The reason is that if any update in the message fails to meet its prerequisites or encounters an error during processing, the entire UPDATE message will be rejected. Therefore, requestors should generally send separate UPDATE messages for unrelated updates.