BIND is refusing to acknowledge DNS update notifications from a secondary DNS server, flagging them as coming from an unexpected source. This means your zone file changes made on the primary server might not be propagating to your secondary servers, leading to inconsistent DNS records across your infrastructure.
The most common culprit is a network configuration issue where the secondary server isn’t correctly identifying the primary server’s IP address, or vice-versa, due to NAT, load balancers, or incorrect allow-notify directives.
Cause 1: Incorrect allow-notify on Primary
The primary server, 192.168.1.10, explicitly lists which IP addresses are allowed to send it notifications. If the secondary server’s IP, 192.168.1.20, isn’t in this list, the primary will reject the notification.
Diagnosis:
On the primary server, check your named.conf or included zone file for the allow-notify directive for the affected zone.
grep 'allow-notify' /etc/bind/named.conf.local
Fix:
Add the secondary server’s IP address to the allow-notify list.
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
allow-notify { 192.168.1.20; localhost; }; // Add secondary IP here
};
Restart BIND on the primary: sudo systemctl restart named. This works because allow-notify acts as a whitelist, and by adding the secondary’s IP, you’re explicitly granting it permission to send notifications for this zone.
Cause 2: IP Address Mismatch due to NAT/Firewall
If there’s a NAT device or firewall between your primary and secondary servers, the IP address the secondary thinks it’s sending notifications from might not be the IP address the primary expects to receive them on. The primary sees the NATed IP and rejects it.
Diagnosis:
On the secondary server, check its BIND configuration (named.conf) for any forwarders or masters directives. The IP listed there is what the secondary will try to notify. On the primary, verify the allow-notify list. Also, check firewall logs on the primary for dropped UDP port 53 packets from the secondary’s external IP.
Fix:
Ensure the allow-notify directive on the primary includes the public or NATed IP address that the secondary server’s notifications will egress from. If the secondary is sending from 10.0.0.5 but it’s NATed to 192.168.1.20 before reaching the primary, 192.168.1.20 must be in allow-notify on the primary.
// On primary server
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
allow-notify { 192.168.1.20; 10.0.0.5; localhost; }; // Include NATed and internal IPs if needed
};
Reload BIND on the primary: sudo systemctl reload named. This ensures the primary’s access control list accounts for the network path the notification takes.
Cause 3: Incorrect masters directive on Secondary
The secondary server’s configuration tells it which IP address is the master for a given zone. If this IP is incorrect, it might be trying to send notifications to the wrong IP, or it might be misidentifying the source of notifications from the primary.
Diagnosis:
On the secondary server, check its named.conf for the masters directive for the zone.
grep 'masters' /etc/bind/named.conf.local
Fix:
Correct the IP address in the masters directive to point to the actual IP of the primary server.
zone "example.com" {
type slave;
file "/var/lib/bind/db.example.com.slave";
masters { 192.168.1.10; }; // Ensure this is the primary's IP
};
Restart BIND on the secondary: sudo systemctl restart named. This ensures the secondary knows precisely which server to communicate with for zone transfers and notifications.
Cause 4: notify yes; missing on Primary
While less common for the "unexpected source" error, if notify yes; is absent or explicitly set to no for a zone on the primary, it won’t send notifications at all, which can sometimes manifest in confusing ways on the secondary if it’s expecting them.
Diagnosis:
Check the zone definition on the primary server’s named.conf.
grep 'notify' /etc/bind/named.conf.local
Fix:
Ensure notify yes; is present for the zone on the primary.
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
allow-notify { 192.168.1.20; };
notify yes; // Ensure this is present and not 'no'
};
Reload BIND on the primary: sudo systemctl reload named. This explicitly enables the notification mechanism for zone updates.
Cause 5: DNSSEC Issues
If DNSSEC is enabled for your zone, the TSIG keys used for transaction signatures might be mismatched or expired between the primary and secondary. While this usually leads to TSIG-related errors, it can sometimes manifest as a generic "unexpected source" if the signature validation fails in a specific way.
Diagnosis:
On the primary, check named.conf for key definitions associated with the zone. On the secondary, check its corresponding key definition and ensure it matches the primary exactly, including the algorithm and secret. Use dnssec-keygen and dnssec-signzone outputs as reference.
Fix: Regenerate TSIG keys or ensure the correct, current key is configured on both primary and secondary servers. Copy the key content precisely.
// On both primary and secondary, in relevant zone or global key sections
key "my-rndc-key" {
algorithm hmac-sha256;
secret "your_very_long_and_random_secret_key_here";
};
// On primary, associate with zone
zone "example.com" {
type master;
file "...";
allow-notify { 192.168.1.20; };
key "my-rndc-key"; // Or a specific zone transfer key
};
Reload BIND on both servers: sudo systemctl reload named. This ensures secure communication channels are established and trusted.
Cause 6: Loopback Interface vs. Public IP for Notifications
If your primary server is configured to listen on 127.0.0.1 for some services but its public IP is 192.168.1.10, and the secondary is configured to notify 192.168.1.10, the primary might reject it if allow-notify only lists localhost or 127.0.0.1.
Diagnosis:
Check named.conf on the primary for listen-on directives and allow-notify. Check the secondary’s masters directive.
Fix:
Ensure the allow-notify on the primary includes the IP address that the secondary is actually sending notifications to. If the secondary sends to 192.168.1.10 and the primary is listening on 192.168.1.10, then 192.168.1.10 must be in allow-notify.
// On primary server
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
allow-notify { 192.168.1.10; 192.168.1.20; localhost; }; // Include primary's own IP if secondary targets it
};
Reload BIND on the primary: sudo systemctl reload named. This aligns the IP the notification is sent to with the IP BIND is configured to accept notifications from.
After fixing these, you might encounter "client 192.168.1.20#53: zone example.com/IN: transfer 'example.com/IN/IN': REFUSED" if the allow-transfer directive on the primary doesn’t permit zone transfers from the secondary.