How to configure Master Name Server

Master(Primary)NameServers

A Master DNS defines one or more zone files for which this DNS is Authoritative ('type master'). The zone has been delegated (via an NS Resource Record) to this DNS.
The term 'master' was introduced in BIND 8.x and replaced the term 'primary'.
Master status is defined in BIND by including 'type master' in the zone declaration section of the name.conf file as shown by the following fragment.

// example.com fragment from named.conf
// defines this server as a zone master
zone "example.com" in{
type master;
file "pri.example.com";
};

---

Notes

1. The terms Primary and Secondary DNS entries in Windows TCP/IP network properties mean nothing, they may reflect the 'master' and 'slave' name-server or they may not - you decide this based on operational need, not BIND configuration.
   
2. It is important to understand that a zone 'master' is a server which gets its zone data from a local source as opposed to a 'slave' which gets its zone data from an external (networked) source (typically the 'master' but not always). This apparently trivial point means that you can have any number of 'master' servers for any zone if it makes operational sense. You have to ensure (by a manual or other process) that the zone files are synchronised but apart from this there is nothing to prevent it.
   
3. Just to confuse things still further you may run across the term 'Primary Master' this has a special meaning in the context of dynamic DNS updates and is defined to be the name server that appears in the SOA RR record.
   

When a master DNS receives Queries for a zone for which it is authoritative then it will respond as 'Authoritative' (AA bit is set in a query response).
If a DNS server receives a query for a zone for which it is neither a Master nor a Slave then it will act as configured (in BIND this behaviour is defined in the named.conf file :

1. If caching behaviour is permitted and recursive queries are allowed the server will completely answer the request or return an error.
   
2. If caching behaviour is permitted and Iterative (non-recursive) queries are allowed the server can respond with the complete answer (if it is already in the cache because of another request), a referral or return an error.
   
3. If caching behaviour is NOT permitted (an 'Authoritative Only' DNS server) the server will return a referral or an error.
   

A master DNS server can NOTIFY zone changes to defined (typically slave) servers - this is the default behaviour. NOTIFY messages ensure zone changes are rapidly propagated to the slaves (interrupt driven) rather than rely on the slave server periodically polling for changes. The BIND default is to notify the servers defined in NS records for the zone - except itself, obviously.
A zone master can be 'hidden' (only one or more of the slaves know of its existence). There is no requirement in such a configuration for the master server to appear in an NS RR for the domain. The only requirement is that two (or more) name servers support the zone. Both servers could be any combination of master-slave, slave-slave or even master-master.
If you are running Stealth Servers and wish them to be notified you will have to add an also-notify parameter as shown in the BIND named.conffile fragment below:

// example.com fragment from named.conf
// defines this server as a zone master
// 192.168.0.2 is a stealth server NOT listed in a NS record
zone "example.com" in{
type master;
also-notify {192.168.0.2;};
file "pri/pri.example.com";
};

You can turn off all NOTIFY operations by specifying 'notify no' in the zone declaration.
Example configuration files for a master DNS Are provided.