first DNS zone update nbetween master and slave is taking too long, but happens eventually partially

Discussion in 'Server Operation' started by huud, Jan 1, 2019.

  1. huud

    huud New Member

    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";
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  3. huud

    huud New Member

    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.
     
    Last edited: Jan 1, 2019

Share This Page