DNS views TSIG and zone xfers

[project722]

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>