bind replication between sites

[Merton Campbell Crockett]

In a crufty BIND 8 environment, I observed a similar problem where  
slave name servers were not maintaining synchronisation with the  
master name server when dynamic DNS updates were enabled.  All  
dynamic updates were being performed by an ISC DHCP server or  
manually using nsupdate.

That last statement isn't entirely correct.  I do allow Windows  
Active Directory domain controllers to update the DomainDNSZones,  
ForestDNSZones, _MSDCS, _SITES, _TCP, and _UDP subdomains.

To maintain synchronisation, I found that I needed to have the  
"maintain-ixfr-base yes;" global option set on all name servers and  
that I needed to have a "server" statement for the master name server  
in each of the slave name server configuration files.

Prior to implementing this, the slave servers would only catch up  
when the refresh interval expired and, immediately, lose  
synchronisation when DHCP removed resource records for expired leases  
or created new resource records for a new lease.

Merton Campbell Crockett



On 22 Jul 2006, at 07:02 , Sten Carlsen wrote:

> Ok, a few more questions:
> After making the change with your script, do you check the new SOA  
> with
> dig? (dig <zone> axfr) does it show the new incremented serial?
> And back to Kevins question what are the times involved in the SOA,
> specially the refresh time. You could try to make that short, like 5
> minutes for the experiment and see if that gets the zone updated  
> when it
> expires.
>
> A couple of other things to consider: is axfr allowed from both  
> slaves?
> is any firewall open for both UDP and TCP transfers with the proper  
> port
> numbers?
>
> If this does not ring a bell, I think you should publish the relevant
> named.conf and zone files from both master and slaves here. Please do
> not change anything, except keys for TSIG, rndc and like. Any editing
> can inadvertently make changes that hide the real problems from  
> view and
> draw attention into the wrong direction delaying the solution. I am
> pretty sure that a lot of people on the list will look at the real  
> files
> and analyse them.
>
> Dave Henderson wrote:
>> Sten,
>>
>>   You are correct in your first paragraph.  I can create a brand  
>> new  zone and it gets propagated to both slave servers.  Any  
>> changes  made to that new zone do not get replicated.  And I have  
>> been  increasing the serial number.  I wrote a perl script that   
>> adds/del/updates the record and increases the serial number.  I   
>> verified all content added/deleted/updated via the script is  
>> correct,  but still no slave servers get updated.
>>
>>   The reason the serial numbers are low is because they are the  
>> ones  listed on the slave server.  The ones on the master are up  
>> to  17.  There shouldn't be a problem at all.
>>
>>   DHCP can be ruled out because these aren't clients creating  
>> dynamic DNS entries (so no its not a stupid wintel client).
>>
>>   Dave
>>
>>
>> Sten Carlsen <ccc2716 at vip.cybercity.dk> wrote:  As I read the  
>> original post:
>> from starting the slave server with no zone file on it, the  
>> replication
>> takes place as it should and after a short there is a zone file on  
>> the
>> slave server. So far all ok.
>> Next, if a change is done on the master that change is not  
>> propagated to
>> the slave server.
>>
>> Is this the correct description of the problem?
>>
>> If this is so, I would like to ask if you remember to increase the
>> serial number in the master zone file? or use nsupdate or dhcp to  
>> update
>> the zone?
>>
>> I noticed the serial numbers from the log files being very low,  
>> possibly
>> indicating that they were not incremented. This would present the  
>> exact
>> picture I explain at the top of this post.
>>
>> Kevin Darcy wrote:
>>
>>> Dave Henderson wrote:
>>>
>>>
>>>> Gang,
>>>>
>>>>  I have three bind servers running. Two at site 1 (one master  
>>>> and one  slave) and the other at site 2. Replication of the zone  
>>>> file seems to  take place, but when updates are made on the  
>>>> master server, they don't  get replicated to the slaves.
>>>>
>>>>
>>> I don't quite understand that sentence. The file is replicating  
>>> but the
>>> changes aren't (???)
>>>
>>>
>>>> Here is a  snippet from the log of the master if I delete the  
>>>> file on a slave  server:
>>>>
>>>>   Jul 19 13:55:55 localhost named[8329]: client  
>>>> 192.168.0.31#32936: transfer of 'esessen.org/IN': AXFR started
>>>>
>>>>   and here it is on the slave server:
>>>>
>>>>   Jul 19 13:55:53 localhost named[7857]: zone esessen.org/IN:  
>>>> transferred serial 3
>>>>   Jul 19 13:55:53 localhost named[7857]: transfer of  
>>>> 'esessen.org/IN' from 192.168.0.11#53: end of transfer
>>>>   Jul 19 13:55:53 localhost named[7857]: zone esessen.org/IN:  
>>>> sending notifies (serial 3)
>>>>
>>>>
>>>>  That all seems to work ok, but if I make change to a domain, it  
>>>> doesn't  get replicated. There are no records on the master  
>>>> server indicating a  transfer at all. The slave contains:
>>>>
>>>>   Jul 19 13:55:52 localhost named[7857]: zone cliquesoftware.com/ 
>>>> IN: sending notifies (serial 2)
>>>>
>>>>   The actual serial number on the master is 17.  Here is the  
>>>> master log (after a restart):
>>>>
>>>>   Jul 19 11:19:41 localhost named[8329]: zone cliquesoftware.com/ 
>>>> IN: loaded serial 17
>>>>   Jul 19 11:19:41 localhost named[8329]: zone cliquesoftware.com/ 
>>>> IN: sending notifies (serial 17)
>>>>
>>>>
>>>>
>>> How long have you waited and what is the REFRESH setting on the  
>>> zone? If
>>> there's something wrong with the NOTIFY mechanism for this zone,  
>>> then it
>>> could take up to REFRESH time for the changes to replicate.
>>>
>>> If NOTIFY is broken, then that could be tackled as a separate issue.
>>> Better to establish that normal REFRESH-timed replication works  
>>> before
>>> getting into the arcana of NOTIFY.
>>>
>>>
>>>>   I am getting the following on the master, but I don't have a  
>>>> server or client using the following ip address:
>>>>
>>>>  Jul 19 12:11:20 localhost named[8329]: client  
>>>> 192.168.0.200#2679:  updating zone 'digital-pipe.local/IN':  
>>>> update failed: 'RRset exists  (value dependent)' prerequisite  
>>>> not satisfied (NXRRSET)
>>>>   Jul 19 12:11:20 localhost named[8329]: client  
>>>> 192.168.0.200#2682: update 'digital-pipe.local/IN' denied
>>>>
>>>>
>>>>
>>>>
>>> Probably just a stupid Wintel client that's misconfigured to  
>>> register
>>> its name in DNS.
>>>
>>>
>>>                                        - Kevin
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> -- 
> Best regards
>
> Sten Carlsen
>
> Let HIM who has an empty INBOX send the first mail.
>
>
>
>

Merton Campbell Crockett
m.c.crockett at adelphia.net