bind replication
p...@mail.nsbeta.info
Is it a right way to run rsync for bind's zone files replication?
If we have dozons of zones, each zone has more than one view, under this
case setup the master/slave with standard zone-traff is the hard way IMO.
Thanks.
p...@mail.nsbeta.info
> Yes, that's just fine. You don't have to use zone transfers.
>
Thanks. But I have another question,
how would bind know the zone files were changed before it reload zones?
Regards.
p...@mail.nsbeta.info
>
> If you know which zone has changed, than you can do "rndc reload zonename".
> If you don't, than "rndc reload" reloads all zones.
> You could also try "rndc reconfig", but I think it will only load new zonesm
> the ones just added in configuration, not never wersions of old zones).
>
What I'm not sure is, given I have two hosts A and B, A is master, B is
slave.
B fetches the zone files from A via rsync.
But, how B knows that the zone files have been changed and then run "rndc
reload" to tell bind reload the zones?
Thanks & Happy New Year!
Regards.
Gary Wallis
> On 12/31/2010 9:39 AM, p...@mail.nsbeta.info wrote:
>> Ben Croswell writes:
>>> It seems like you
>>> are making the process more complex, instead of just letting BIND do it's
>>> job.
>> No. because I have many zones, and each zone has some views.
>> So the standard zone-transfer will most likely get broken due to the
>> complexity.
>
> Done carefully (which will be the case in all circumstances), doing zone
> transfers within views of many zones is no more "likely to get broken"
> than doing it with external mechanisms.
>
> Been there, done that, have the tee-shirt and certainly don't want to
> use rsync.
>
> AlanC
I agree with Alan, the command line and private tools are great for DNS
admins; but when you need to give end users the ability to 24x7 change
RRs in their zones, automated tools seem to be the only option.
I imagine that the "write once" vs "write and then click" holy war does
not apply in this case.
Cheers!
Gary
Anand Buddhdev
> I think you have to restart bind. That's why I believe it's better to use zone transfers because it's automatic.
You don't have to _restart_ BIND, you have to _reload_ it. Otherwise
BIND can't know that the zone file on disk has changed. You'd do
something like:
rsync source:/some/zone dest:/bind/dir/zone && ssh dest 'rndc reload zone'
--
Anand
Anand Buddhdev
> Hi,
> Is it a right way to run rsync for bind's zone files replication?
> If we have dozons of zones, each zone has more than one view, under this
> case setup the master/slave with standard zone-traff is the hard way IMO.
> Thanks.
Yes, that's just fine. You don't have to use zone transfers.
Anand
Gary Wallis
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
You need to create your own replication scripts as part of your dns
management process. Simple Perl scripts even BASH works fine. But it may
be a lot of work. And as it has been pointed out, you need to mesh with
the great ISC/BIND software:
rndc
And I would go further pre processing everything using:
named-checkzone
named-checkconf
Just as some have mentioned, when you need to manage many NSs with views
note that the perfect primary/secondary transfer system built in to BIND
(that is really a great distributed responsibility solution and even a
true DNS cornerstone) breaks. It breaks by adding complexity.
If a single entity is responsible for many DNS servers and zones and the
entity has complete control over all the systems, then, I personally
think that managed replication is much better.
See http://en.wikipedia.org/wiki/DNS_management_software for some free
GPL systems that do work.
Disclosure: I wrote one of them.
Happy new years,
Cheers!
Gary
Nuno Paquete
Thanks. But I have another question,
how would bind know the zone files were changed before it reload zones?
Regards.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
p...@mail.nsbeta.info
>
> If you wished to sync zone files in this manner, with dynamic zones, you would need
> to freeze the zones on the sending side, which forces a write of the data that is in the journal file to the zone file,
>
> freeze the zones on the receiving side
> then copy the files over
> reload
> unfreeze zones on both sides.
Thanks. This is the very helpful info.
Ben Croswell
What technical problem are you trying to solve with rsync? It seems like you are making the process more complex, instead of just letting BIND do it's job.
Alan Clegg
>> are making the process more complex, instead of just letting BIND do it's
>> job.
>
p...@mail.nsbeta.info
> It seems like you
> are making the process more complex, instead of just letting BIND do it's
> job.
No. because I have many zones, and each zone has some views.
So the standard zone-transfer will most likely get broken due to the
complexity.
Thanks.
Torinthiel
>
>No dia 31 de Dez de 2010, às 08:18, "p...@mail.nsbeta.info"
<p...@mail.nsbeta.info> escreveu:
>
>> Anand Buddhdev writes:
>>> On 31/12/2010 05:33, p...@mail.nsbeta.info wrote:
>>>> Hi,
>>>> Is it a right way to run rsync for bind's zone files replication?
>>>> If we have dozons of zones, each zone has more than one view, under
this
>>>> case setup the master/slave with standard zone-traff is the hard way
IMO.
>>>> Thanks.
>>> Yes, that's just fine. You don't have to use zone transfers.
>>
>> Thanks. But I have another question,
>> how would bind know the zone files were changed before it reload zones?
>> Regards.
>
>I think you have to restart bind. That's why I believe it's better to use
zone transfers because it's automatic.
No, you don't have to.
If you know which zone has changed, than you can do "rndc reload zonename".
If you don't, than "rndc reload" reloads all zones.
You could also try "rndc reconfig", but I think it will only load new zonesm
the ones just added in configuration, not never wersions of old zones).
Regards,
Torinthiel
Jack Tavares
If you are using dynamic zones, bind will create journal files.
If you were to copy over the zone files and journal files and do
a reload, bind determines whether or not to reload the zone based
on the timestamp of the zone file. It does not look at the time on the journal file.
p...@mail.nsbeta.info
>
> Done carefully (which will be the case in all circumstances), doing zone
> transfers within views of many zones is no more "likely to get broken"
> than doing it with external mechanisms.
>
So going with bind's zone-transfer is there a howto document for this
purpose?
Thanks.
Steve Arntzen
> Done carefully (which will be the case in all circumstances), doing zone
> transfers within views of many zones is no more "likely to get broken"
> than doing it with external mechanisms.
>
> use rsync.
>
> AlanC
>
I wanted to reply to this earlier.
I have several zones, five views and multiple slaves which pick up zone
data from specific views. Add to that some dynamic zones.
Because the named.conf file became not only complex, but also large, I
ended up breaking the configuration into multiple files (options, views
and zone declarations) and using include statements to tie it all
together. That made the configuration much easier to read and
understand.
Bind does everything at the local site itself without issue. Any zone
data changes are made on the master and everything syncs up. It just
works (like it's supposed to).
I use rsync ONLY to copy the configuration and zone data to a remote
site for disaster recovery every thirty minutes. rsync is configured to
NOT copy the journal files. As Bind will periodically write out the
journaled data, the zone data at the remote site is pretty fresh.
One downside to rsync is having to be aware of when the scheduled
synchronization occurs. One must be careful when editing zone files or
changing configurations so that partial changes are not copied to the
remote systems which could cause problems.
Let Bind do it's thing.
My 2 cents,
Steve.
Alan Clegg
> Alan Clegg writes:
>>
>> Done carefully (which will be the case in all circumstances), doing zone
>> transfers within views of many zones is no more "likely to get broken"
>> than doing it with external mechanisms.
>
> purpose?
Not a how-to, but it is covered in the BIND FAQ on the ISC website..
http://www.isc.org/software/bind/faq
Then look at the entry for:
My slave server for both an internal and an external view has both
views transferred from the same master view - how to resolve?
AlanC
p...@mail.nsbeta.info
>
> Not a how-to, but it is covered in the BIND FAQ on the ISC website..
>
> http://www.isc.org/software/bind/faq
>
> Then look at the entry for:
>
> My slave server for both an internal and an external view has both
> views transferred from the same master view - how to resolve?
>
Thanks.
If I have two views,the names are "tel" and "edu" (means telecom and edu
networks), and I want both nsupdate and zone-transfer, is the config looks
as below right? Thanks in advance.
acl "TEL" {
58.32.0.0/11;
58.208.0.0/12;
59.32.0.0/11;
59.80.0.0/14;
...
};
view "tel" {
match-clients {
key "telkey";
TEL;
};
allow-update {key "telkey";};
#others...
};
view "edu" {
match-clients {
key "edukey";
any;
};
allow-update {key "edukey";};
# others
};
key "telkey" {
algorithm hmac-md5;
secret "******";
};
key "edukey" {
algorithm hmac-md5;
secret "******";
};
Matus UHLAR - fantomas
> Is it a right way to run rsync for bind's zone files replication?
> If we have dozons of zones, each zone has more than one view,
you mean, each zone appears in more than one view?
> under this
> case setup the master/slave with standard zone-traff is the hard way IMO.
I'd ask myself if you really need that much views, or views at all.
However, setting up keys coule wease the way a bit.
(I don't object against rsync, I'm just lazy and prefer way that is least
complicated)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
Matus UHLAR - fantomas
>> If you know which zone has changed, than you can do "rndc reload zonename".
>> If you don't, than "rndc reload" reloads all zones.
>> You could also try "rndc reconfig", but I think it will only load new
>> zonesm the ones just added in configuration, not never wersions of old
>> zones).
On 31.12.10 21:55, p...@mail.nsbeta.info wrote:
> What I'm not sure is, given I have two hosts A and B, A is master, B is
> slave.
> B fetches the zone files from A via rsync.
> But, how B knows that the zone files have been changed and then run "rndc
> reload" to tell bind reload the zones?
simply run rndc reload and bind will reload all zones (actually, it will
check files' timestamps and reload only files that have changed).
note that for rsync replication there's no real "master" and "slave".
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller