Of Masters and Slaves

In the context of updates, what server to update becomes important, because there will be a need to know what server is the primary master. The primary master is named in the SOA record's first field. This field must not be used for the zone name. It must name the zone master server. Even if the server is otherwise unlisted, it must be named in the SOA record.

A slave server is a server that has a master. A master server is a server that acts as a master for a slave. The primary master is the zone origin server it has no masters.

RFC 2136 specifies that, if a slave server receives an update request, the request shall be accepted and forwarded toward the primary master server. A slave server will not know who is authorized to update zones and so cannot check the authorization. It must store the update request and forward it. If the primary master is unavailable, it should forward it to any other master it knows. This allows the request to percolate through layers of protection that might be present between the zone updater and the primary master. That's the theory anyway. As of this writing (May 2000), BIND 8 does not implement this and the primary master must be present for an update to take hold. Even if you configure a slave to accept update requests and update the zone, the update will not find its way back to the primary master. Then, the next time a zone transfer from the primary master takes place, the update will be overwritten. So, the primary master must be available to the zone updater. This will be fixed in a future version of BIND.