Zone Transfer issue on BIND9
Hi there,
I have an issue related to zone transfer which I couldn't fix. I've found a
"presumable" fix googling a lot but it doesn't seem to work.
The main issue is that all my zones get transferred to the slave properly
but all the files related to the same view are identical.
I've found some similar issues and they were all pointing to the same ISC
FAQ link (https://www.isc.org/faq/item/182) which doesn't fix the issue at
all.
I've three main views and I've tried to apply the fix in the aforementioned
link. I've also tried to remove the "dmz" view from my configuration to
reflect a scenario as closer as possible to the one in the FAQ with no
success.
I've spent about 4 days trying to figure out why. And at the moment I've
just replaced everything with a 2 master configuration which implies a
manual update. I can theoretically live with that as I don't need to push
updates too often, but I can't live well without understanding what the heck
am I missing.
Any hint about any evident/hidden mistake would be really appreciated.
Below an extract from my configurations.
***MASTER server (FreeBSD 9.0-RELEASE-p3 (i386)|| BIND 9.8.3-P2)***
acl "internal" {
10.0.0.0/26;
10.0.1.0/28;
172.16.0.0/27;
172.16.1.0/28;
172.17.1.0/29;
127.0.0.1;
};
acl "dmz" { 172.17.2.0/27; };
acl "datacentre" {
171.XX.YY.24;
171.XX.YY.25;
171.XX.YY.26;
171.XX.YY.27;
171.XX.YY.28;
171.XX.YY.29;
171.XX.YY.30;
171.XX.YY.31;
172.16.3.0/27;
};
key TSIG-KEY {
algorithm hmac-sha512;
secret "HASH OMITTED";
};
server 171.XX.YY.27 {
keys { TSIG-KEY ;};
};
options {
directory "/etc/namedb";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
version "";
allow-recursion { internal; dmz; datacentre; };
allow-update { none; };
allow-transfer { none; };
listen-on { 10.0.0.15; 127.0.0.1; };
// listen-on-v6{ ::1; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
};
view "internal" {
match-clients { !key TSIG-KEY; internal; datacentre; };
allow-query { internal; datacentre; };
zone "." {
type hint;
file "/etc/namedb/named.root";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/namedb/master/localhost-reverse.db";
allow-transfer { localhost; };
};
zone "DOMAIN01.eu" {
type master;
file "/etc/namedb/master/DOMAIN01.eu.int.zone";
allow-transfer { 171.XX.YY.27; };
notify yes;
};
zone "DOMAIN02.net" {
type master;
file "/etc/namedb/master/DOMAIN02.net.int.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "DOMAIN03.net" {
type master;
file "/etc/namedb/master/DOMAIN03.net.int.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "0.0.10.in-addr.arpa" IN {
type master;
file "/etc/namedb/master/0.0.10.in-addr.arpa.int.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "1.16.172.in-addr.arpa" IN {
type master;
file "/etc/namedb/master/1.16.172.in-addr.arpa.ext.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "3.16.172.in-addr.arpa" IN {
type master;
file "/etc/namedb/master/3.16.172.in-addr.arpa.int.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "1.17.172.in-addr.arpa" {
type master;
file
"/etc/namedb/master/1.17.172.in-addr.arpa.ssl-vpn.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "2.17.172.in-addr.arpa" {
type master;
file "/etc/namedb/master/2.17.172.in-addr.arpa.dmz.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "YY.XX.171.in-addr.arpa" {
type master;
file
"/etc/namedb/master/YY.XX.171.in-addr.arpa.masterdc.zone";
allow-transfer { 171.XX.YY.27; };
};
/ SECURITY BLOCK /
...
OMITTED
...
};
view "dmz" {
match-clients { !key TSIG-KEY; internal; datacentre; };
allow-query { dmz; };
zone "DOMAIN01.eu" {
type master;
file "/etc/namedb/master/DOMAIN01.eu.dmz.zone";
allow-transfer { 171.XX.YY.27; };
};
zone "2.17.172.in-addr
Re: Zone Transfer issue on BIND9
On 24/08/12 12:09, sn...@email.it wrote:
Hi there,
I have an issue related to zone transfer which I couldn't fix. I've found a
"presumable" fix googling a lot but it doesn't seem to work.
You haven't said *how* it isn't working. Be specific.
Note that the FAQ link you reference puts the "server {}" block INSIDE
the view. You have it in the global config. That seems like something to
investigate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Zone Transfer issue on BIND9
You're putting the allow transfer on each zone? I don't think that's your
issue but it seems odd to me. Here we do it at the view level.
Also it appears you're using the same IP for at least two of your views - for
view transfers to work properly here we setup virtual IPs on the DNS servers
and set the ACLs appropriately.
i.e. our "real" IPs are in the ACL we used prior to setting up views and are
now only used for the main [external] view and we have different ACLs for the
virtual IPs used within the internal view.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Phil
Mayers
Sent: Friday, August 24, 2012 7:41 AM
To: bind-users@lists.isc.org
Subject: Re: Zone Transfer issue on BIND9
On 24/08/12 12:09, sn...@email.it wrote:
> Hi there,
> I have an issue related to zone transfer which I couldn't fix. I've
> found a "presumable" fix googling a lot but it doesn't seem to work.
You haven't said *how* it isn't working. Be specific.
Note that the FAQ link you reference puts the "server {}" block INSIDE the
view. You have it in the global config. That seems like something to
investigate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer
-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Zone Transfer issue on BIND9
Hi, thanks for replying,
I'll try to use the allow-transfer at the view level. Never tried that, not
even sure it works. But I'll try.
About the IP, according to my understanding, it was necessary to use
different IPs (virtual or not) on BIND prior version 9.3.
- Original Message
Da: Lightner Jeff
To: Phil Mayers , bind-users@lists.isc.org
Oggetto: RE: Zone Transfer issue on BIND9
Data: 24/08/12 14:16
>
>
>
> You're putting the allow transfer on each zone? I don't think that's
your issue but it seems odd to me. Here we do it at the view level.
>
> Also it appears you're using the same IP for at least two of your views -
for view transfers to work properly here we setup virtual IPs on the DNS
servers and set the ACLs appropriately.
> i.e. our "real" IPs are in the ACL we used prior to setting up views and
are now only used for the main [external] view and we have different ACLs
for the virtual IPs used within the internal view.
>
>
>
>
>
> -Original Message-
> From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of
Phil Mayers
> Sent: Friday, August 24, 2012 7:41 AM
> To: bind-users@lists.isc.org
> Subject: Re: Zone Transfer issue on BIND9
>
> On 24/08/12 12:09, sn...@email.it wrote:
> > Hi there,
> > I have an issue related to zone transfer which I couldn't fix. I've
> > found a "presumable" fix googling a lot but it doesn't seem to work.
>
> You haven't said *how* it isn't working. Be specific.
>
> Note that the FAQ link you reference puts the "server {}" block INSIDE the
view. You have it in the global config. That seems like something to
investigate.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
>
> Athena(r), Created for the Cause(tm)
> Making a Difference in the Fight Against Breast Cancer
>
> -
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you
have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Thank you.
> --
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna. Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12601&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte settimana benessere con i pacchetti terme degli hotel della riviera
romagnola. Rimini, Riccione, Cattolica e Misano. Chiama lo 0541607636 Consorzio
Costahotels
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12533&d=24-8
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
On Fri, 24 Aug 2012, sn...@email.it wrote:
> ***MASTER server (FreeBSD 9.0-RELEASE-p3 (i386)|| BIND 9.8.3-P2)***
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
...
> view "dmz" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
A client request will be resolved in the context of the first view that
it matches. The above match-clients are identical for different views so
the dmz view is not used.
> ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
> view "dmz" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
I believe I did specify how: "The main issue is that all my zones get
transferred to the slave properly but all the files related to the same view
are identical.". But I've realised I've not explained it properly.
My issue is that files transferred on the slave are identical but within
DOMAINS, not VIEWS. I apologise for my mistake.
For example, on the slave:
DOMAIN01.eu.int.zone
DOMAIN01.eu.ext.zone
are identical just as like as the other internal/external zone files for the
other domains.
Anyway, another user pointed me to the fact that I've used the
allow-transfer at the zone level, not at the view level.
That might be a good start.
I'm gonna try that ASAP as a start. Any other idea is more than welcome.
Thanks in advance for your time Phil.
- Original Message
Da: Phil Mayers
To: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 13:41
>
>
>
> On 24/08/12 12:09, sn...@email.it wrote:
> > Hi there,
> > I have an issue related to zone transfer which I couldn't fix. I've
found a
> > "presumable" fix googling a lot but it doesn't seem to work.
>
> You haven't said *how* it isn't working. Be specific.
>
> Note that the FAQ link you reference puts the "server {}" block INSIDE
> the view. You have it in the global config. That seems like something to
> investigate.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna. Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12596&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte last minute Rimini, Riccione, Cattolica e Misano negli hotel per
famiglie con pacchetti tutto compreso per le vacanze al mare con bambini.
Animazione e servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12534&d=24-8
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
Unfortunately that cannot be the root cause because (as stated in my first
email) I've also tried to remove completely the dmz view from both servers
leaving just the internal and the external one. And I had the same issue
still.
But as I've just wrote a minute ago I've made a mistake in my first
description of the issue.
Files are identical within the DOMAIN, not the VIEW.
For example, on the slave server:
DOMAIN01.eu.int.zone
DOMAIN01.eu.ext.zone
are exactly the same (also same checksum)
so the other zone files of the same domains are:
DOMAIN02.net.int.zone
DOMAIN02.net.ext.zone
and so on.
Thanks.
- Original Message
Da: Jeremy C. Reed
To:
Cc: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 14:43
>
>
>
> On Fri, 24 Aug 2012, sn...@email.it wrote:
>
> > ***MASTER server (FreeBSD 9.0-RELEASE-p3 (i386)|| BIND 9.8.3-P2)***
>
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> ...
>
> > view "dmz" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
>
> A client request will be resolved in the context of the first view that
> it matches. The above match-clients are identical for different views so
> the dmz view is not used.
>
>
> > ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
>
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> > view "dmz" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
>
>
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte all inclusive in Romagna.Speciale Agosto da Euro 480,00 Speciale
Settembre da Euro 295,00. Terzo letto Gratis e Quarto scontato al 50%
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12545&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte settimana benessere con i pacchetti terme degli hotel della riviera
romagnola. Rimini, Riccione, Cattolica e Misano. Chiama lo 0541607636 Consorzio
Costahotels
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12533&d=24-8
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
On Fri, 24 Aug 2012, sn...@email.it wrote:
> view "internal" {
...
> zone "1.16.172.in-addr.arpa" IN {
> type master;
> file "/etc/namedb/master/1.16.172.in-addr.arpa.ext.zone";
Previous zone file names in this same view were called "int". Why the
filename change? (ext means "external" even though in the internal
view?)
> ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
> key TSIG-KEY. {
...
> allow-notify { 171.XX.YY.27; 10.0.0.15; };
> listen-on { 171.XX.YY.27; 127.0.0.1; };
Is the allow-notify 171.XX.YY.27 address same as the listen-on
171.XX.YY.27 address? This is confusing as the allow-notify is a
different server and listen-on is this server.
> view "internal" {
> match-clients { !key TSIG-KEY; internal; datacentre; };
What defines that TSIG-KEY? Notice it doesn't have the trailing period
"TSIG-KEY." as defined earlier.
>From your later email:
> Files are identical within the DOMAIN, not the VIEW.
> For example, on the slave server:
> DOMAIN01.eu.int.zone
> DOMAIN01.eu.ext.zone
>
> are exactly the same (also same checksum)
Are they a copy of the internal or external view's zone on the master?
It is a little difficult to follow the configuration when using maybe
fake IP addresses, fake zone names, and fake filenames. You may want to
simplify your named.conf to bare minimum (two views and one zone each)
for initial testing.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
- Original Message
Da: Jeremy C. Reed
To:
Cc: bind-users@lists.isc.org
Oggetto: Re: Zone Transfer issue on BIND9
Data: 24/08/12 15:39
>
>
>
> On Fri, 24 Aug 2012, sn...@email.it wrote:
>
> > view "internal" {
>
> ...
> > zone "1.16.172.in-addr.arpa" IN {
> > type master;
> > file
"/etc/namedb/master/1.16.172.in-addr.arpa.ext.zone";
>
> Previous zone file names in this same view were called "int". Why the
> filename change? (ext means "external" even though in the internal
> view?)
>
You're right. It is a bit misleading but it is as such also because I've
already shrunk the configuration file consistently already. It's marked as
"ext" because that IP range is geographically somewhere else ... reachable
via VPN tunnelling. Which makes it basically internal even though it has
been called as such just for practical reasons (to remind me that the
network is not "here"). That's why it's in the "internal" view. Perhaps
another abbreviation would have been more appropriate.
> > ***SLAVE server (FreeBSD 9.0-RELEASE-p3 (amd64)|| BIND 9.8.1-P1)***
>
> > key TSIG-KEY. {
> ...
>
> > allow-notify { 171.XX.YY.27; 10.0.0.15; };
>
> > listen-on { 171.XX.YY.27; 127.0.0.1; };
>
> Is the allow-notify 171.XX.YY.27 address same as the listen-on
> 171.XX.YY.27 address? This is confusing as the allow-notify is a
> different server and listen-on is this server.
>
True that.
I've put that IP address there as a test yesterday (or the day before) I
believe because I was having a problem in the logs showing the following
message:
"refused notify from non-master: 171.XX.YY.27#52860"
Problem that I've fixed in this way, putting the IP address of the server
itself in the allow-notify field along with the IP address of the master
one. Not sure that's a fix or a workaround, but I don't think that might
cause harm anyhow. Of course I might be wrong. :)
> > view "internal" {
> > match-clients { !key TSIG-KEY; internal; datacentre; };
>
> What defines that TSIG-KEY? Notice it doesn't have the trailing period
> "TSIG-KEY." as defined earlier.
>
> From your later email:
>
> > Files are identical within the DOMAIN, not the VIEW.
> > For example, on the slave server:
> > DOMAIN01.eu.int.zone
> > DOMAIN01.eu.ext.zone
> >
> > are exactly the same (also same checksum)
>
> Are they a copy of the internal or external view's zone on the master?
>
I apologise. The trailing period got lost during the name substitution with
vi. It's just a "typo". In normal config there's not such a thing.
Basically if I've the directive "!key TSIG-KEY." in the match-client field,
all affected files get the content of the external view's zone. If there's
"key TSIG-KEY." instead I've got all the affected files with the internal
view's zone.
> It is a little difficult to follow the configuration when using maybe
> fake IP addresses, fake zone names, and fake filenames. You may want to
> simplify your named.conf to bare minimum (two views and one zone each)
> for initial testing.
It is.
But the only things that I've changed are the public IP addresses and the
domain names which affect also file names and the TSIG name.
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it: http://www.email.it/f
Sponsor:
Offerte last minute Rimini, Riccione, Cattolica e Misano negli hotel per
famiglie con pacchetti tutto compreso per le vacanze al mare con bambini.
Animazione e servizio spiaggia
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12534&d=20120824
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP
autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
Offerte hotel + parco per pacchetti con ingresso incluso ai parchi
divertimento della romagna, negli hotel Rimini, Riccione, Cattolica e Misano
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=12536&d=24-8
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
The problem pointed out in your 'match-clients' is the first glaring problem. What you need to understand is that from the point of BIND, your slave server is treated the same (from the view ) as any "client" for the master and vice versa. So, the communication between master and slave needs to be taken into account along with "real" clients. Breaking down your views along w/ the files, it appears you want to have 3 unique zone files for the same domains being transferred from master to slave. That means you need to define 3 unique paths between master and slave. Given that, if you are going to only use one IP, you need to use 2 keys. For example, TSIG1-KEY, TSIG2-KEY and the 'other' match. I'd heavily recommend following the other advice and simplify your test scenario. Get the communication working for a single unique zone file across the 3 views between the master and slave. Then add in whatever other acls needed to support non-master/slave comm. Once you have that, then augment it with the rest of zones you need to support. -- John ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone Transfer issue on BIND9
The key names will show up in syslog messages along with IPs and view names. Compare master and slave syslogs for clues. JM -- Message: 1 Date: Sat, 25 Aug 2012 11:48:47 -0400 From: John Wingenbach To: bind-users@lists.isc.org Subject: Re: Zone Transfer issue on BIND9 Message-ID: <20120825114847.6679a...@cistern.wingenbach.org> Content-Type: text/plain; charset=US-ASCII The problem pointed out in your 'match-clients' is the first glaring problem. What you need to understand is that from the point of BIND, your slave server is treated the same (from the view ) as any "client" for the master and vice versa. So, the communication between master and slave needs to be taken into account along with "real" clients. Breaking down your views along w/ the files, it appears you want to have 3 unique zone files for the same domains being transferred from master to slave. That means you need to define 3 unique paths between master and slave. Given that, if you are going to only use one IP, you need to use 2 keys. For example, TSIG1-KEY, TSIG2-KEY and the 'other' match. I'd heavily recommend following the other advice and simplify your test scenario. Get the communication working for a single unique zone file across the 3 views between the master and slave. Then add in whatever other acls needed to support non-master/slave comm. Once you have that, then augment it with the rest of zones you need to support. -- John -- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users End of bind-users Digest, Vol 1295, Issue 1 *** ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
