1

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, the only update I have seen so far is 2 updates, 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, no change. The first time I got it working it was quicker, now I repeated the same setup with a new IP and it's too slow. I have read this and have added it in my zone files as well, still it's dead slow.

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.

Anything else I should do to speed up the initial update ?

  • It took about 30 minutes to complete the zone update, if someone could explain what happens in the background that takes this much time, that would be great.. – Huud Rych Dec 31 '18 at 23:00
  • It would help to say which dns software you are using. After that you should say what commands you run after you update the master to encourage the slave to get the updated data. – icarus Dec 31 '18 at 23:13
  • Sorry didnt realize that, I'm using the BIND v9, the command to update is named -u named -g -p 53 to get the Slave to update.. – Huud Rych Dec 31 '18 at 23:15
  • named -u named -g -p 53 runs the named command in the foreground. My understanding is these days you want to run rndc when you change the data, but I haven't used bind in decades. – icarus Dec 31 '18 at 23:20
  • 1
    Did you change the serial number before you did the reload? – icarus Dec 31 '18 at 23:32
1

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.

RESOLVCONF=yes

OPTIONS=-4

Now it updates instantly.

  • Good job. Though supposedly BIND has algorithms to prevent this... – Rui F Ribeiro Jan 1 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.