BIND9 sends notify to slave only with also-notify
I have a problem that has been driving me crazy for three days! I'm replacing my Authoritative DNS servers with new ones and then I'm resetting all BIND9 configurations again to do a bit more "fine tuning" given the replacement.
I have configured a MASTER server and two SLAVE servers, I have configured a zone to be used as a test with a domain (FQDN) that I usually use for tests, the problem is this:
- When I update the zone and reboot / reload bind, from the logs I see that notifications are sent correctly but the all slaves, they do not receive (also verified with tcpdump port 53: no out from master)
Feb 12 20:42:13 svr-3 named[12957]: zone test.com/IN: sending notifies (serial 20210 21201)
- If I add instead the directive "also-notify {slave_ip_1; slave_ip_2;}; notifications are sent and received correctly (verified with tcpdump port 53 and with bind logs) and obviously the transfer process starts and ends correctly
At this point, I believe that it is a problem on some configuration of the MASTER that I have escaped or set incorrectly, since the slaves receive correctly; it would appear as if it is not reading the authoritative NS records.
I am attaching the configuration files, perhaps with your help, I can find the error (the file is to be completed, I stopped as soon as I encountered this problem)
named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on { xxx; };
listen-on-v6 { any; };
//IP da utilizzare per le richieste in uscita di aggiornamento zone e il forward dei dynamic updates
transfer-source xxx;
//Abilito le notifiche
notify yes;
//Quale IP utilizzare per le notifiche in uscita
notify-source xxx;
//IP da notificare in aggiunta degli NS RR
// also-notify { yyy; zzz; };
auth-nxdomain no;
// hide version number from clients for security reasons.
version "Not Available";
// disable recursion on authoritative DNS server.
recursion no;
// enable the query log
querylog yes;
// disallow zone transfer
allow-transfer { none; };
};
zone file
; BIND reverse data file for empty rfc1918 zone
;
; DO NOT EDIT THIS FILE - it is used for multiple zones.
; Instead, copy it, edit named.conf, and use that copy.
;
$TTL 86400 ;TTL (1 Giorno)
$ORIGIN test.com. ;Base Dominio
; Record Start of Authority (SOA)
@ IN SOA ns1.test.net. hostmaster.test.net. (
2021021201 ; Serial
21600 ; Refresh (6H)
10800 ; Retry (3H)
604800 ; Expire (1 Settimana)
604800 ) ; Negative Cache TTL (1 Settimana)
; Record A
@ 10800 IN A 123.345.678.123
www 10800 IN A 123.345.678.123
; Record AAAA
; Record CNAME
; Record TXT
; Record SRV
; Record MX
@ 3600 IN MX 1 mail.test.net.
@ 3600 IN MX 10 mail2.test.net.
; Record NS
@ IN NS ns1.test.net.
@ IN NS ns2.test.net.
@ IN NS dns.otherdomain.it.
named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "test.com" {
type master;
file "/etc/bind/zones/db.test.com";
allow-query { any; };
allow-transfer { key keytest; };
};
Solution 1:
I got to the point of putting into production the new machines for the management of the Authoritative DNS servers and at this point I was able to perform a more precise diagnosis.
The problem has been solved, I think it was due to the fact that in the transfer phase I registered the new GLUE records with the registrar, then I transferred all the zones to the new master server and at this point I reported the problem to you .
But I had not yet reported (with the registrar) the new DNS addresses, because obviously the machines were not yet complete with configurations; yesterday I proceeded to run a DNS UPDATE, then to make the new services functional and SURPRISE!
Now by disabling the "also-notify" function, the master server is able to send notifications to the slave machines.
I honestly did not think that bind was going to check which were the authoritative servers currently set up at the registrar, I thought that only the NS records set in the zone file were enough.
Thanks everyone for trying to help me with this problem, I hope this experience can be helpful.