The master DNS server maintains awareness of its slaves through explicit configuration in the zone file's NS records and the also-notify directive. When a zone is updated, BIND doesn't "parse" the zone file dynamically - it uses pre-configured slave server information stored in memory.

zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { 192.0.2.1; 192.0.2.2; };
    also-notify { 192.0.2.1; 192.2.2.2; };
};

The NOTIFY mechanism works differently in these scenarios:

Standard Configuration:
The master includes all slave servers in NS records and sends NOTIFY to each.

example.com.    IN  NS  ns1.example.com.
example.com.    IN  NS  ns2.example.com.

Hidden Master Setup:
The master isn't listed in public NS records, requiring explicit also-notify statements:

zone "example.com" {
    type master;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { 192.0.2.53; }; // slave IP
    also-notify { 192.0.2.53; port 5353; }; // notify slave on non-standard port
    notify explicit;
};

When NOTIFY appears broken in hidden master setups:

1. Verify allow-transfer includes all slaves
2. Check also-notify contains all slave IPs/ports
3. Ensure notify explicit is set
4. Confirm slaves are listening on expected ports

Debug with rndc status on master and named -g on slaves to see NOTIFY traffic.

For complex topologies involving stealth slaves or notification to third-party DNS services:

zone "example.com" {
    type master;
    also-notify {
        192.0.2.53;    // primary slave
        198.51.100.42; // secondary slave
        203.0.113.8 port 5300; // external DNS provider
    };
    notify-source 192.0.2.1 port 53;
    notify-source-v6 2001:db8::1;
};

Remember to configure matching allow-notify on slave servers for security.

In BIND DNS configurations, master servers maintain awareness of their slaves through explicit also-notify statements in named.conf or via NS records in zone files. When a zone is updated, the master checks these sources to determine notification targets.

zone "example.com" {
    type master;
    file "db.example.com";
    also-notify { 192.0.2.2; 192.0.2.3; }; // explicit slave IPs
    notify yes;
};

The sequence works as follows:

1. Zone serial increments upon change
2. Master checks NS records and also-notify list
3. NOTIFY messages sent to all identified slaves
4. Slaves initiate AXFR or IXFR transfers

In hidden master setups where slaves aren't listed in NS records, you must use also-notify explicitly. The standard NS-based notification would indeed fail here:

// Hidden master configuration
zone "secure.example" {
    type master;
    file "db.secure.example";
    also-notify { 
        192.0.2.10; // stealth slave 1 
        192.0.2.11; // stealth slave 2
    };
    notify yes;
};

Check notification status with these commands:

# Check notify targets
rndc status | grep "also notify"

# Verify zone transfers
dig @master example.com AXFR
dig @slave example.com SOA +short

The notify statement accepts three values: yes (default), no, or explicit (only notify also-notify targets).

For a hidden master serving 3 authoritative slaves:

// named.conf fragment
options {
    notify explicit; // Only notify listed servers
};

zone "internal.corp" {
    type master;
    file "db.internal.corp";
    also-notify {
        198.51.100.1; 
        198.51.100.2;
        198.51.100.3;
    };
};

This configuration ensures notifications reach all slaves while maintaining the hidden master's obscurity from public DNS queries.