Hi, I have configured a master/Slave zone, the initial zone transfer is too slow and no changes have happened over the course of 10 mins it took 30 mins before I received zone up to date, this is in a test VMs and not production, there is hardly any data in it. Could it be a misconfiguration, I have changed TTL, refresh, retry to 100, yet nothing happens, tried bumping up the serial as well to get an update, this causes the slave to show Transfer completed: 1 messages but not zone up to date, any specific reason this is happening. Another problem is that once the zone is updated, only the slave shows the message zone up to date, the master does not. Anything else I should do to speed up the initial update ? I am using Code: named -u named -g -p 53 to run it in foreground The master does not show in update like Code: transfer of 'L00012345.local/IN': AXFR-style IXFR started message, nothing, just shows Code: 01-Jan-2019 07:15:15.527 zone L00144445.local/IN: sending notifies (serial 1) 01-Jan-2019 07:15:15.527 zone 102.168.192.IN-ADDR.ARPA/IN: sending notifies (serial 1)[code] This is even after the zone has updated. Forward Zone [code]$TTL 3H $ORIGIN L00144445.local. @ IN SOA ns1.L00144445.local. admin.L00144445.local. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.L00144445.local. IN NS ns2.L00144445.local. ns1 IN A 192.168.102.191 ns2 IN A 192.168.102.192 Reverse Zone Code: $TTL 3H $ORIGIN 102.168.192.IN-ADDR.ARPA. @ IN SOA ns1.L00144445.local. admin.L00144445.local. ( 0 ; serial 1D ; refresh 1H ; retry 1W ; expire 3H ) ; minimum IN NS ns1.L00144445.local. IN NS ns2.L00144445.local. 191 IN PTR ns1.L00144445.local. 192 IN PTR ns2.L00144445.local. named.conf MASTER Code: acl internals { 192.168.102.0/24; }; options { listen-on port 53 { 127.0.0.1; 192.168.102.191; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; allow-transfer { 192.168.102.192; }; allow-query { localhost; internals; }; recursion yes; dnssec-enable yes; dnssec-validation yes; bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; zone "." IN { type hint; file "named.ca"; }; zone "L00144445.local" { type master; file "L00144445.db"; allow-transfer { 192.168.102.192; }; notify yes; }; zone "102.168.192.IN-ADDR.ARPA" { type master; file "54444100L.db"; allow-transfer { 192.168.102.192; }; notify yes; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; named.conf SLAVE Code: acl internals { 192.168.102.0/24; }; options { listen-on port 53 { 127.0.0.1; 192.168.102.192; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; allow-notify { 192.168.102.191; }; allow-query { localhost; internals; }; recursion yes; dnssec-enable yes; dnssec-validation yes; bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; zone "." IN { type hint; file "named.ca"; }; zone "L00144445.local" { type slave; masters { 192.168.102.191; }; file "L00144445.db"; allow-transfer { 192.168.102.191; }; notify yes; }; zone "102.168.192.IN-ADDR.ARPA" { type slave; masters { 192.168.102.191; }; file "54444100L.db"; allow-transfer { 192.168.102.191; }; notify yes; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key";
You do not say what version of Bind you are running, but my recollection is it was some 15 years ago that bind got push update capability. That is, if the master is configured with info on what slaves zone has, the update is pushed immediately to slaves. Otherwise the update happens when the slaves use up TTL and do the zone transfer. If you forget to update zone serial number, the zone transfer does not happen. I use Emacs with zone mode to edit zone files, it updates serial automatically. The slave stores zones in files, you can look directly in the storage directory if the files there are updated or not. Have you considered using ISPConfig to run your name service? That would relieve you from these petty details that hamper operations. https://www.howtoforge.com/tutorial/setting-up-your-own-name-service-with-ispconfig/ Otherwise, get the book "DNS and Bind", http://shop.oreilly.com/product/9780596100575.do . My copy is at the office so I can not look things up for you.
Thanks for the update, I manage to solve the issue as follows. I found the problem to be ipv6 configuration which kept on attempting to update the zones as well, this was found in /var/log/messages log file, and since it was pre-configured in its default setting, it would keep on attempting to update zone right after ipv4 is updated thus no response was even received. Removed all references of ipv6 from /etc/named.conf, and added the following options to /etc/sysonfig/named file. Code: RESOLVCONF=yes OPTIONS=-4 Now it updates instantly. Appreciate your guidance, I'm want to improve my basics before taking higher level tools, good advice nonetheless.