Re: [Question] zone transfer issue with multiple views
Thanks guys. Let me play a bit and see how it goes. Cheers. Eoin From: Matthew Pounsett Sent: Saturday, 9 December 2017 9:29 AM To: Eoin Kim Cc: Lightner, Jeffrey; bind-users@lists.isc.org Subject: Re: [Question] zone transfer issue with multiple views On 8 December 2017 at 17:37, Eoin Kim mailto:eoin@rcst.com.au>> wrote: Hi, Thanks for your help. But is it possible to do it without additional IP address? I thought that I am not really bad with BIND but as soon as I started using views, I'm going nowhere [😊] In order for the slave's View A to transfer from the master's View A, and the slave's View B to transfer from the master's view B, there has to be some way for the master to differentiate the two views on the slave and answer their queries from the correct view. Source IP address is the typical way to do that. You could probably select on source port instead, by setting the slave's transfer-source to a particular port for each view. I've never set this up myself, but I just checked the ARM and it looks like you can use any legal address_match_list in the view's match-clients list, so you could also select on TSIG key used, if you assign per-view TSIG keys. ___ 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: [Question] zone transfer issue with multiple views
On 8 December 2017 at 17:37, Eoin Kim wrote: > Hi, > > > Thanks for your help. But is it possible to do it without additional IP > address? I thought that I am not really bad with BIND but as soon as I > started using views, I'm going nowhere [image: 😊] > > > In order for the slave's View A to transfer from the master's View A, and the slave's View B to transfer from the master's view B, there has to be some way for the master to differentiate the two views on the slave and answer their queries from the correct view. Source IP address is the typical way to do that. You could probably select on source port instead, by setting the slave's transfer-source to a particular port for each view. I've never set this up myself, but I just checked the ARM and it looks like you can use any legal address_match_list in the view's match-clients list, so you could also select on TSIG key used, if you assign per-view TSIG keys. ___ 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: [Question] zone transfer issue with multiple views
Hi, Thanks for your help. But is it possible to do it without additional IP address? I thought that I am not really bad with BIND but as soon as I started using views, I'm going nowhere [😊] I found related links: * ​https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html (I believe my scenario would be example 3 or 4) * https://kb.isc.org/article/AA-00723/0 (Because I really want to use TSIG) Do I have to use a tarball from ISC to do this? Debian's BIND has a version of 9.9.5 so version-wise, it looks alright to me. Thanks again. Eoin From: Lightner, Jeffrey Sent: Friday, 8 December 2017 11:38 PM To: Lightner, Jeffrey; Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views Sorry that 10.0.9.9 should be 10.9.9.9 – i.e. notify-source and transfer-source are the same IP within the same view. From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Lightner, Jeffrey Sent: Friday, December 08, 2017 8:34 AM To: Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; …then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; …then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master – you’d have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic – eth1 is used for internal including zone transfers) ___ 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: [Question] zone transfer issue with multiple views
Sorry that 10.0.9.9 should be 10.9.9.9 - i.e. notify-source and transfer-source are the same IP within the same view. From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Lightner, Jeffrey Sent: Friday, December 08, 2017 8:34 AM To: Eoin Kim; bind-users@lists.isc.org Subject: RE: [Question] zone transfer issue with multiple views When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; ...then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; ...then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master - you'd have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic - eth1 is used for internal including zone transfers) ___ 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: [Question] zone transfer issue with multiple views
When we did it here we setup separate notify-source and transfer-source within the views on both the master and the slave. view "internal" { match-clients { internaldns; }; notify-source 10.9.9.8.; transfer-source 10.9.9.8; allow-transfer { dnsservers; }; ...then our zones for internal view Internaldns acl is one that we specify servers inside our network. dnsserrvers acl is one that specifies the primary internal facing IP of the master and the slave view "external" { match-clients { any; }; notify-source 10.9.9.9; transfer-source 10.0.9.9; allow-transfer { dswadnsalias; }; ...then our zones for external view any allows external locations to query us (we have recursion turned off) dswadnsalias acl is one that specifies the alias IPs on the same NIC as the internal facing IP of the master and the slave The IPs above would be on the master - you'd have separate IPs (but the same ACLs) on the slave. You can create an alias IP on your primary NIC so for example here we have: eth1 = 10.9.9.8 eth1:1 = 10.0.9.9 (In our config eth0 is the one we use for external facing traffic - eth1 is used for internal including zone transfers) From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Eoin Kim Sent: Thursday, December 07, 2017 8:05 PM To: bind-users@lists.isc.org Subject: [Question] zone transfer issue with multiple views Hi all, I wonder if anyone can help me find the cause of the problem I am currently having. I am testing BIND with two views - internal, external. Everything seems okay except for one thing - zone transfer doesn't look happening for reverse zone for external view. On my slave server, I can see the following log message: 08-Dec-2017 10:55:59.247 general: info: zone 0.20.172.in-addr.arpa/IN/external: refresh: unexpected rcode (NXDOMAIN) from master 192.168.0.7#53 (source 0.0.0.0#0) Servers are using TSIG for zone transfer. It looks like zone transfer itself working for all other zones except for reverse zone for external view. Could I please get help if possible? I am using Debian Jessie and BIND was installed from its repository. I am willing to post BIND configurations if needed. Thanks a lot. Eoin Kim Systems Administrator RCS Telecommunications Level 1 - The Annexe 133 Mary Street Brisbane, QLD, 4000 Office: 07 3228 0843 Mobile: 0419 726 231 [RCST logo drop shadow] ___ 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: DNSSEC / Include a subdomain's KSK data, ZSK data or both in parent domain?
On 07.12.2017 22:33, Douglas C. Stephens wrote: > My research found that only DS records for the child zone's KSK(s) > needed to be put into the parent zone. That's what I thought, thank you for your confirmation. -Ralph ___ 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