Report this

What is the reason for this report?

First DNS zone update between master and slave is taking too long, but happens..

Posted on January 1, 2019
huud

By huud

Hi,

Having configured the master/Slave zone, the initial zone transfer is too slow and no changes have happened until after 30 mins before I received zone up to date but ONLY on the Slave, is the Master suppose to show this as well as I have enabled notify on both servers.

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 named -u named -g -p 53 to run it in foreground

The master does not show any update like transfer of ‘L00012345.local/IN’: AXFR-style IXFR started message, nothing, just shows

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)

This is even after the zone has updated.

Forward Zone

$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

$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

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 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”;



This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Hi there,

DNS zone transfers may not be instantaneous and can take some time depending on several factors such as network conditions, size of the zone, and DNS server configurations. In your case, since you’re working with a test Droplet and there is little data, it seems unusual that the transfer is taking 30 minutes.

Here are a few possible issues that may cause this:

  1. Networking Problems: Please ensure that there are no networking issues between the master and the slave DNS servers. This could include connectivity problems, firewall restrictions, or other networking conditions that could slow down the zone transfer.

  2. DNS Server Configuration: Your DNS server configuration looks generally correct, but there may be other parameters affecting the speed of the transfer. For example, the refresh parameter in the SOA record determines how often the slave will check for updates from the master. If this is set to a high value, it could delay the updates. However, in your case, you’ve set it to 1 day (1D), which shouldn’t cause such a delay.

  3. DNS Server Performance: If the DNS servers are under high load or if there are other performance-related issues, it could potentially slow down the transfer. Please ensure that the DNS servers have sufficient resources and are performing optimally.

  4. Serial Number: If the serial number in the SOA record on the master isn’t higher than the one on the slave, the slave won’t initiate a zone transfer. You mentioned that you’ve tried to bump the serial number, but please ensure that it’s always incremented whenever changes are made.

As for your question about whether the master should show the “zone up to date” message, this message is typically shown on the slave DNS server, not on the master. The master doesn’t need to check for updates because it’s the source of the updates. On the other hand, the slave regularly checks the master for updates, and when it finds that its zone data matches the master’s, it shows the “zone up to date” message.

Finally, for speeding up the initial update, you could try decreasing the refresh interval in the SOA record. But again, this shouldn’t be necessary in your case because the refresh interval is already set to a reasonable value (1 day), and your updates are taking unusually long. You may want to focus more on investigating potential networking issues or DNS server performance problems.

Best,

Bobby

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.