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).
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.)
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:
ID: (new)
Opcode: UPDATE
Zone zcount: 1
Zone zname: (zone name)
Zone zclass: (zone class)
Zone ztype: T_SOA
Prerequisite Section: (see previous text)
Update Section: (see previous text)
Additional Data Section: (empty)
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.
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.