DNS views TSIG and zone xfers
project722
project722 at gmail.com
Sat Aug 27 00:31:37 UTC 2016
Thanks Bob, that is exactly what I ended up doing. And its working great
now. You are also right about the view selection.
On Fri, Aug 26, 2016 at 3:43 PM, Bob Harold <rharolde at umich.edu> wrote:
>
> On Thu, Aug 25, 2016 at 6:25 PM, project722 <project722 at gmail.com> wrote:
>
>> Actually, I got to thinking about this. The "other_allowed_ns" ACL is in
>> the global options, along with an "allow-transfer" for that ACL. So, I
>> *think* they will still be able to zone transfer via the global option
>> based on simply IP. BUT...since I have multiple views, which zones from
>> which views get sent over to these servers and how will they know how to
>> handle the info if zones from both views get sent. Would something like
>> this help:
>>
>> allow-transfer { other_allowed_ns; view "external"; };
>>
>> So they only get sent the zones from the external view?
>>
>> On Thu, Aug 25, 2016 at 5:14 PM, project722 <project722 at gmail.com> wrote:
>>
>>> I have successfully setup TSIG keys for "views" using a DNS
>>> master/server pair. Zone transfers are working as expected between the 2
>>> servers for each view. Before we go live into production with this I need
>>> some clarification on a couple things. Our prod servers are also allowing
>>> zone transfers to a few other servers besides the slave server. We have an
>>> acl setup that looks similar to this:
>>>
>>>
>
>> {
>>> x.x.x.x; // This is our Secondary DNS server
>>> 127.0.0.1; // localhost can make zone transfers
>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> }; // end of "other_xfer_allowed" ACL
>>>
>>> And in the "allow transfer" statement we have included that ACL. My
>>> question is:
>>>
>>> Now that we are using TSIG, will I need to get with the admins of all
>>> these other servers and provide them my TSIG key so they can request zone
>>> transfers? I would think somehting like that needs to be done since it was
>>> required to be configured on slave server, but I am not sure. I'd rather do
>>> an IP based control just for these other servers instead of TSIG but I am
>>> not sure how that would look or how to set that up in the context of my
>>> config. How can I tell my conf to NOT force these other xfer allowed
>>> servers to use TSIG and use IP only? This gets complicated when you start
>>> throwing views into the mix.
>>>
>>> acl internal {
>>> 192.168.200.0/24; // corpnet
>>> };
>>>
>>> acl external {
>>> 192.168.201.0/24;
>>> 192.168.202.0/24;
>>> };
>>>
>>>
>>> other_xfer_allowed_ns {
>>> x.x.x.x; // This is our Secondary DNS server
>>> 127.0.0.1; // localhost can make zone transfers
>>> x.x.x.x/24; // Server Farm Range is allowed to make zone-transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> x.x.x.x/24; // NAT pool for internal DNS server Zone Transfers
>>> }; // end of "other_xfer_allowed" ACL
>>>
>>>
>>> key "tsigkey" {
>>> algorithm HMAC-SHA512;
>>> secret "xxxxxxxxx";
>>> };
>>>
>>> key "tsigkeyext" {
>>> algorithm HMAC-SHA512;
>>> secret "xxxxxxxxxx";
>>> };
>>>
>>>
>>> view "corpnet" {
>>> match-clients { internal; key tsigkey;
>>> };
>>>
>>> //IP of slave server
>>> server 192.168.173.78 {
>>> keys { tsigkey; };
>>> };
>>>
>>> also-notify {
>>> 192.168.173.78;
>>> };
>>>
>>> zone "." IN {
>>> type hint;
>>> file "named.ca";
>>> };
>>>
>>> zone"internalzone1.com" IN {
>>> type master;
>>> file "internalzone1.com";
>>> allow-transfer { key tsigkey; };
>>> };
>>>
>>> zone"sharedzone.com" IN {
>>> type master;
>>> file "sharedzone1.com";
>>> allow-transfer { key tsigkey; };
>>> };
>>>
>>> include "/etc/named.rfc1912.zones";
>>> include "/etc/named.root.key";
>>> };
>>>
>>>
>>> view "external" {
>>> match-clients { external; key tsigkeyext; };
>>>
>>> //IP of slave server
>>> server 192.168.173.78 {
>>> keys { tsigkeyext; };
>>> };
>>>
>>> also-notify {
>>> 192.168.173.78;
>>> };
>>>
>>> zone "." IN {
>>> type hint;
>>> file "named.ca";
>>> };
>>>
>>> zone"externalzone1.com" IN {
>>> type master;
>>> file "externalzone1";
>>> allow-transfer { key tsigkeyext; };
>>>
>>> zone"sharedzone.com" IN {
>>> type master;
>>> file "sharedzone2.com";
>>> allow-transfer { key tsigkeyext; };
>>> };
>>> include "/etc/named.rfc1912.zones";
>>> include "/etc/named.root.key";
>>> };
>>>
>>>
> "allow-transfer { key tsigkeyext; };" means that the key tsigkeyext is
> the only way to transfer this zone.
>
> You define "other_xfer_allowed_ns" but I do not see it used anywhere.
>
> Most likely what you want is:
> allow-transfer { key tsigkeyext; other_xfer_allowed_ns; };
> So that either the TSIG key can be used, or any of the IP's can transfer
> regardless of TSIG.
> (I don't know of a way to restrict a transfer to a specific IP *and*
> require TSIG)
>
> As to which view they "see", the "match-clients" determines that. They
> will only ever hit one view with a given request. So a transfer will only
> get the zone from that particular view.
>
> Hope that makes it clearer.
>
> --
> Bob Harold
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160826/2e69d68b/attachment.html>
More information about the bind-users
mailing list