Bind slave slow to update zones

15,068

Solution 1

From the copy-left guide DNS for Rocket Scientists:

By default BIND9 will send NOTIFY messages to all the target names (right-hand names) that appear in NS RRs for the zone

So you need to add your slave server as a NS entry in db.example.com.inv.zone.

Additionally, you may need to add the settings:

  • In the master: notify yes; and allow-transfer { SLAVE_IP; };
  • In the slave: allow-notify { MASTER_IP; };

Solution 2

When the serial number is changed on the master, it will notify the slave immediately. In other words, notify is enabled by default. BUT, the way notify works is, the master looks at the NS records of that particular domain in the zone file, and notifies the servers listed in the NS record, excluding itself. In your case, I don't see the slave server's hostname being listed as an NS record in the db.root.example.com zone file. Therefore, the slave is contacting the master, listed in the slave's config file - masters { 192.168.0.2; }; at the Refresh interval, 1 hour. That is why it is taking long time to update.

Solution - add the NS record for the slave, also include its IP address as an A record. Typical setup is as follows -

  @        IN      NS      ns1.example.com.
  @        IN      NS      ns2.example.com.
  ns1     IN      A       192.168.1.1
  ns2     IN      A       192.168.1.2

First and third line, for master. Second and fourth line for slave.

Share:
15,068

Related videos on Youtube

infeo
Author by

infeo

Updated on September 18, 2022

Comments

  • infeo
    infeo almost 2 years

    I have two Bind servers in a master/slave configuration. When the serial is incremented on the master zone file, it takes longer than expected for the zone to update on the slave. I have replicated the problem on two test servers. With a ttl of 5 secs, it takes serveral minutes for the slave to update. I am using Bind 9.8 and Ubuntu 12.04.

    Here's my configuration for the master test server:

    named.conf.local

    zone "example.com" {
            type master;
            file "/var/lib/bind/db.example.com.zone";
            //forwarders {};
            // If we do not comment the ''forwarders'' "empty" clients of the local subnet     in my case don't have access to the upstream DNS ?
            //allow-update { key ns-example-com_rndc-key; };
            allow-update { key rndc-key; };
            //confusion between the file name to import (ns-example-com_rndc-key) and the     key label (rndc-key) ?
    };
    zone "0.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/db.example.com.inv.zone";
        //see comment below (zone "example.com")
        //forwarders {};
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
    };
    

    db.root.example.com

    $TTL    5
    @       IN      SOA   sid.example.com. root.example.com. (
                   2007010416           ; Serial
                           5           ; Refresh [1m]
                          5           ; Retry   [10m]
                        5           ; Expire  [1d]
                          5 )         ; Negative Cache TTL [1h]
    ;
    @       IN      NS      sid.example.com.
    @       IN      MX      10 sid.example.com.
    
    sid     IN      A       192.168.0.3
    etch    IN      A       192.168.0.3
    
    pop     IN      CNAME   sid
    www     IN      CNAME   sid
    mail    IN      CNAME   sid
    

    db.example.com.inv.zone

    @ IN SOA        sid.example.com. root.example.com. (
                   2007010401           ; Serial
                         3600           ; Refresh [1h]
                          600           ; Retry   [10m]
                        86400           ; Expire  [1d]
                          600 )         ; Negative Cache TTL [1h]
    ;
    @       IN      NS      sid.example.com.
    
    1       IN      PTR     sid.example.com.
    2       IN      PTR     etch.example.com.
    

    Here's the configuration for the slave:

    zone "example.com" {
        type slave;
        file "/var/cache/bind/db.example.com.zone";
        masters { 192.168.0.2; };
    //forwarders {};
        // If we do not comment the ''forwarders'' "empty" clients of the local subnet in my case don't have access to the upstream DNS ?
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
        //confusion between the file name to import (ns-example-com_rndc-key) and the key label (rndc-key) ?
    };
    zone "0.168.192.in-addr.arpa" {
        type slave;
        file "/var/cache/bind/db.example.com.inv.zone";
        masters { 192.168.0.2; };
    //see comment below (zone "example.com")
        //forwarders {};
        //allow-update { key ns-example-com_rndc-key; };
        allow-update { key rndc-key; };
    };
    
    • faker
      faker almost 11 years
      Looks OK to me, but I've never heard of anyone using such short refresh values. Typically you'd use notify to get zone changes (almost) instantly to your slave servers. Why not use that?
    • infeo
      infeo almost 11 years
      The sort refresh values are just on the test servers. What is notify? Is it in the reference manual?
    • Rahim Khoja
      Rahim Khoja almost 10 years
      I also find that adding also-notify { a.b.c.d; }; to your named.conf can sometimes help