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
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: [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
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
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
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
