Force slave BIND9 server reload inmediately

[Jonathan Petersson]

Have you enabled

also-notify { ip-to-slave };

for the zone in named.conf?

Also, I would use A-records rather than CNAMEs when referring to NS records.

Arturo Díaz Almagro wrote:
> This is my SOA configuration
> $ORIGIN .
> $TTL 86400      ; 1 day
> domain.com         IN SOA  services.domain.com. root.localhost. (
>                                 08020502   ; serial
>                                 43200      ; refresh (1/2 day)
>                                 86400      ; retry (1 day)
>                                 2419200    ; expire (4 weeks)
>                                 604800     ; minimum (1 week)
>                                 )
>                                IN      NS      dns.domain.com.
>                      IN      NS      dns2.domain.com.
>                                A       10.100.0.3
> ;
> primary                 A        10.100.0.3
> secondary           A         10.172.0.3
> dns                       CNAME        primary
> dns2                     CNAME       secondary
> The NS record are right IP address for my network. Is that configuration
> right?
>
> Thanks
>
>
> 2008/2/4, kirk <kirkb at kirkb.net>:
>   
>> Arturo Díaz Almagro wrote:
>>     
>>> Hello all,
>>> Hope anybody could help me. I have two BIND9 servers where one is the
>>>       
>> master
>>     
>>> and other is the slave. I realized that when I perform a change in a
>>>       
>> zone
>>     
>>> file in the master and reload/restart the master BIND9 service the slave
>>> does not start the zone transfer inmediately. I have a 'high
>>>       
>> availability'
>>     
>>> system where the DNS server has an important role and I need those
>>>       
>> changes
>>     
>>> inmediately loaded. I noticed that those changes are loaded but in a big
>>> period time, so the system replication works. Could anybody tell me how
>>>       
>> to
>>     
>>> force BIND9 to load changes inmediately after the notifies are received?
>>>
>>> Thanks a lot.
>>>
>>>       
>> I have seen this happen when the name server resource records(NS) in the
>> zone are invalid. The master will attempt to send notifies to those
>> invalid NS entries (which never gets to the destination or the incorrect
>> destination) but after the SOA "refresh" interval elapses the zone gets
>> updated fine.
>>
>> Make sure that the notifies from the master to slave are reaching their
>> proper destination.
>>
>>
>>
>>     
>
>
>