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