Hi all,
we have one master server and several slave servers with Bind 9.9.2-P1, and
service for about 50K zones.
i shutdown one slave,start it, then a lot of transfer between the slave and
server:
log segment(rand zone for test):
***
05-Mar-2013 18:36:18.675 general: info: zone 6x3he.com/IN:
On Mar 5 2013, Felix New wrote:
we have one master server and several slave servers with Bind 9.9.2-P1, and
service for about 50K zones.
i shutdown one slave,start it, then a lot of transfer between the slave and
server:
[... snip ...]
the check transfer(maybe this is usefull for
On 05/03/13 11:39, Felix New wrote:
Hi all,
we have one master server and several slave servers with Bind 9.9.2-P1,
and service for about 50K zones.
i shutdown one slave,start it, then a lot of transfer between the slave
and server:
log segment(rand zone for test):
***
05-Mar-2013 18:36:18.675
On 04.03.13 17:35, Shawn Bakhtiar wrote:
A better solution may be (if feasible) to register and get an internet AS
number and enable BGP on both links. If one fails the upstream routers
(even if from desperate providers) will detect a fail and re-rout via the
active link.
you don't need AS
Hi,all
I want to transfer multiple views from master to slave. The zones are in
different views in master, and in single view in slave.
Ex:
MASTER:
view v1{
zone z11 {...} //need transfer
zone z12 {...}
zone z13 {...}
}
view v2 {
zone z21 {...} //need transfer
zone z22
Hi
You can not really share a zone(=file) between views. Both views will
believe they have full rights to the file and one view will see this as
someone (the other view) will change the file behind its back.
What might work is to use a key to allow you to access the views needed.
You should
On Mar 4, 2013, at 10:43 AM, Verne Britton wrote:
I have been testing and testing and either just don't see what I'm doing
wrong, or have a learning block :-)
current thinking is that a open recursion DNS server is bad, so we want to
implement an allow-recursion clause; perhaps even
Hello everyone,
I have a question about using the $INCLUDE directive in my zone files.
We run DNS for a moderately large number of domains, largely pointing at
the same servers. So, I'd really like to have the following setup:
db.common.inc:
mail IN A n.n.n.n
mail2 IN A n.n.n.n
In article mailman.1607.1362510489.11945.bind-us...@lists.isc.org,
Pat Suwalski p...@suwalski.net wrote:
Hello everyone,
I have a question about using the $INCLUDE directive in my zone files.
We run DNS for a moderately large number of domains, largely pointing at
the same servers. So,
On 3/5/2013 1:08 PM, Pat Suwalskip...@suwalski.net wrote:
Hello everyone,
I have a question about using the $INCLUDE directive in my zone files.
We run DNS for a moderately large number of domains, largely pointing at
the same servers. So, I'd really like to have the following setup:
On 13-03-05 02:51 PM, Barry S. Finkel wrote:
What you need to do is have the common piece in an $INCLUDE file
and put changed items (such as www in your example) in each view.
If www changes in each view, then do not include it in the common
file. If, for example, you have three views, and www
Use TSIG to select the right instances
MASTER:
key transfer.key.v1 {
};
key transfer.key.v2 {
};
acl all-transfer-keys {
key transfer.key.v1; keyy transfer.key.v2;
};
view v1 {
match-clients { key transfer.key.v1; !all-transfer-keys; };
In message 513654f9.4060...@suwalski.net, Pat Suwalski writes:
On 13-03-05 02:44 PM, Barry Margolin wrote:
Instead of one include file for everything, use separate include files:
$INCLUDE db.common.mail.inc
$INCLUDE db.common.www.inc
$INCLUDE db.common.spf.inc
Then you can omit
On 03/05/2013 11:08 AM, Pat Suwalski wrote:
Hello everyone,
I have a question about using the $INCLUDE directive in my zone files.
We run DNS for a moderately large number of domains, largely pointing at
the same servers. So, I'd really like to have the following setup:
db.common.inc:
14 matches
Mail list logo
