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.

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.

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.

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.

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.

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.

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.