Skip to main content

5. Forwarding Behavior

5. Forwarding Behavior

This section describes the behaviour of a forwarding server, i.e., a slave name server that forwards UPDATE requests to the primary master.

5.1. When a slave server receives an UPDATE request for a zone for which it is authoritative, it should forward the request to the primary master for that zone. The address of the primary master should be obtained from the zone's SOA MNAME field or from server configuration.

5.2. The slave server should preserve the original requestor's address and other request parameters when forwarding the request. This allows the primary master to apply security policies and to send the response directly to the original requestor.

5.3. If the slave server uses UDP to forward the request, it should be prepared to retry using TCP if the UDP request times out or if it receives a TC (truncation) bit in the response.

5.4. If a slave server receives an UPDATE request via TCP, it MUST forward the request to the primary master using TCP. This ensures that requestors requiring accurate response codes (which is why they used TCP in the first place) will receive them.

5.5. A slave server may implement a forwarding timeout mechanism. If a forwarded request does not receive a response from the primary master within this timeout period, the slave may return a SERVFAIL response to the original requestor and close the connection (if TCP was used).

5.6. If the slave server is unable to forward the request (for example, because it cannot connect to the primary master), it should return a SERVFAIL response to the requestor.

5.7. It is possible for a slave server to implement a chain of forwarding, where updates are forwarded through multiple slave servers before reaching the primary master. However, such configurations are not recommended because they introduce additional points of failure and delay. If such a configuration is used, each forwarding server in the chain should follow the rules described in this section.

5.8. A forwarding server should not modify the UPDATE message except as necessary for DNS message forwarding (e.g., setting the recursion desired bit as appropriate for its configuration).

5.9. The forwarding server may cache the address of the primary master to avoid repeated SOA MNAME lookups. However, it should be prepared to refresh this cache if forwarding attempts fail, as the primary master may have been relocated.

5.10. If a forwarding loop is detected (for example, if the slave server receives back its own forwarded request), the server should return SERVFAIL to avoid infinite forwarding loops.